Re: [patch 01/28] cpu alloc: The allocator
On Tue, 13 Nov 2007, David Miller wrote: > The idea about doling out vmalloc space seemed the most promising. Well that is basically the same as the virtual mode. Just ditch the fallback mode? vmalloc directly does not guarantee a fixed address. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] - [15/15] - remove defconfig ptr comparisons to 0 - net/sunrpc
Remove defconfig ptr comparison to 0
Remove sparse warning: Using plain integer as NULL pointer
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
---
diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
index 76be83e..1600df2 100644
--- a/net/sunrpc/clnt.c
+++ b/net/sunrpc/clnt.c
@@ -157,7 +157,7 @@ static struct rpc_clnt * rpc_new_client(struct rpc_xprt
*xprt, char *servname, s
clnt->cl_server = clnt->cl_inline_name;
if (len > sizeof(clnt->cl_inline_name)) {
char *buf = kmalloc(len, GFP_KERNEL);
- if (buf != 0)
+ if (buf)
clnt->cl_server = buf;
else
len = sizeof(clnt->cl_inline_name);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] - [14/15] - remove defconfig ptr comparisons to 0 - kernel
Remove defconfig ptr comparison to 0
Remove sparse warning: Using plain integer as NULL pointer
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
---
diff --git a/kernel/futex.c b/kernel/futex.c
index 9dc591a..ea119d3 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -276,7 +276,7 @@ static int get_futex_key(u32 __user *uaddr, struct
rw_semaphore *fshared,
*/
static void get_futex_key_refs(union futex_key *key)
{
- if (key->both.ptr == 0)
+ if (!key->both.ptr)
return;
switch (key->both.offset & (FUT_OFF_INODE|FUT_OFF_MMSHARED)) {
case FUT_OFF_INODE:
diff --git a/kernel/pid.c b/kernel/pid.c
index d1db36b..1b3f842 100644
--- a/kernel/pid.c
+++ b/kernel/pid.c
@@ -563,7 +563,7 @@ static struct pid_namespace *create_pid_namespace(int level)
atomic_set(>pidmap[0].nr_free, BITS_PER_PAGE - 1);
for (i = 1; i < PIDMAP_ENTRIES; i++) {
- ns->pidmap[i].page = 0;
+ ns->pidmap[i].page = NULL;
atomic_set(>pidmap[i].nr_free, BITS_PER_PAGE);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] - [12/15] - remove defconfig ptr comparisons to 0 - include/asm-x86
Remove defconfig ptr comparison to 0
The memcpy from memory location 0 sure looks odd.
Remove sparse warning: Using plain integer as NULL pointer
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
---
diff --git a/include/asm-x86/mach-es7000/mach_mpparse.h
b/include/asm-x86/mach-es7000/mach_mpparse.h
index 8aa1054..a1dd66f 100644
--- a/include/asm-x86/mach-es7000/mach_mpparse.h
+++ b/include/asm-x86/mach-es7000/mach_mpparse.h
@@ -29,7 +29,7 @@ extern int mps_oem_check(struct mp_config_table *mpc, char
*oem,
static inline int es7000_check_dsdt(void)
{
struct acpi_table_header header;
- memcpy(, 0, sizeof(struct acpi_table_header));
+ memcpy(, (void *)0, sizeof(struct acpi_table_header));
acpi_get_table_header(ACPI_SIG_DSDT, 0, );
if (!strncmp(header.oem_id, "UNISYS", 6))
return 1;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] - [13/15] - remove defconfig ptr comparisons to 0 - init
Remove defconfig ptr comparison to 0
Remove sparse warning: Using plain integer as NULL pointer
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
---
diff --git a/init/do_mounts_rd.c b/init/do_mounts_rd.c
index 3ac5904..46dfd64 100644
--- a/init/do_mounts_rd.c
+++ b/init/do_mounts_rd.c
@@ -212,7 +212,7 @@ int __init rd_load_image(char *from)
}
buf = kmalloc(BLOCK_SIZE, GFP_KERNEL);
- if (buf == 0) {
+ if (!buf) {
printk(KERN_ERR "RAMDISK: could not allocate buffer\n");
goto done;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] - [11/15] - remove defconfig ptr comparisons to 0 - fs/smbfs
Remove defconfig ptr comparison to 0
Remove sparse warning: Using plain integer as NULL pointer
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
---
diff --git a/fs/smbfs/smbiod.c b/fs/smbfs/smbiod.c
index 283c572..fa3b249 100644
--- a/fs/smbfs/smbiod.c
+++ b/fs/smbfs/smbiod.c
@@ -206,7 +206,7 @@ int smbiod_retry(struct smb_sb_info *server)
smb_close_socket(server);
- if (pid == 0) {
+ if (!pid) {
/* FIXME: this is fatal, umount? */
printk(KERN_ERR "smb_retry: no connection process\n");
server->state = CONN_RETRIED;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] - [10/15] - remove defconfig ptr comparisons to 0 - fs/reiserfs
Remove defconfig ptr comparison to 0
Remove sparse warning: Using plain integer as NULL pointer
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
---
diff --git a/fs/reiserfs/do_balan.c b/fs/reiserfs/do_balan.c
index f85c5cf..40786d2 100644
--- a/fs/reiserfs/do_balan.c
+++ b/fs/reiserfs/do_balan.c
@@ -283,7 +283,7 @@ static int balance_leaf(struct tree_balance *tb, struct
item_head *ih, /* item h
return balance_leaf_when_delete(tb, flag);
zeros_num = 0;
- if (flag == M_INSERT && body == 0)
+ if (flag == M_INSERT && !body)
zeros_num = ih_item_len(ih);
pos_in_item = tb->tb_path->pos_in_item;
@@ -1728,7 +1728,7 @@ struct buffer_head *get_FEB(struct tree_balance *tb)
struct buffer_info bi;
for (i = 0; i < MAX_FEB_SIZE; i++)
- if (tb->FEB[i] != 0)
+ if (tb->FEB[i])
break;
if (i == MAX_FEB_SIZE)
diff --git a/fs/reiserfs/fix_node.c b/fs/reiserfs/fix_node.c
index 0ee35c6..af375c6 100644
--- a/fs/reiserfs/fix_node.c
+++ b/fs/reiserfs/fix_node.c
@@ -857,7 +857,7 @@ static int get_lfree(struct tree_balance *tb, int h)
struct buffer_head *l, *f;
int order;
- if ((f = PATH_H_PPARENT(tb->tb_path, h)) == 0 || (l = tb->FL[h]) == 0)
+ if (!(f = PATH_H_PPARENT(tb->tb_path, h)) || !(l = tb->FL[h]))
return 0;
if (f == l)
@@ -878,7 +878,7 @@ static int get_rfree(struct tree_balance *tb, int h)
struct buffer_head *r, *f;
int order;
- if ((f = PATH_H_PPARENT(tb->tb_path, h)) == 0 || (r = tb->FR[h]) == 0)
+ if (!(f = PATH_H_PPARENT(tb->tb_path, h)) || !(r = tb->FR[h]))
return 0;
if (f == r)
diff --git a/fs/reiserfs/namei.c b/fs/reiserfs/namei.c
index b378eea..8867533 100644
--- a/fs/reiserfs/namei.c
+++ b/fs/reiserfs/namei.c
@@ -452,7 +452,7 @@ static int reiserfs_add_entry(struct
reiserfs_transaction_handle *th,
buflen = DEH_SIZE + ROUND_UP(namelen);
if (buflen > sizeof(small_buf)) {
buffer = kmalloc(buflen, GFP_NOFS);
- if (buffer == 0)
+ if (!buffer)
return -ENOMEM;
} else
buffer = small_buf;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] - [8/15] - remove defconfig ptr comparisons to 0 - fs/nfs
Remove defconfig ptr comparison to 0
Remove sparse warning: Using plain integer as NULL pointer
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
---
diff --git a/fs/nfs/callback_xdr.c b/fs/nfs/callback_xdr.c
index 058ade7..935f145 100644
--- a/fs/nfs/callback_xdr.c
+++ b/fs/nfs/callback_xdr.c
@@ -254,7 +254,7 @@ static __be32 encode_attr_change(struct xdr_stream *xdr,
const uint32_t *bitmap,
if (!(bitmap[0] & FATTR4_WORD0_CHANGE))
return 0;
p = xdr_reserve_space(xdr, 8);
- if (unlikely(p == 0))
+ if (unlikely(!p))
return htonl(NFS4ERR_RESOURCE);
p = xdr_encode_hyper(p, change);
return 0;
@@ -267,7 +267,7 @@ static __be32 encode_attr_size(struct xdr_stream *xdr,
const uint32_t *bitmap, u
if (!(bitmap[0] & FATTR4_WORD0_SIZE))
return 0;
p = xdr_reserve_space(xdr, 8);
- if (unlikely(p == 0))
+ if (unlikely(!p))
return htonl(NFS4ERR_RESOURCE);
p = xdr_encode_hyper(p, size);
return 0;
@@ -278,7 +278,7 @@ static __be32 encode_attr_time(struct xdr_stream *xdr,
const struct timespec *ti
__be32 *p;
p = xdr_reserve_space(xdr, 12);
- if (unlikely(p == 0))
+ if (unlikely(!p))
return htonl(NFS4ERR_RESOURCE);
p = xdr_encode_hyper(p, time->tv_sec);
*p = htonl(time->tv_nsec);
diff --git a/fs/nfs/delegation.c b/fs/nfs/delegation.c
index 11833f4..4e93af2 100644
--- a/fs/nfs/delegation.c
+++ b/fs/nfs/delegation.c
@@ -49,7 +49,7 @@ static int nfs_delegation_claim_locks(struct nfs_open_context
*ctx, struct nfs4_
struct file_lock *fl;
int status;
- for (fl = inode->i_flock; fl != 0; fl = fl->fl_next) {
+ for (fl = inode->i_flock; fl; fl = fl->fl_next) {
if (!(fl->fl_flags & (FL_POSIX|FL_FLOCK)))
continue;
if (nfs_file_open_context(fl->fl_file) != ctx)
diff --git a/fs/nfs/idmap.c b/fs/nfs/idmap.c
index d11eb05..c6d4e70 100644
--- a/fs/nfs/idmap.c
+++ b/fs/nfs/idmap.c
@@ -308,7 +308,7 @@ nfs_idmap_name(struct idmap *idmap, struct idmap_hashtable
*h,
mutex_lock(>idmap_im_lock);
he = idmap_lookup_id(h, id);
- if (he != 0) {
+ if (he) {
memcpy(name, he->ih_name, he->ih_namelen);
ret = he->ih_namelen;
goto out;
diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
index 23a9a36..a983637 100644
--- a/fs/nfs/nfs4state.c
+++ b/fs/nfs/nfs4state.c
@@ -781,7 +781,7 @@ static int nfs4_reclaim_locks(struct
nfs4_state_recovery_ops *ops, struct nfs4_s
struct file_lock *fl;
int status = 0;
- for (fl = inode->i_flock; fl != 0; fl = fl->fl_next) {
+ for (fl = inode->i_flock; fl; fl = fl->fl_next) {
if (!(fl->fl_flags & (FL_POSIX|FL_FLOCK)))
continue;
if (nfs_file_open_context(fl->fl_file)->state != state)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] - [9/15] - remove defconfig ptr comparisons to 0 - fs/nfsd
Remove defconfig ptr comparison to 0
Remove sparse warning: Using plain integer as NULL pointer
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
---
diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
index d019918..07b38cf 100644
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -987,7 +987,7 @@ nfsd_vfs_write(struct svc_rqst *rqstp, struct svc_fh *fhp,
struct file *file,
* flushing the data to disk is handled separately below.
*/
- if (file->f_op->fsync == 0) {/* COMMIT3 cannot work */
+ if (!file->f_op->fsync) {/* COMMIT3 cannot work */
stable = 2;
*stablep = 2; /* FILE_SYNC */
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] - [7/15] - remove defconfig ptr comparisons to 0 - fs/lockd
Remove defconfig ptr comparison to 0
Remove sparse warning: Using plain integer as NULL pointer
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
---
diff --git a/fs/lockd/svcshare.c b/fs/lockd/svcshare.c
index 068886d..98548ad 100644
--- a/fs/lockd/svcshare.c
+++ b/fs/lockd/svcshare.c
@@ -71,7 +71,7 @@ nlmsvc_unshare_file(struct nlm_host *host, struct nlm_file
*file,
struct nlm_share*share, **shpp;
struct xdr_netobj *oh = >lock.oh;
- for (shpp = >f_shares; (share = *shpp) != 0; shpp =
>s_next) {
+ for (shpp = >f_shares; (share = *shpp); shpp = >s_next) {
if (share->s_host == host && nlm_cmp_owner(share, oh)) {
*shpp = share->s_next;
kfree(share);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] - [6/15] - remove defconfig ptr comparisons to 0 - fs/jfs
Remove defconfig ptr comparison to 0
Remove sparse warning: Using plain integer as NULL pointer
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
---
diff --git a/fs/jfs/jfs_dtree.c b/fs/jfs/jfs_dtree.c
index df25ecc..eb6ba22 100644
--- a/fs/jfs/jfs_dtree.c
+++ b/fs/jfs/jfs_dtree.c
@@ -284,11 +284,11 @@ static struct dir_table_slot *find_index(struct inode
*ip, u32 index,
release_metapage(*mp);
*mp = NULL;
}
- if (*mp == 0) {
+ if (!(*mp)) {
*lblock = blkno;
*mp = read_index_page(ip, blkno);
}
- if (*mp == 0) {
+ if (!(*mp)) {
jfs_err("free_index: error reading directory table");
return NULL;
}
@@ -413,7 +413,8 @@ static u32 add_index(tid_t tid, struct inode *ip, s64 bn,
int slot)
}
ip->i_size = PSIZE;
- if ((mp = get_index_page(ip, 0)) == 0) {
+ mp = get_index_page(ip, 0);
+ if (!mp) {
jfs_err("add_index: get_metapage failed!");
xtTruncate(tid, ip, 0, COMMIT_PWMAP);
memcpy(_ip->i_dirtable, temp_table,
@@ -461,7 +462,7 @@ static u32 add_index(tid_t tid, struct inode *ip, s64 bn,
int slot)
} else
mp = read_index_page(ip, blkno);
- if (mp == 0) {
+ if (!mp) {
jfs_err("add_index: get/read_metapage failed!");
goto clean_up;
}
@@ -499,7 +500,7 @@ static void free_index(tid_t tid, struct inode *ip, u32
index, u32 next)
dirtab_slot = find_index(ip, index, , );
- if (dirtab_slot == 0)
+ if (!dirtab_slot)
return;
dirtab_slot->flag = DIR_INDEX_FREE;
@@ -526,7 +527,7 @@ static void modify_index(tid_t tid, struct inode *ip, u32
index, s64 bn,
dirtab_slot = find_index(ip, index, mp, lblock);
- if (dirtab_slot == 0)
+ if (!dirtab_slot)
return;
DTSaddress(dirtab_slot, bn);
@@ -552,7 +553,7 @@ static int read_index(struct inode *ip, u32 index,
struct dir_table_slot *slot;
slot = find_index(ip, index, , );
- if (slot == 0) {
+ if (!slot) {
return -EIO;
}
@@ -595,7 +596,7 @@ int dtSearch(struct inode *ip, struct component_name * key,
ino_t * data,
ciKey.name =
(wchar_t *) kmalloc((JFS_NAME_MAX + 1) * sizeof(wchar_t),
GFP_NOFS);
- if (ciKey.name == 0) {
+ if (!ciKey.name) {
rc = -ENOMEM;
goto dtSearch_Exit2;
}
@@ -960,7 +961,7 @@ static int dtSplitUp(tid_t tid,
key.name =
(wchar_t *) kmalloc((JFS_NAME_MAX + 2) * sizeof(wchar_t),
GFP_NOFS);
- if (key.name == 0) {
+ if (!key.name) {
DT_PUTPAGE(smp);
rc = -ENOMEM;
goto dtSplitUp_Exit;
diff --git a/fs/jfs/jfs_imap.c b/fs/jfs/jfs_imap.c
index 3870ba8..9bf29f7 100644
--- a/fs/jfs/jfs_imap.c
+++ b/fs/jfs/jfs_imap.c
@@ -381,7 +381,7 @@ int diRead(struct inode *ip)
/* read the page of disk inode */
mp = read_metapage(ipimap, pageno << sbi->l2nbperpage, PSIZE, 1);
- if (mp == 0) {
+ if (!mp) {
jfs_err("diRead: read_metapage failed");
return -EIO;
}
@@ -654,7 +654,7 @@ int diWrite(tid_t tid, struct inode *ip)
/* read the page of disk inode */
retry:
mp = read_metapage(ipimap, pageno << sbi->l2nbperpage, PSIZE, 1);
- if (mp == 0)
+ if (!mp)
return -EIO;
/* get the pointer to the disk inode */
diff --git a/fs/jfs/jfs_logmgr.c b/fs/jfs/jfs_logmgr.c
index 15a3974..09ecd06 100644
--- a/fs/jfs/jfs_logmgr.c
+++ b/fs/jfs/jfs_logmgr.c
@@ -2347,7 +2347,7 @@ int jfsIOWait(void *arg)
do {
spin_lock_irq(_redrive_lock);
- while ((bp = log_redrive_list) != 0) {
+ while ((bp = log_redrive_list)) {
log_redrive_list = bp->l_redrive_next;
bp->l_redrive_next = NULL;
spin_unlock_irq(_redrive_lock);
diff --git a/fs/jfs/jfs_mount.c b/fs/jfs/jfs_mount.c
index 644429a..7b698f2 100644
--- a/fs/jfs/jfs_mount.c
+++ b/fs/jfs/jfs_mount.c
@@ -147,7 +147,7 @@ int jfs_mount(struct super_block *sb)
*/
if ((sbi->mntflag & JFS_BAD_SAIT) == 0) {
ipaimap2 = diReadSpecial(sb, AGGREGATE_I, 1);
- if (ipaimap2 == 0) {
+ if (!ipaimap2) {
jfs_err("jfs_mount: Faild to read AGGREGATE_I");
rc = -EIO;
goto errout35;
diff --git a/fs/jfs/namei.c b/fs/jfs/namei.c
index 4e0a849..d6e5eba 100644
--- a/fs/jfs/namei.c
[PATCH] - [4/15] - remove defconfig ptr comparisons to 0 - fs/jbd
Remove defconfig ptr comparison to 0
Remove sparse warning: Using plain integer as NULL pointer
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
---
diff --git a/fs/jbd/journal.c b/fs/jbd/journal.c
index 5d14243..0459657 100644
--- a/fs/jbd/journal.c
+++ b/fs/jbd/journal.c
@@ -1619,14 +1619,14 @@ static int journal_init_journal_head_cache(void)
{
int retval;
- J_ASSERT(journal_head_cache == 0);
+ J_ASSERT(!journal_head_cache);
journal_head_cache = kmem_cache_create("journal_head",
sizeof(struct journal_head),
0, /* offset */
SLAB_TEMPORARY, /* flags */
NULL); /* ctor */
retval = 0;
- if (journal_head_cache == 0) {
+ if (!journal_head_cache) {
retval = -ENOMEM;
printk(KERN_EMERG "JBD: no memory for journal_head cache\n");
}
diff --git a/fs/jbd/revoke.c b/fs/jbd/revoke.c
index ad2eacf..d5f8eee 100644
--- a/fs/jbd/revoke.c
+++ b/fs/jbd/revoke.c
@@ -173,13 +173,13 @@ int __init journal_init_revoke_caches(void)
0,
SLAB_HWCACHE_ALIGN|SLAB_TEMPORARY,
NULL);
- if (revoke_record_cache == 0)
+ if (!revoke_record_cache)
return -ENOMEM;
revoke_table_cache = kmem_cache_create("revoke_table",
sizeof(struct jbd_revoke_table_s),
0, SLAB_TEMPORARY, NULL);
- if (revoke_table_cache == 0) {
+ if (!revoke_table_cache) {
kmem_cache_destroy(revoke_record_cache);
revoke_record_cache = NULL;
return -ENOMEM;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] - [5/15] - remove defconfig ptr comparisons to 0 - fs/jbd2
Remove defconfig ptr comparison to 0
Remove sparse warning: Using plain integer as NULL pointer
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
---
diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
index 6ddc553..ca74850 100644
--- a/fs/jbd2/journal.c
+++ b/fs/jbd2/journal.c
@@ -218,7 +218,7 @@ static int jbd2_journal_start_thread(journal_t *journal)
if (IS_ERR(t))
return PTR_ERR(t);
- wait_event(journal->j_wait_done_commit, journal->j_task != 0);
+ wait_event(journal->j_wait_done_commit, journal->j_task);
return 0;
}
@@ -230,7 +230,7 @@ static void journal_kill_thread(journal_t *journal)
while (journal->j_task) {
wake_up(>j_wait_commit);
spin_unlock(>j_state_lock);
- wait_event(journal->j_wait_done_commit, journal->j_task == 0);
+ wait_event(journal->j_wait_done_commit, !journal->j_task);
spin_lock(>j_state_lock);
}
spin_unlock(>j_state_lock);
@@ -1629,14 +1629,14 @@ static int journal_init_jbd2_journal_head_cache(void)
{
int retval;
- J_ASSERT(jbd2_journal_head_cache == 0);
+ J_ASSERT(!jbd2_journal_head_cache);
jbd2_journal_head_cache = kmem_cache_create("jbd2_journal_head",
sizeof(struct journal_head),
0, /* offset */
0, /* flags */
NULL); /* ctor */
retval = 0;
- if (jbd2_journal_head_cache == 0) {
+ if (!jbd2_journal_head_cache) {
retval = -ENOMEM;
printk(KERN_EMERG "JBD: no memory for journal_head cache\n");
}
@@ -1662,14 +1662,14 @@ static struct journal_head
*journal_alloc_journal_head(void)
atomic_inc(_journal_heads);
#endif
ret = kmem_cache_alloc(jbd2_journal_head_cache, GFP_NOFS);
- if (ret == 0) {
+ if (!ret) {
jbd_debug(1, "out of memory for journal_head\n");
if (time_after(jiffies, last_warning + 5*HZ)) {
printk(KERN_NOTICE "ENOMEM in %s, retrying.\n",
__FUNCTION__);
last_warning = jiffies;
}
- while (ret == 0) {
+ while (!ret) {
yield();
ret = kmem_cache_alloc(jbd2_journal_head_cache,
GFP_NOFS);
}
diff --git a/fs/jbd2/revoke.c b/fs/jbd2/revoke.c
index 3595fd4..ec81511 100644
--- a/fs/jbd2/revoke.c
+++ b/fs/jbd2/revoke.c
@@ -172,13 +172,13 @@ int __init jbd2_journal_init_revoke_caches(void)
jbd2_revoke_record_cache = kmem_cache_create("jbd2_revoke_record",
sizeof(struct jbd2_revoke_record_s),
0, SLAB_HWCACHE_ALIGN, NULL);
- if (jbd2_revoke_record_cache == 0)
+ if (!jbd2_revoke_record_cache)
return -ENOMEM;
jbd2_revoke_table_cache = kmem_cache_create("jbd2_revoke_table",
sizeof(struct jbd2_revoke_table_s),
0, 0, NULL);
- if (jbd2_revoke_table_cache == 0) {
+ if (!jbd2_revoke_table_cache) {
kmem_cache_destroy(jbd2_revoke_record_cache);
jbd2_revoke_record_cache = NULL;
return -ENOMEM;
diff --git a/fs/jbd2/transaction.c b/fs/jbd2/transaction.c
index b1fcf2b..036e7ef 100644
--- a/fs/jbd2/transaction.c
+++ b/fs/jbd2/transaction.c
@@ -1164,7 +1164,7 @@ int jbd2_journal_dirty_metadata(handle_t *handle, struct
buffer_head *bh)
}
/* That test should have eliminated the following case: */
- J_ASSERT_JH(jh, jh->b_frozen_data == 0);
+ J_ASSERT_JH(jh, !jh->b_frozen_data);
JBUFFER_TRACE(jh, "file as BJ_Metadata");
spin_lock(>j_list_lock);
@@ -1512,7 +1512,7 @@ void __jbd2_journal_temp_unlink_buffer(struct
journal_head *jh)
J_ASSERT_JH(jh, jh->b_jlist < BJ_Types);
if (jh->b_jlist != BJ_None)
- J_ASSERT_JH(jh, transaction != 0);
+ J_ASSERT_JH(jh, transaction);
switch (jh->b_jlist) {
case BJ_None:
@@ -1581,11 +1581,11 @@ __journal_try_to_free_buffer(journal_t *journal, struct
buffer_head *bh)
if (buffer_locked(bh) || buffer_dirty(bh))
goto out;
- if (jh->b_next_transaction != 0)
+ if (jh->b_next_transaction)
goto out;
spin_lock(>j_list_lock);
- if (jh->b_transaction != 0 && jh->b_cp_transaction == 0) {
+ if (jh->b_transaction && !jh->b_cp_transaction) {
if (jh->b_jlist == BJ_SyncData || jh->b_jlist == BJ_Locked) {
/* A written-back ordered data buffer */
JBUFFER_TRACE(jh, "release data");
@@ -1593,7 +1593,7 @@
[PATCH] - [3/15] - remove defconfig ptr comparisons to 0 - drivers/scsi/aic7xxx
Remove defconfig ptr comparison to 0
Remove sparse warning: Using plain integer as NULL pointer
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
---
diff --git a/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c
b/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c
index 4488946..223bad1 100644
--- a/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c
+++ b/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c
@@ -310,7 +310,7 @@ ahc_linux_pci_reserve_io_region(struct ahc_softc *ahc,
u_long *base)
*base = pci_resource_start(ahc->dev_softc, 0);
if (*base == 0)
return (ENOMEM);
- if (request_region(*base, 256, "aic7xxx") == 0)
+ if (!request_region(*base, 256, "aic7xxx"))
return (ENOMEM);
return (0);
}
@@ -327,7 +327,7 @@ ahc_linux_pci_reserve_mem_region(struct ahc_softc *ahc,
start = pci_resource_start(ahc->dev_softc, 1);
if (start != 0) {
*bus_addr = start;
- if (request_mem_region(start, 0x1000, "aic7xxx") == 0)
+ if (!request_mem_region(start, 0x1000, "aic7xxx"))
error = ENOMEM;
if (error == 0) {
*maddr = ioremap_nocache(start, 256);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/15] - remove defconfig ptr comparisons to 0 - drivers/net
Remove defconfig ptr comparison to 0
Remove sparse warning: Using plain integer as NULL pointer
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index da767d3..cec3cb4 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -2495,7 +2495,7 @@ reuse_rx:
}
#ifdef BCM_VLAN
- if ((status & L2_FHDR_STATUS_L2_VLAN_TAG) && (bp->vlgrp != 0)) {
+ if ((status & L2_FHDR_STATUS_L2_VLAN_TAG) && bp->vlgrp) {
vlan_hwaccel_receive_skb(skb, bp->vlgrp,
rx_hdr->l2_fhdr_vlan_tag);
}
@@ -5134,7 +5134,7 @@ bnx2_start_xmit(struct sk_buff *skb, struct net_device
*dev)
vlan_tag_flags |= TX_BD_FLAGS_TCP_UDP_CKSUM;
}
- if (bp->vlgrp != 0 && vlan_tx_tag_present(skb)) {
+ if (bp->vlgrp && vlan_tx_tag_present(skb)) {
vlan_tag_flags |=
(TX_BD_FLAGS_VLAN_TAG | (vlan_tx_tag_get(skb) << 16));
}
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 4942f7d..b189c47 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -12576,7 +12576,7 @@ static int __devinit tg3_init_one(struct pci_dev *pdev,
tg3reg_len = pci_resource_len(pdev, 2);
tp->aperegs = ioremap_nocache(tg3reg_base, tg3reg_len);
- if (tp->aperegs == 0UL) {
+ if (!tp->aperegs) {
printk(KERN_ERR PFX "Cannot map APE registers, "
"aborting.\n");
err = -ENOMEM;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] - [1/15] - remove defconfig ptr comparisons to 0 - arch/x86
Remove defconfig ptr comparison to 0
Remove sparse warning: Using plain integer as NULL pointer
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
---
diff --git a/arch/x86/boot/printf.c b/arch/x86/boot/printf.c
index 1a09f93..953224e 100644
--- a/arch/x86/boot/printf.c
+++ b/arch/x86/boot/printf.c
@@ -54,7 +54,7 @@ static char *number(char *str, long num, int base, int size,
int precision,
if (type & LEFT)
type &= ~ZEROPAD;
if (base < 2 || base > 36)
- return 0;
+ return NULL;
c = (type & ZEROPAD) ? '0' : ' ';
sign = 0;
if (type & SIGN) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/28] cpu alloc: The allocator
On Tue, 13 Nov 2007, David Miller wrote: > From: Christoph Lameter <[EMAIL PROTECTED]> > Date: Tue, 13 Nov 2007 17:57:15 -0800 (PST) > > > H. cpu_alloc really does not need zeroed data. Just an address > > fixed by the compiler where stuff can be put. Can the loader do that > > somehow? > > Yes, and I think IA64 uses such a scheme for it's 64KB fixed > per-cpu TLB mapping thing doesn't it? The per cpu TLB mapping is virtually mapped. The real memory allocation behind it occurs dynamically from bootmem. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] - [0/15] - remove defconfig ptr comparisons to 0
Remove defconfig ptr comparison to 0 Remove sparse warning: Using plain integer as NULL pointer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/28] cpu alloc: The allocator
From: Christoph Lameter <[EMAIL PROTECTED]> Date: Tue, 13 Nov 2007 17:57:15 -0800 (PST) > H. cpu_alloc really does not need zeroed data. Just an address > fixed by the compiler where stuff can be put. Can the loader do that > somehow? Yes, and I think IA64 uses such a scheme for it's 64KB fixed per-cpu TLB mapping thing doesn'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: [patch 01/28] cpu alloc: The allocator
From: Christoph Lameter <[EMAIL PROTECTED]> Date: Tue, 13 Nov 2007 17:50:24 -0800 (PST) > On Tue, 13 Nov 2007, David Miller wrote: > > > BTW, I'm going to stop testing your patches on sparc64 for > > a while until you start to make me feel like you understand > > that ignoring the BSS bloat issue is bad. > > Well this is just the fallback. How can I avoid this and still keep a > constant? Add a new segment to vmlinux.lds.S? I'm not so sure. The idea about doling out vmalloc space seemed the most promising. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] sata_nv: fix ADMA ATAPI issues with memory over 4GB
Mark Lord wrote: > Tejun Heo wrote: >> Robert Hancock wrote: >>> Tejun Heo wrote: > .. >>> Yes, it should likely do something with these return values. Though >>> theoretically it shouldn't fail, since the DMA mask is either 32-bit, >>> which shouldn't fail, or one that was successfully set before. Also I >>> don't think the SCSI layer actually checks the slave_config return >>> value.. sigh. >> >> Then please at least add WARN_ON() && another reason why allocating / >> deallocating resources from ->slave_config isn't such a good idea. > .. > > The entire point of "slave_configure" is to provide a point for the LLD > to do per-device data structure allocation/init. > > And yes, SCSI does check the return code. Whether the code around that > check > is buggy or not is another question, but it's always worked for me. I see but I still prefer having PRD, pad buf allocation/release in ->port_start/stop() primarily for consistency. Robert, what do you think? -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2: Network commit causes SLUB performance regression with tbench
From: Nick Piggin <[EMAIL PROTECTED]> Date: Tue, 13 Nov 2007 22:41:58 +1100 > On Tuesday 13 November 2007 06:44, Christoph Lameter wrote: > > On Sat, 10 Nov 2007, Nick Piggin wrote: > > > BTW. your size-2048 kmalloc cache is order-1 in the default setup, > > > wheras kmalloc(1024) or kmalloc(4096) will be order-0 allocations. And > > > SLAB also uses order-0 for size-2048. It would be nice if SLUB did the > > > same... > > > > You can try to see the effect that order 0 would have by booting with > > > > slub_max_order=0 > > Yeah, that didn't help much, but in general I think it would give > more consistent and reliable behaviour from slub. Just a note that I'm not ignoring this issue, I just don't have time to get to it yet. I suspect the issue is about having a huge skb->data linear area for TCP sends over loopback. We're likely getting a much smaller skb->data linear data area after the patch in question, the rest using the sk_buff scatterlist pages which are a little bit more expensive to process. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/28] cpu alloc: The allocator
On Tue, 13 Nov 2007, David Miller wrote: > Yes, I've run into similar problems with lockdep as well. > I had to build an ultra minimalized kernel to get it to > boot on my Niagara boxes. H. cpu_alloc really does not need zeroed data. Just an address fixed by the compiler where stuff can be put. Can the loader do that somehow? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] New Kernel Bugs
From: Russell King <[EMAIL PROTECTED]> Date: Tue, 13 Nov 2007 23:40:33 + > ARM ep93xx defconfig has been broken since 2.6.23-git1 due to: > > drivers/net/arm/ep93xx_eth.c:420: error: implicit declaration of function > '__netif_rx_schedule_prep' > > caused by: [NET]: Make NAPI polling independent of struct net_device objects. > > ARM netx defconfig has been broken since 2.6.23-git1 due to: > > drivers/net/netx-eth.c: In function 'netx_eth_hard_start_xmit': > drivers/net/netx-eth.c:131: error: 'dev' undeclared (first use in this > function) > drivers/net/netx-eth.c:131: error: (Each undeclared identifier is reported > only once > drivers/net/netx-eth.c:131: error: for each function it appears in.) > drivers/net/netx-eth.c: In function 'netx_eth_receive': > drivers/net/netx-eth.c:158: error: 'dev' undeclared (first use in this > function) > > caused by: [NET] drivers/net: statistics cleanup #1 -- save memory and shrink > code > I'll fix these up, thanks for the report. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] New Kernel Bugs
From: Andrew Morton <[EMAIL PROTECTED]> Date: Tue, 13 Nov 2007 14:32:01 -0800 > On Tue, 13 Nov 2007 22:18:01 + Russell King <[EMAIL PROTECTED]> wrote: > > > Find some other mailing list; I'm not hosting *nor* am I willing to run a > > non-subscribers only mailing list. Period. Not negotiable, so don't even > > try to change my mind. > > Making a list subscribers-only will cause some bug reports to be lost. > > Tradeoffs are involved, against which decisions must be made. You have > made yours. Russell doesn't have to worry any more, he doesn't have to host it, and he doesn't have to be willing to run a non-subscribers-only mailing list. Because I am. I've created [EMAIL PROTECTED] Enjoy. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/28] cpu alloc: The allocator
From: Andi Kleen <[EMAIL PROTECTED]> Date: Wed, 14 Nov 2007 02:06:28 +0100 > David Miller <[EMAIL PROTECTED]> writes: > > > > The problem is that for the non-virtualized case this patch bloats up > > the BSS section to be more than 8MB in size. Sparc64 kernel images > > cannot be more than 8MB in size total due to various boot loader and > > firmware limitations. > > I recently ran into a similar problem with x86-64 and large BSS from > lockdep conflicting with a 16MB kdump kernel. Solution was to do > another early allocator before bootmem and then move the tables into > there. Yes, I've run into similar problems with lockdep as well. I had to build an ultra minimalized kernel to get it to boot on my Niagara boxes. I think I even looked at the same lockdep code, and I'd appreciate it if you'd submit your fix for this if you haven't already. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [perfmon] Re: [perfmon2] perfmon2 merge news
On Tue, Nov 13, 2007 at 04:28:52PM -0800, Philip Mucci wrote: > I know you don't want to hear this, but we actually use all of the > features of perfmon, because a) we wanted to use the best methods That is hard to believe. But let's go for it temporarily for the argument. Can you instead prioritize features. What is most essential, what is important, what is just nice to have, what is rarely used? > Note that PAPI is just middleware. The tools built upon it are what Surely the tools on top cannot use more than the middleware provides. > - providing virtualized 64-bit counters per-thread > - providing notification (buffered or non) on interrupt/overflow of > the above. Ok that makes sense and should be possible with a reasonable simple interface. > If you'd like to outline further what you'd like to hear from the > community, I can arrange that. I seem to remember going through this > once before, but I'd be happy to do it again. For reference, here's a > quick list from memory of some of the tools in active use and built > on this infrastructure. These are used heavily around the globe. Please list concrete features, throwing around random names is not useful. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 01/28] cpu alloc: The allocator
On Tue, 13 Nov 2007, David Miller wrote: > I'm surprised this is your reaction instead of "oh damn, sorry > I bloated up the kernel image size by 8mb, I'll find a way to > fix that." Well I found a way to fix that and its in the patch... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/28] cpu alloc: The allocator
On Tue, 13 Nov 2007, David Miller wrote: > BTW, I'm going to stop testing your patches on sparc64 for > a while until you start to make me feel like you understand > that ignoring the BSS bloat issue is bad. Well this is just the fallback. How can I avoid this and still keep a constant? Add a new segment to vmlinux.lds.S? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 06/11] Text Edit Lock - Alternative code for x86 (updated)
Text Edit Lock - Alternative code for x86
Fix a memcpy that should be a text_poke (in apply_alternatives).
Use kernel_wp_save/kernel_wp_restore in text_poke to support DEBUG_RODATA
correctly and so the CPU HOTPLUG special case can be removed.
clflush all the cachelines touched by text_poke.
Add text_poke_early, for alternatives and paravirt boot-time and module load
time patching.
Notes:
- the clflush is left there, even though Andi Kleen says it breaks some
architecture. The proper fix is to detect these CPUs and set the
cpu_has_clflush flag appropriately. It does not belong here.
- we use a macro for kernel_wp_save/restore to mimic local_irq_save/restore: the
argument is passed without &.
Changelog:
- Fix text_set and text_poke alignment check (mixed up bitwise and and or)
- Remove text_set
- Use the new macro INIT_ARRAY() to stop polluting the C files with ({ })
brackets (which breaks some c parsers in editors).
- Export add_nops, so it can be used by others.
- Remove x86 test for "wp_works_ok", it will just be ignored by the architecture
if not supported.
- Document text_poke_early.
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
CC: Andi Kleen <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
---
arch/x86/kernel/alternative.c| 78 +--
include/asm-x86/alternative_32.h | 37 ++
include/asm-x86/alternative_64.h | 39 +++
3 files changed, 132 insertions(+), 22 deletions(-)
Index: linux-2.6-lttng/arch/x86/kernel/alternative.c
===
--- linux-2.6-lttng.orig/arch/x86/kernel/alternative.c 2007-11-13
13:43:20.0 -0500
+++ linux-2.6-lttng/arch/x86/kernel/alternative.c 2007-11-13
20:40:54.0 -0500
@@ -27,6 +27,58 @@ __setup("smp-alt-boot", bootonly);
#define smp_alt_once 1
#endif
+/*
+ * Warning:
+ * When you use this code to patch more than one byte of an instruction
+ * you need to make sure that other CPUs cannot execute this code in parallel.
+ * Also no thread must be currently preempted in the middle of these
+ * instructions. And on the local CPU you need to be protected again NMI or
MCE
+ * handlers seeing an inconsistent instruction while you patch.
+ * Warning: read_cr0 is modified by paravirt, this is why we have _early
+ * versions. They are not in the __init section because they can be used at
+ * module load time.
+ */
+static inline void text_sync(void *addr, size_t len)
+{
+ void *faddr;
+
+ sync_core();
+ /* FIXME Could also do a CLFLUSH here to speed up CPU recovery; but
+ that causes hangs on some VIA CPUs. */
+ /* Not strictly needed, but can speed CPU recovery up. */
+ if (0 && cpu_has_clflush)
+ for (faddr = addr; faddr < addr + len;
+ faddr += boot_cpu_data.x86_clflush_size)
+ asm("clflush (%0) " :: "r" (faddr) : "memory");
+}
+
+void *text_poke_early(void *addr, const void *opcode, size_t len)
+{
+ memcpy(addr, opcode, len);
+ text_sync(addr, len);
+ return addr;
+}
+
+/*
+ * Only atomic text poke/set should be allowed when not doing early patching.
+ * It means the size must be writable atomically and the address must be
aligned
+ * in a way that permits an atomic write.
+ */
+
+void *__kprobes text_poke(void *addr, const void *opcode, size_t len)
+{
+ unsigned long cr0;
+
+ BUG_ON(len > sizeof(long));
+ BUG_ONlong)addr + len - 1) & ~(sizeof(long) - 1))
+ - ((long)addr & ~(sizeof(long) - 1)));
+ kernel_wp_save(cr0);
+ memcpy(addr, opcode, len);
+ kernel_wp_restore(cr0);
+ text_sync(addr, len);
+ return addr;
+}
+
static int debug_alternative;
static int __init debug_alt(char *str)
@@ -173,7 +225,7 @@ static const unsigned char*const * find_
#endif /* CONFIG_X86_64 */
/* Use this to add nops to a buffer, then text_poke the whole buffer. */
-static void add_nops(void *insns, unsigned int len)
+void add_nops(void *insns, unsigned int len)
{
const unsigned char *const *noptable = find_nop_table();
@@ -186,6 +238,7 @@ static void add_nops(void *insns, unsign
len -= noplen;
}
}
+EXPORT_SYMBOL_GPL(add_nops);
extern struct alt_instr __alt_instructions[], __alt_instructions_end[];
extern u8 *__smp_locks[], *__smp_locks_end[];
@@ -219,7 +272,7 @@ void apply_alternatives(struct alt_instr
memcpy(insnbuf, a->replacement, a->replacementlen);
add_nops(insnbuf + a->replacementlen,
a->instrlen - a->replacementlen);
- text_poke(instr, insnbuf, a->instrlen);
+ text_poke_early(instr, insnbuf, a->instrlen);
}
}
@@ -234,7 +287,8 @@ static void alternatives_smp_lock(u8 **s
continue;
if (*ptr > text_end)
continue;
-
Re: [patch 5/8] Immediate Values - x86 Optimization (update 2)
Immediate Values - x86 Optimization
x86 optimization of the immediate values which uses a movl with code patching
to set/unset the value used to populate the register used as variable source.
Changelog:
- Use text_poke_early with cr0 WP save/restore to patch the bypass. We are doing
non atomic writes to a code region only touched by us (nobody can execute it
since we are protected by the immediate_mutex).
- Put immediate_set and _immediate_set in the architecture independent header.
- Use $0 instead of %2 with (0) operand.
- Add x86_64 support, ready for i386+x86_64 -> x86 merge.
- Use asm-x86/asm.h.
Ok, so the most flexible solution that I see, that should fit for both
i386 and x86_64 would be :
1 byte : "=Q" : Any register accessible as rh: a, b, c, and d.
2, 4 bytes : "=R" : Legacy register—the eight integer registers available
on all i386 processors (a, b, c, d, si, di, bp, sp). 8
bytes : (only for x86_64)
"=r" : A register operand is allowed provided that it is in a
general register.
That should make sure x86_64 won't try to use REX prefixed opcodes for
1, 2 and 4 bytes values.
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
CC: Andi Kleen <[EMAIL PROTECTED]>
CC: "H. Peter Anvin" <[EMAIL PROTECTED]>
CC: Chuck Ebbert <[EMAIL PROTECTED]>
CC: Christoph Hellwig <[EMAIL PROTECTED]>
CC: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/x86/Kconfig.i386 |3
arch/x86/Kconfig.x86_64 |3
arch/x86/kernel/Makefile_32 |1
arch/x86/kernel/Makefile_64 |1
arch/x86/kernel/immediate.c | 330
arch/x86/kernel/traps_32.c | 10 -
include/asm-x86/immediate.h | 109 ++
7 files changed, 453 insertions(+), 4 deletions(-)
Index: linux-2.6-lttng/arch/x86/kernel/Makefile_32
===
--- linux-2.6-lttng.orig/arch/x86/kernel/Makefile_322007-11-13
17:06:16.0 -0500
+++ linux-2.6-lttng/arch/x86/kernel/Makefile_32 2007-11-13 20:12:34.0
-0500
@@ -34,6 +34,7 @@ obj-$(CONFIG_KPROBES) += kprobes_32.o
obj-$(CONFIG_MODULES) += module_32.o
obj-y += sysenter_32.o vsyscall_32.o
obj-$(CONFIG_ACPI_SRAT)+= srat_32.o
+obj-$(CONFIG_IMMEDIATE)+= immediate.o
obj-$(CONFIG_EFI) += efi_32.o efi_stub_32.o
obj-$(CONFIG_DOUBLEFAULT) += doublefault_32.o
obj-$(CONFIG_VM86) += vm86_32.o
Index: linux-2.6-lttng/arch/x86/kernel/traps_32.c
===
--- linux-2.6-lttng.orig/arch/x86/kernel/traps_32.c 2007-11-13
17:06:16.0 -0500
+++ linux-2.6-lttng/arch/x86/kernel/traps_32.c 2007-11-13 20:12:34.0
-0500
@@ -544,7 +544,7 @@ fastcall void do_##name(struct pt_regs *
}
DO_VM86_ERROR_INFO( 0, SIGFPE, "divide error", divide_error, FPE_INTDIV,
regs->eip)
-#ifndef CONFIG_KPROBES
+#if !defined(CONFIG_KPROBES) && !defined(CONFIG_IMMEDIATE)
DO_VM86_ERROR( 3, SIGTRAP, "int3", int3)
#endif
DO_VM86_ERROR( 4, SIGSEGV, "overflow", overflow)
@@ -786,7 +786,7 @@ void restart_nmi(void)
acpi_nmi_enable();
}
-#ifdef CONFIG_KPROBES
+#if defined(CONFIG_KPROBES) || defined(CONFIG_IMMEDIATE)
fastcall void __kprobes do_int3(struct pt_regs *regs, long error_code)
{
trace_hardirqs_fixup();
@@ -794,8 +794,10 @@ fastcall void __kprobes do_int3(struct p
if (notify_die(DIE_INT3, "int3", regs, error_code, 3, SIGTRAP)
== NOTIFY_STOP)
return;
- /* This is an interrupt gate, because kprobes wants interrupts
- disabled. Normal trap handlers don't. */
+ /*
+* This is an interrupt gate, because kprobes and immediate values wants
+* interrupts disabled. Normal trap handlers don't.
+*/
restore_interrupts(regs);
do_trap(3, SIGTRAP, "int3", 1, regs, error_code, NULL);
}
Index: linux-2.6-lttng/include/asm-x86/immediate.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6-lttng/include/asm-x86/immediate.h 2007-11-13 20:16:05.0
-0500
@@ -0,0 +1,109 @@
+#ifndef _ASM_I386_IMMEDIATE_H
+#define _ASM_I386_IMMEDIATE_H
+
+/*
+ * Immediate values. i386 architecture optimizations.
+ *
+ * (C) Copyright 2006 Mathieu Desnoyers <[EMAIL PROTECTED]>
+ *
+ * This file is released under the GPLv2.
+ * See the file COPYING for more details.
+ */
+
+#include
+
+struct __immediate {
+ long var; /* Pointer to the identifier variable of the
+* immediate value
+*/
+ long immediate; /*
+* Pointer to the memory location of the
+* immediate value within the instruction.
+*/
+ long size; /*
Re: [PATCH 0/5][RFC] Physical PCI slot objects
Hi Gary, * Gary Hade <[EMAIL PROTECTED]>: > On Tue, Nov 13, 2007 at 01:11:02PM -0700, Matthew Wilcox wrote: > > On Tue, Nov 13, 2007 at 10:51:22AM -0800, Greg KH wrote: > > > Ok, again, I want to see the IBM people sign off on this, after testing > > > on all of their machines, before I'll consider this, as I know the IBM > > > acpi tables are "odd". > > > > That seems a little higher standard than patches are normally held to. > > How about the patches get sent to the appropriate people at IBM (who are > > they?) > > I be one of them. :) I have been involved in many (but not all) > of IBM's x86 based (IBM System x) servers with hotplug capable > PCI slots. I have mostly worked on 'acpiphp' associated issues. Thanks for testing the series. It's much appreciated. > Have you possibly considered a kernel option as a kinder and > gentler way of introducing the changes? That is a good idea. I will work on that. > > IBM x3850 > Slots 1-2: PCI-X under PCI root bridges > Slots 3-6: PCIe under transparent P2P bridges > Slot 1: PCI-X - populated > Slot 2: PCI-X - !populated > Slot 3: PCIe - populated > Slot 4: PCIe - !populated > Slot 5: PCIe - !populated > Slot 6: PCIe - populated > > result is with 2.6.24-rc2 plus all 4 proposed patches Silly question, but I have to ask. :) I sent out 5 patches -- is this simply a typo on your part, or did you only apply 4/5 patches? > problem: acpiphp failed to register empty PCIe slots 4 and 5 Ok, so acpiphp wasn't going to register those slots anyway, since they are empty. It would have bailed out after not seeing _ADR or _EJ0 on those slots. The acpi-pci-slot driver created those slots anyway, which is one of the points of the patch -- to create sysfs entries even for empty slots. > acpiphp_glue: found PCI-to-PCI bridge at PCI :0f:00.0 This is the real address of slot 4. > acpiphp_glue: found ACPI PCI Hotplug slot 4 at PCI :10:00 > acpiphp: pci_hp_register failed with error -17 > acpiphp_glue: acpiphp_register_hotplug_slot failed(err code = 0xffef) [repeated 7x] We saw this message 8x, once for each SxFy object under your p2p bridge. I actually somewhat did expect to see this error message (hence the RFC part of my patch ;) I currently don't have a good way to determine if we've already seen an empty slot under a p2p bridge, so we try to register every SxFy object. Of course, a /sys/bus/pci/slots/4/ entry already exists, so that's why we're getting -17 (-EEXIST). > acpiphp_glue: found PCI-to-PCI bridge at PCI :14:00.0 > acpiphp_glue: found ACPI PCI Hotplug slot 5 at PCI :15:00 > acpiphp: pci_hp_register failed with error -17 > acpiphp_glue: acpiphp_register_hotplug_slot failed(err code = 0xffef) Same explanation as above. > # find /sys/bus/pci/slots > /sys/bus/pci/slots [snip] > /sys/bus/pci/slots/4 > /sys/bus/pci/slots/4/address > /sys/bus/pci/slots/5 > /sys/bus/pci/slots/5/address Arguably, the right thing happened here. We got entries for empty slots, and we know their addresses. If anyone can clue me in on a better way to implement patch 4/5 in my series so that we're not seeing those multiple attempts to register slots under p2p bridges, I'd love to hear your ideas. Thanks again for testing. /ac - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/28] cpu alloc: The allocator
BTW, I'm going to stop testing your patches on sparc64 for a while until you start to make me feel like you understand that ignoring the BSS bloat issue is bad. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: stuck nfsd processes with 2.6.24-rc2
On Tue, 13 Nov 2007, Christian Kujau wrote:
Ah, I forgot about that. Will do as soon as I get a working kernel again. I'm
in the middle of git-bisecting and I had to mark the last 2 versions as "bad"
but only because they 1) Oopsed during boot or 2) could not load the kernel
image:
Same again: after 3 working versions I have to mark yet another one as
"bad" - not because the NFS bug showed up, but I was unable to boot again
("linux 'zimage' kernel too big" message again). So now I am at:
-
git-bisect start
# bad: [6e800af233e0bdf108efb7bd23c11ea6fa34cdeb] ACPI: add documentation for
deprecated /proc/acpi/battery in ACPI_PROCFS
git-bisect bad 6e800af233e0bdf108efb7bd23c11ea6fa34cdeb
# good: [bbf25010f1a6b761914430f5fca081ec8c7accd1] Linux 2.6.23
git-bisect good bbf25010f1a6b761914430f5fca081ec8c7accd1
# good: [fba956c46a72f9e7503fd464ffee43c632307e31] Map volume and brightness
events on thinkpads
git-bisect good fba956c46a72f9e7503fd464ffee43c632307e31
# bad: [7b1915a989ea4d426d0fd98974ab80f30ef1d779] mm/oom_kill.c: Use
list_for_each_entry instead of list_for_each
git-bisect bad 7b1915a989ea4d426d0fd98974ab80f30ef1d779
# bad: [c223701cf6c706f42840631c1ca919a18e6e2800] ide: add "hdx=nodma" kernel
parameter
git-bisect bad c223701cf6c706f42840631c1ca919a18e6e2800
# good: [1d677a6dfaac1d1cf51a7f58847077240985faf2] pm3fb: hardware cursor
support
git-bisect good 1d677a6dfaac1d1cf51a7f58847077240985faf2
# good: [291702f017efdfe556cb87b8530eb7d1ff08cbae] [ALSA] Support ASUS P701
eeepc [0x1043 0x82a1] support
git-bisect good 291702f017efdfe556cb87b8530eb7d1ff08cbae
# good: [92d15c2ccbb3e31a3fc71ad28fdb55e1319383c0] Merge branch 'for-linus' of
git://git.kernel.dk/data/git/linux-2.6-block
git-bisect good 92d15c2ccbb3e31a3fc71ad28fdb55e1319383c0
# bad: [f77bf01425b11947eeb3b5b54685212c302741b8] kbuild: introduce ccflags-y,
asflags-y and ldflags-y
git-bisect bad f77bf01425b11947eeb3b5b54685212c302741b8
-
I'm not sure wether it's sane to continue at all ("only 19 revisions
left!"); but this has to wait until tomorrow anyway...
@Bruce: sysrq-t will have to wait too, sorry.
thanks for any ideas,
Christian.
--
BOFH excuse #70:
nesting roaches shorted out the ether cable
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/28] cpu alloc: The allocator
From: Christoph Lameter <[EMAIL PROTECTED]> Date: Tue, 13 Nov 2007 14:20:02 -0800 (PST) > On Tue, 13 Nov 2007, David Miller wrote: > > > Yes, I could add virtualized area support to sparc64, but we cannot > > impose this on every platform. > > Other platforms do not have the 8MB restriction nor do they have so many > processors. sparc32 has the same limitations, nobody is going to implement the virt stuff there. > Here is the draft of a virtual cpu area implementation for sparc64. Uses > the VMEMMAP chunks: This doesn't avoid the core problem. Bloating up the BSS like that is bad, end enforcing a virt implementation to avoid that is an anti-social way to go about implementing this feature. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/28] cpu alloc: The allocator
From: Christoph Lameter <[EMAIL PROTECTED]> Date: Tue, 13 Nov 2007 14:00:45 -0800 (PST) > On Tue, 13 Nov 2007, Eric Dumazet wrote: > > > Once you add in mm/vmalloc.c all needed helpers, no need to use BSS Megablob > > anymore ? > > Well I think all of this can be avoided by simply copying the existing > vmemmap helper functions and providing a virtual address for sparc64. I intend to do that in the end, but you miss my point. Requiring this is unreasonable. And nobody is going to do the virt stuff for platforms like sparc32. And I do mean nobody. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/28] cpu alloc: The allocator
From: Christoph Lameter <[EMAIL PROTECTED]> Date: Tue, 13 Nov 2007 13:40:19 -0800 (PST) > On Tue, 13 Nov 2007, David Miller wrote: > > > One thing you could do is simply use a vmalloc allocation in the > > non-virtualized case. > > Yuck. Meaning to add more crappy code. The bss limitations to 8M is a bit > strange though. Do other platforms have the same issues? sparc32 has the same limit. I'm surprised this is your reaction instead of "oh damn, sorry I bloated up the kernel image size by 8mb, I'll find a way to fix that." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] New Kernel Bugs
Please stop cross-posting this thread at least to linux-pcmcia until your post is relevant to PCMCIA. Sorry for being a bore. (Not that I don't love reading LKML discussions, but I found that it took too much time, and now they're over at linux-pcmcia too! :) Thank you in advance. //Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/paravirt: revert exports to restore old behaviour
Christoph Hellwig wrote: > NACK, both of these are internal and graphics drivers should not be > using them. > I don't feel very strongly about it either way. I think the two arguments for it are: 1. it's a regression compared to previous kernels 2. it's a visible difference between CONFIG_PARAVIRT and non-CONFIG_PARAVIRT Arguments against are all the usual ones. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mm snapshot broken-out-2007-11-13-04-14.tar.gz uploaded
On Tue, 13 Nov 2007 17:11:13 -0800 Andrew Morton wrote: > On Tue, 13 Nov 2007 20:20:32 -0400 Kevin Winchester <[EMAIL PROTECTED]> wrote: > > > On November 13, 2007 08:15:41 am [EMAIL PROTECTED] wrote: > > > The mm snapshot broken-out-2007-11-13-04-14.tar.gz has been uploaded to > > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-11-13- > > >04-14.tar.gz > > > > > > It contains the following patches against 2.6.24-rc2: > > > > > > > > > > > How exactly do I go about trying out this snapshot? I did the following: > > > > - exported 2.6.24-rc2 from my cloned git tree to a separate folder > > - installed quilt > > - extracted the patches to the "patches" directory at the top level of the > > 2.6.24-rc2 tree > > - copied the list of patches from your mail into a "series" file which I > > placed in the "patches" directory > > The tarball contains a copy of the series file. For some reason LARGE > numbers of people miss it and ask me "hey, where's the series file?". Odd. Raises hand. > > Is > > there a reason that there is no "series" file in the archive with the > > patches? > > It's in there ;) > > btw, I put the patches in a directory called "broken-out" so that you can > untar them in your kernel tree and not have them stomped all over your > existing patches/ directory. symlink it... It's not at the same directory level as the patches. For some reason, that would help me find it. --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] New Kernel Bugs
On Tue, 13 Nov 2007 19:52:17 -0500 Chuck Ebbert <[EMAIL PROTECTED]> wrote: > On 11/13/2007 04:12 PM, Alan Cox wrote: > >> Bug fixing is not about finding someone to blame, it's about getting the > >> bug fixed. > > > > Partly - its also about understanding why the bug occurred and making it > > not happen again. > > Very few people think about that part. Why does the kernel have very few useful tests? Lack of interest? resources? expertise? Ideally each new feature would just be a small add on to an existing test. Unlike developing new features which seems to grow well with more developers. Bug fixing also seems to be a scarcity process. There often seems to be a very few people that understand the problem well enough or have the necessary hardware to reproduce and fix the problem. Recent changes like tickless and scheduler rework were well thought out and caused very little impact to 90% of the users. The problem is the 10% who do have problems. Worse, the developers often only hear about the a small sample of those. -- Stephen Hemminger <[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/
Divide-by-zero in the 2.6.23 scheduler code
https://bugzilla.redhat.com/show_bug.cgi?id=340161
The problem code has been removed in 2.6.24. The below patch disables
SCHED_FEAT_PRECISE_CPU_LOAD which causes the offending code to be skipped
but does not prevent the user from enabling it.
The divide-by-zero is here in kernel/sched.c:
static void update_cpu_load(struct rq *this_rq)
{
u64 fair_delta64, exec_delta64, idle_delta64, sample_interval64, tmp64;
unsigned long total_load = this_rq->ls.load.weight;
unsigned long this_load = total_load;
struct load_stat *ls = _rq->ls;
int i, scale;
this_rq->nr_load_updates++;
if (unlikely(!(sysctl_sched_features & SCHED_FEAT_PRECISE_CPU_LOAD)))
goto do_avg;
/* Update delta_fair/delta_exec fields first */
update_curr_load(this_rq);
fair_delta64 = ls->delta_fair + 1;
ls->delta_fair = 0;
exec_delta64 = ls->delta_exec + 1;
ls->delta_exec = 0;
sample_interval64 = this_rq->clock - ls->load_update_last;
ls->load_update_last = this_rq->clock;
if ((s64)sample_interval64 < (s64)TICK_NSEC)
sample_interval64 = TICK_NSEC;
if (exec_delta64 > sample_interval64)
exec_delta64 = sample_interval64;
idle_delta64 = sample_interval64 - exec_delta64;
==> tmp64 = div64_64(SCHED_LOAD_SCALE * exec_delta64, fair_delta64);
tmp64 = div64_64(tmp64 * exec_delta64, sample_interval64);
this_load = (unsigned long)tmp64;
do_avg:
/* Update our load: */
for (i = 0, scale = 1; i < CPU_LOAD_IDX_MAX; i++, scale += scale) {
unsigned long old_load, new_load;
/* scale is effectively 1 << i now, and >> i divides by scale */
old_load = this_rq->cpu_load[i];
new_load = this_load;
this_rq->cpu_load[i] = (old_load*(scale-1) + new_load) >> i;
}
}
---
kernel/sched_fair.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.23.noarch.orig/kernel/sched_fair.c
+++ linux-2.6.23.noarch/kernel/sched_fair.c
@@ -93,7 +93,7 @@ unsigned int sysctl_sched_features __rea
SCHED_FEAT_FAIR_SLEEPERS*1 |
SCHED_FEAT_SLEEPER_AVG *0 |
SCHED_FEAT_SLEEPER_LOAD_AVG *1 |
- SCHED_FEAT_PRECISE_CPU_LOAD *1 |
+ SCHED_FEAT_PRECISE_CPU_LOAD *0 |
SCHED_FEAT_START_DEBIT *1 |
SCHED_FEAT_SKIP_INITIAL *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: mm snapshot broken-out-2007-11-13-04-14.tar.gz uploaded
On Tue, 13 Nov 2007 20:20:32 -0400 Kevin Winchester <[EMAIL PROTECTED]> wrote: > On November 13, 2007 08:15:41 am [EMAIL PROTECTED] wrote: > > The mm snapshot broken-out-2007-11-13-04-14.tar.gz has been uploaded to > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-11-13- > >04-14.tar.gz > > > > It contains the following patches against 2.6.24-rc2: > > > > > > How exactly do I go about trying out this snapshot? I did the following: > > - exported 2.6.24-rc2 from my cloned git tree to a separate folder > - installed quilt > - extracted the patches to the "patches" directory at the top level of the > 2.6.24-rc2 tree > - copied the list of patches from your mail into a "series" file which I > placed in the "patches" directory The tarball contains a copy of the series file. For some reason LARGE numbers of people miss it and ask me "hey, where's the series file?". Odd. > - ran "quilt push -a" > > The result was that all of the patches seem to have been applied, but there > were many offsets and at least one fuzzed patch. Should they have applied > cleanly? Is quilt the way I am supposed to be applying these patches? Yes, the -mm patches contain large amount of fuzz. I'll occasionally go in and do a mass defuzzing (shaving?) but it all goes fuzzy again within a day. I _could_ rediff all the time, but I keep all the patches under revision control and I often need to grab the previous version of a patch (when I've just dropped an earlier patch, and that earlier patch had caused me to redo this patch). Having lots of revisions due to unnecessary rediffing would complicate that. > Is > there a reason that there is no "series" file in the archive with the > patches? It's in there ;) btw, I put the patches in a directory called "broken-out" so that you can untar them in your kernel tree and not have them stomped all over your existing patches/ directory. symlink 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: [BUG] New Kernel Bugs
From: Mark Lord <[EMAIL PROTECTED]> Date: Tue, 13 Nov 2007 13:18:43 -0500 > Mind you, no arguing that this is effective when that poor bloke has > a day free to download the git-tree and build/reboot a dozen times. Like the internet, this time spent is beneficial because it's pushing the work out to the end nodes. In fact git bisect is an awesome example of the end node principle in action for software development and QA. For the end-user wanting their bug fixed and the developer it's a win win situation because the reporter is actually able to do something proactive which will help get the bug they want fixed faster. So I don't agree with framing this person as a "poor bloke". Our testers are more empowered than ever to lead the process towards a fix. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: uml doesn't work on 2.6.24-rc2
On Wed, Nov 14, 2007 at 12:32:43AM +0100, Miklos Szeredi wrote: > UML doesn't run on 2.6.24-rc2 as host (config attached). Guest is > 2.6.23-mm1, but I guess it's irrelevant. 2.6.23 as host was OK. > > When booting there are zillions of lines like this: > > "arch_switch_tls failed, errno = EINVAL" This is PTRACE_ARCH_PRCTL failing and the only EINVAL I see is do_arch_prctl getting a bogus operation - something other than ARCH_[GS]ET_[FG]S, which is strange because UML never would have worked if it were passing in bogus arguments. Jeff -- Work email - jdike at linux dot intel dot com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 01/28] cpu alloc: The allocator
David Miller <[EMAIL PROTECTED]> writes: > > The problem is that for the non-virtualized case this patch bloats up > the BSS section to be more than 8MB in size. Sparc64 kernel images > cannot be more than 8MB in size total due to various boot loader and > firmware limitations. I recently ran into a similar problem with x86-64 and large BSS from lockdep conflicting with a 16MB kdump kernel. Solution was to do another early allocator before bootmem and then move the tables into there. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5][RFC] Physical PCI slot objects
Greg KH <[EMAIL PROTECTED]> writes: > > Also, some companies already provide userspace tools to get all of this > information about the different slots in a system and what is where, > from userspace, no kernel changes are needed. So, why add all this > extra complexity to the kernel if it is not needed? It's not only complexity. Each new sysfs entry costs memory. Memory is not free. There should be always a good reason for those. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Enabling Magic SysRq Key on boot before INIT
On Tue, 13 Nov 2007 19:55:09 -0500 Chuck Ebbert wrote: > On 11/13/2007 03:24 PM, Eric Schoeller wrote: > > Hello, > > > > I would like to enable the Magic SysRq key immediately when the linux > > kernel starts to boot, not when INIT begins. So, I am familiar with the > > sysctl command and /etc/sysctl.conf - but I'd like to modify these types > > of kernel variables earlier in the boot process. I thought that I could, > > perhaps, pass an argument to my "kernel" line in my bootloader (grub) > > configuration, but I have not been able to figure that out. > > > > sysrq_always_enabled I thought that Eric was asking if it was possible to alter sysctls by adding boot command line arguments.. if he was, then the answer is no, it's not (in general). --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 5/8] Immediate Values - x86 Optimization (update)
Mathieu Desnoyers wrote: Ok, so the most flexible solution that I see, that should fit for both i386 and x86_64 would be : 1 byte : "=Q" : Any register accessible as rh: a, b, c, and d. 2, 4 bytes : "=R" : Legacy register—the eight integer registers available on all i386 processors (a, b, c, d, si, di, bp, sp). 8 bytes : (only for x86_64) "=r" : A register operand is allowed provided that it is in a general register. That should make sure x86_64 won't try to use REX prefixed opcodes for 1, 2 and 4 bytes values. Does it make sense ? That's probably the best bet. -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: [patch/rfc 1/4] GPIO implementation framework
Subject: [PATCH 5/5] move per GPIO "requested" to "struct gpio_desc"
---
include/asm-generic/gpio.h | 17 +++-
lib/gpiolib.c | 62 ---
2 files changed, 39 insertions(+), 40 deletions(-)
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index da67038..7e70c67 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -28,6 +28,10 @@ struct gpio_chip;
struct gpio_desc {
struct gpio_chip *chip;
unsigned is_out:1;
+ unsigned requested:1;
+#ifdef CONFIG_DEBUG_FS
+ const char *requested_str;
+#endif
};
/**
@@ -76,24 +80,11 @@ struct gpio_chip {
u16 ngpio;
unsignedcan_sleep:1;
- /* other fields are modified by the gpio library only */
- DECLARE_BITMAP(requested, ARCH_GPIOS_PER_CHIP);
-
#ifdef CONFIG_DEBUG_FS
struct list_headnode;
- const char *requested_str[ARCH_GPIOS_PER_CHIP];
#endif
};
-/* returns true iff a given gpio signal has been requested;
- * primarily for code dumping gpio_chip state.
- */
-static inline int
-gpiochip_is_requested(struct gpio_chip *chip, unsigned offset)
-{
- return test_bit(offset, chip->requested);
-}
-
/* add/remove chips */
extern int gpiochip_add(struct gpio_chip *chip);
extern int __must_check gpiochip_remove(struct gpio_chip *chip);
diff --git a/lib/gpiolib.c b/lib/gpiolib.c
index a089597..f9e1c88 100644
--- a/lib/gpiolib.c
+++ b/lib/gpiolib.c
@@ -43,20 +43,19 @@ static inline int gpio_is_onchip(unsigned gpio,
struct gpio_chip *chip)
/* Warn when drivers omit gpio_request() calls -- legal but
* ill-advised when setting direction, and otherwise illegal.
*/
-static void gpio_ensure_requested(struct gpio_chip *chip, unsigned offset)
+static void gpio_ensure_requested(unsigned gpio)
{
- int requested;
+ int requested;
- requested = test_and_set_bit(offset, chip->requested);
+ requested = gpio_desc[gpio].requested;
#ifdef CONFIG_DEBUG_FS
if (!requested)
- chip->requested_str[offset] = "(auto)";
+ gpio_desc[gpio].requested_str = "(auto)";
#endif
if (!requested)
- printk(KERN_DEBUG "GPIO-%d autorequested\n",
- chip->base + offset);
+ pr_debug("GPIO-%d autorequested\n", gpio);
}
/* caller holds gpio_lock */
@@ -114,13 +113,12 @@ EXPORT_SYMBOL_GPL(gpiochip_add);
int gpiochip_remove(struct gpio_chip *chip)
{
unsigned long flags;
- int offset;
unsignedid;
spin_lock_irqsave(_lock, flags);
- for (offset = 0; offset < chip->ngpio; offset++)
- if (gpiochip_is_requested(chip, offset)) {
+ for (id = chip->base; id < chip->base + chip->ngpio; id++)
+ if (gpio_desc[id].requested) {
spin_unlock_irqrestore(_lock, flags);
return -EBUSY;
}
@@ -145,11 +143,14 @@ EXPORT_SYMBOL_GPL(gpiochip_remove);
int gpio_request(unsigned gpio, const char *label)
{
struct gpio_chip*chip;
+ struct gpio_desc*desc;
int status = -EINVAL;
unsigned long flags;
spin_lock_irqsave(_lock, flags);
- chip = gpio_to_chip(gpio);
+
+ desc = _desc[gpio];
+ chip = desc->chip;
if (!gpio_is_onchip(gpio, chip))
goto done;
@@ -162,12 +163,14 @@ int gpio_request(unsigned gpio, const char *label)
status = 0;
- if (test_and_set_bit(gpio, chip->requested))
+ if (desc->requested == 0)
+ desc->requested = 1;
+ else
status = -EBUSY;
#ifdef CONFIG_DEBUG_FS
if (status == 0)
- chip->requested_str[gpio] = (label == NULL) ? "?" : label;
+ desc->requested_str = (label == NULL) ? "?" : label;
#endif
done:
@@ -180,9 +183,11 @@ void gpio_free(unsigned gpio)
{
unsigned long flags;
struct gpio_chip*chip;
+ struct gpio_desc*desc;
spin_lock_irqsave(_lock, flags);
+ desc = _desc[gpio];
chip = gpio_to_chip(gpio);
if (!gpio_is_onchip(gpio, chip))
@@ -190,12 +195,13 @@ void gpio_free(unsigned gpio)
gpio -= chip->base;
- if (!test_and_clear_bit(gpio, chip->requested))
+ if (desc->requested == 0)
+ desc->requested = 1;
+ else
chip = NULL;
#ifdef CONFIG_DEBUG_FS
- if (chip != NULL)
- chip->requested_str[gpio] = NULL;
+ desc->requested_str = NULL;
#endif
WARN_ON(extra_checks && chip == NULL);
done:
@@ -231,8 +237,8 @@ int gpio_direction_input(unsigned gpio)
if (!gpio_is_onchip(gpio, chip))
goto fail;
+ gpio_ensure_requested(gpio);
gpio -= chip->base;
-
Re: [patch/rfc 1/4] GPIO implementation framework
Here comes the point of "struct gpio_desc"
Subject: [PATCH 3/5] use a per GPIO "struct gpio_desc" and chain
"gpio_chip" to a list
---
include/asm-generic/gpio.h |7 +
lib/gpiolib.c | 64 ++--
2 files changed, 39 insertions(+), 32 deletions(-)
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index ba3e336..783adcf 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -23,6 +23,12 @@
struct seq_file;
+struct gpio_chip;
+
+struct gpio_desc {
+ struct gpio_chip *chip;
+};
+
/**
* struct gpio_chip - abstract a GPIO controller
* @label: for diagnostics
@@ -76,6 +82,7 @@ struct gpio_chip {
DECLARE_BITMAP(requested, ARCH_GPIOS_PER_CHIP);
#ifdef CONFIG_DEBUG_FS
+ struct list_headnode;
const char *requested_str[ARCH_GPIOS_PER_CHIP];
#endif
};
diff --git a/lib/gpiolib.c b/lib/gpiolib.c
index d52c7f1..57e0d10 100644
--- a/lib/gpiolib.c
+++ b/lib/gpiolib.c
@@ -25,13 +25,12 @@
#defineextra_checks0
#endif
-/* gpio_lock protects modification to the table of chips and to
- * gpio_chip->requested. If a gpio is requested, its gpio_chip
- * is not removable.
- */
static DEFINE_SPINLOCK(gpio_lock);
-static struct gpio_chip *chips[DIV_ROUND_UP(ARCH_NR_GPIOS,
- ARCH_GPIOS_PER_CHIP)];
+struct gpio_desc gpio_desc[ARCH_NR_GPIOS];
+
+#ifdef CONFIG_DEBUG_FS
+static LIST_HEAD(gpio_chip_list);
+#endif
static inline int gpio_is_onchip(unsigned gpio, struct gpio_chip *chip)
{
@@ -63,7 +62,7 @@ static void gpio_ensure_requested(struct gpio_chip
*chip, unsigned offset)
/* caller holds gpio_lock */
static inline struct gpio_chip *gpio_to_chip(unsigned gpio)
{
- return chips[gpio / ARCH_GPIOS_PER_CHIP];
+ return gpio_desc[gpio].chip;
}
/**
@@ -78,7 +77,6 @@ static inline struct gpio_chip *gpio_to_chip(unsigned gpio)
int gpiochip_add(struct gpio_chip *chip)
{
unsigned long flags;
- int status = 0;
unsignedid;
if (chip->base < 0 || (chip->base % ARCH_GPIOS_PER_CHIP) != 0)
@@ -89,13 +87,21 @@ int gpiochip_add(struct gpio_chip *chip)
return -EINVAL;
spin_lock_irqsave(_lock, flags);
- id = chip->base / ARCH_GPIOS_PER_CHIP;
- if (chips[id] == NULL)
- chips[id] = chip;
- else
- status = -EBUSY;
+
+ for (id = chip->base; id < chip->base + chip->ngpio; id++)
+ if (gpio_desc[id].chip) {
+ spin_unlock_irqrestore(_lock, flags);
+ return -EBUSY;
+ }
+
+ for (id = chip->base; id < chip->base + chip->ngpio; id++)
+ gpio_desc[id].chip = chip;
+
+#ifdef CONFIG_DEBUG_FS
+ list_add(>node, _chip_list);
+#endif
spin_unlock_irqrestore(_lock, flags);
- return status;
+ return 0;
}
EXPORT_SYMBOL_GPL(gpiochip_add);
@@ -108,28 +114,26 @@ EXPORT_SYMBOL_GPL(gpiochip_add);
int gpiochip_remove(struct gpio_chip *chip)
{
unsigned long flags;
- int status = 0;
int offset;
- unsignedid = chip->base / ARCH_GPIOS_PER_CHIP;
+ unsignedid;
spin_lock_irqsave(_lock, flags);
- for (offset = 0; offset < chip->ngpio; offset++) {
+ for (offset = 0; offset < chip->ngpio; offset++)
if (gpiochip_is_requested(chip, offset)) {
- status = -EBUSY;
- break;
+ spin_unlock_irqrestore(_lock, flags);
+ return -EBUSY;
}
- }
- if (status == 0) {
- if (chips[id] == chip)
- chips[id] = NULL;
- else
- status = -EINVAL;
- }
+ for (id = chip->base; id < chip->base + chip->ngpio; id++)
+ gpio_desc[id].chip = NULL;
+
+#ifdef CONFIG_DEBUG_FS
+ list_del(>node);
+#endif
spin_unlock_irqrestore(_lock, flags);
- return status;
+ return 0;
}
EXPORT_SYMBOL_GPL(gpiochip_remove);
@@ -463,11 +467,7 @@ static int gpiolib_show(struct seq_file *s, void *unused)
/* REVISIT this isn't locked against gpio_chip removal ... */
- for (id = 0; id < ARRAY_SIZE(chips); id++) {
- chip = chips[id];
- if (!chip)
- continue;
-
+ list_for_each_entry(chip, _chip_list, node) {
seq_printf(s, "%sGPIOs %d-%d, %s%s:\n",
started ? "\n" : "",
chip->base, chip->base + chip->ngpio - 1,
--
1.5.2.5.GIT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/rfc 1/4] GPIO implementation framework
Subject: [PATCH] move per GPIO "is_out" to "struct gpio_desc"
---
include/asm-generic/gpio.h |4 +---
lib/gpiolib.c | 18 +++---
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index 783adcf..da67038 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -27,6 +27,7 @@ struct gpio_chip;
struct gpio_desc {
struct gpio_chip *chip;
+ unsigned is_out:1;
};
/**
@@ -47,8 +48,6 @@ struct gpio_desc {
* (base + ngpio - 1).
* @can_sleep: flag must be set iff get()/set() methods sleep, as they
* must while accessing GPIO expander chips over I2C or SPI
- * @is_out: bit array where bit N is true iff GPIO with offset N has been
- * called successfully to configure this as an output
*
* A gpio_chip can help platforms abstract various sources of GPIOs so
* they can all be accessed through a common programing interface.
@@ -78,7 +77,6 @@ struct gpio_chip {
unsignedcan_sleep:1;
/* other fields are modified by the gpio library only */
- DECLARE_BITMAP(is_out, ARCH_GPIOS_PER_CHIP);
DECLARE_BITMAP(requested, ARCH_GPIOS_PER_CHIP);
#ifdef CONFIG_DEBUG_FS
diff --git a/lib/gpiolib.c b/lib/gpiolib.c
index 57e0d10..a089597 100644
--- a/lib/gpiolib.c
+++ b/lib/gpiolib.c
@@ -217,11 +217,14 @@ int gpio_direction_input(unsigned gpio)
{
unsigned long flags;
struct gpio_chip*chip;
+ struct gpio_desc*desc;
int status = -EINVAL;
spin_lock_irqsave(_lock, flags);
- chip = gpio_to_chip(gpio);
+ desc = _desc[gpio];
+ chip = desc->chip;
+
if (!chip || !chip->get || !chip->direction_input)
goto fail;
@@ -238,8 +241,7 @@ int gpio_direction_input(unsigned gpio)
might_sleep_if(extra_checks && chip->can_sleep);
status = chip->direction_input(chip, gpio);
- if (status == 0)
- clear_bit(gpio, chip->is_out);
+ desc->is_out = 0;
return status;
fail:
spin_unlock_irqrestore(_lock, flags);
@@ -251,11 +253,14 @@ int gpio_direction_output(unsigned gpio, int value)
{
unsigned long flags;
struct gpio_chip*chip;
+ struct gpio_desc*desc;
int status = -EINVAL;
spin_lock_irqsave(_lock, flags);
- chip = gpio_to_chip(gpio);
+ desc = _desc[gpio];
+ chip = desc->chip;
+
if (!chip || !chip->get || !chip->direction_output)
goto fail;
@@ -272,8 +277,7 @@ int gpio_direction_output(unsigned gpio, int value)
might_sleep_if(extra_checks && chip->can_sleep);
status = chip->direction_output(chip, gpio, value);
- if (status == 0)
- set_bit(gpio, chip->is_out);
+ desc->is_out = 1;
return status;
fail:
spin_unlock_irqrestore(_lock, flags);
@@ -402,7 +406,7 @@ static void gpiolib_dbg_show(struct seq_file *s,
struct gpio_chip *chip)
continue;
gpio = chip->base + i;
- is_out = test_bit(i, chip->is_out);
+ is_out = gpio_desc[gpio].is_out;
seq_printf(s, " gpio-%-3d (%-12s) %s %s",
gpio, chip->requested_str[i],
--
1.5.2.5.GIT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/rfc 1/4] GPIO implementation framework
so that requested will always be used, only *requested_str will be used
for DEBUG_FS tracking assistance
Subject: [PATCH 2/5] define gpio_chip.requested_str as a debugfs tracking string
---
include/asm-generic/gpio.h | 11 ++-
lib/gpiolib.c | 34 ++
2 files changed, 16 insertions(+), 29 deletions(-)
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index d00a287..ba3e336 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -73,13 +73,10 @@ struct gpio_chip {
/* other fields are modified by the gpio library only */
DECLARE_BITMAP(is_out, ARCH_GPIOS_PER_CHIP);
+ DECLARE_BITMAP(requested, ARCH_GPIOS_PER_CHIP);
#ifdef CONFIG_DEBUG_FS
- /* fat bits */
- const char *requested[ARCH_GPIOS_PER_CHIP];
-#else
- /* thin bits */
- DECLARE_BITMAP(requested, ARCH_GPIOS_PER_CHIP);
+ const char *requested_str[ARCH_GPIOS_PER_CHIP];
#endif
};
@@ -89,11 +86,7 @@ struct gpio_chip {
static inline int
gpiochip_is_requested(struct gpio_chip *chip, unsigned offset)
{
-#ifdef CONFIG_DEBUG_FS
- return chip->requested[offset] != NULL;
-#else
return test_bit(offset, chip->requested);
-#endif
}
/* add/remove chips */
diff --git a/lib/gpiolib.c b/lib/gpiolib.c
index c627efb..d52c7f1 100644
--- a/lib/gpiolib.c
+++ b/lib/gpiolib.c
@@ -48,12 +48,11 @@ static void gpio_ensure_requested(struct gpio_chip
*chip, unsigned offset)
{
int requested;
+ requested = test_and_set_bit(offset, chip->requested);
+
#ifdef CONFIG_DEBUG_FS
- requested = (int) chip->requested[offset];
if (!requested)
- chip->requested[offset] = "(auto)";
-#else
- requested = test_and_set_bit(offset, chip->requested);
+ chip->requested_str[offset] = "(auto)";
#endif
if (!requested)
@@ -158,16 +157,13 @@ int gpio_request(unsigned gpio, const char *label)
*/
status = 0;
-#ifdef CONFIG_DEBUG_FS
- if (!label)
- label = "?";
- if (chip->requested[gpio])
- status = -EBUSY;
- else
- chip->requested[gpio] = label;
-#else
+
if (test_and_set_bit(gpio, chip->requested))
status = -EBUSY;
+
+#ifdef CONFIG_DEBUG_FS
+ if (status == 0)
+ chip->requested_str[gpio] = (label == NULL) ? "?" : label;
#endif
done:
@@ -190,14 +186,12 @@ void gpio_free(unsigned gpio)
gpio -= chip->base;
-#ifdef CONFIG_DEBUG_FS
- if (chip->requested[gpio])
- chip->requested[gpio] = NULL;
- else
- chip = NULL;
-#else
if (!test_and_clear_bit(gpio, chip->requested))
chip = NULL;
+
+#ifdef CONFIG_DEBUG_FS
+ if (chip != NULL)
+ chip->requested_str[gpio] = NULL;
#endif
WARN_ON(extra_checks && chip == NULL);
done:
@@ -400,14 +394,14 @@ static void gpiolib_dbg_show(struct seq_file *s,
struct gpio_chip *chip)
unsignedgpio;
int is_out;
- if (!chip->requested[i])
+ if (!chip->requested_str[i])
continue;
gpio = chip->base + i;
is_out = test_bit(i, chip->is_out);
seq_printf(s, " gpio-%-3d (%-12s) %s %s",
- gpio, chip->requested[i],
+ gpio, chip->requested_str[i],
is_out ? "out" : "in ",
chip->get
? (chip->get(chip, i) ? "hi" : "lo")
--
1.5.2.5.GIT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/rfc 1/4] GPIO implementation framework
Here comes a bunch of patches to illustrate my idea, some are not related to
the point I mentioned, and they are not mature for now :-)
Subject: [PATCH 1/5] add gpio_is_onchip() for commonly used gpio range checking
---
lib/gpiolib.c | 32 ++--
1 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/lib/gpiolib.c b/lib/gpiolib.c
index f2ae689..c627efb 100644
--- a/lib/gpiolib.c
+++ b/lib/gpiolib.c
@@ -33,6 +33,14 @@ static DEFINE_SPINLOCK(gpio_lock);
static struct gpio_chip *chips[DIV_ROUND_UP(ARCH_NR_GPIOS,
ARCH_GPIOS_PER_CHIP)];
+static inline int gpio_is_onchip(unsigned gpio, struct gpio_chip *chip)
+{
+ if (chip && gpio >= chip->base && gpio < chip->base + chip->ngpio)
+ return 1;
+ else
+ return 0;
+}
+
/* Warn when drivers omit gpio_request() calls -- legal but
* ill-advised when setting direction, and otherwise illegal.
*/
@@ -139,11 +147,11 @@ int gpio_request(unsigned gpio, const char *label)
spin_lock_irqsave(_lock, flags);
chip = gpio_to_chip(gpio);
- if (!chip)
+
+ if (!gpio_is_onchip(gpio, chip))
goto done;
+
gpio -= chip->base;
- if (gpio >= chip->ngpio)
- goto done;
/* NOTE: gpio_request() can be called in early boot,
* before IRQs are enabled.
@@ -176,11 +184,11 @@ void gpio_free(unsigned gpio)
spin_lock_irqsave(_lock, flags);
chip = gpio_to_chip(gpio);
- if (!chip)
+
+ if (!gpio_is_onchip(gpio, chip))
goto done;
+
gpio -= chip->base;
- if (gpio >= chip->ngpio)
- goto done;
#ifdef CONFIG_DEBUG_FS
if (chip->requested[gpio])
@@ -218,9 +226,11 @@ int gpio_direction_input(unsigned gpio)
chip = gpio_to_chip(gpio);
if (!chip || !chip->get || !chip->direction_input)
goto fail;
- gpio -= chip->base;
- if (gpio >= chip->ngpio)
+
+ if (!gpio_is_onchip(gpio, chip))
goto fail;
+
+ gpio -= chip->base;
gpio_ensure_requested(chip, gpio);
/* now we know the gpio is valid and chip won't vanish */
@@ -250,9 +260,11 @@ int gpio_direction_output(unsigned gpio, int value)
chip = gpio_to_chip(gpio);
if (!chip || !chip->get || !chip->direction_output)
goto fail;
- gpio -= chip->base;
- if (gpio >= chip->ngpio)
+
+ if (!gpio_is_onchip(gpio, chip))
goto fail;
+
+ gpio -= chip->base;
gpio_ensure_requested(chip, gpio);
/* now we know the gpio is valid and chip won't vanish */
--
1.5.2.5.GIT
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch/rfc 1/4] GPIO implementation framework
On Nov 14, 2007 3:06 AM, David Brownell <[EMAIL PROTECTED]> wrote: > On Monday 12 November 2007, eric miao wrote: > > Hi David, > > > > I hope I was not late giving my humble feedback on this framework :-) > > > > Can we use "per gpio based" structure instead of "per gpio_chip" based one, > > just like what the generic IRQ layer is doing nowadays? > > We "can" do most anything. What would that improve though? > > Each irq_chip handles multiple IRQs ... just like this patch > has each gpio_chip handling multiple GPIOs. (Not that I think > GPIO code should closely model IRQ code; they need to address > very different problems.) > > I can't tell what you intend to suggest as a "per-GPIO" data > structure; since I can think of at least three different ways > to do such a thing, you should be more concrete. I'd think it > should be in *addition* to a gpio_chip structure though. > exactly, I'd say a "struct gpio_desc" as > > > So that > > > > a. you don't have to declare per gpio_chip "can_sleep", "is_out" and > > "requested". > > Those will be just bits of properties of a single GPIO. > > The can_sleep value is a per-controller thing. The other bits are > indeed per-GPIO. > > So do you mean a structure with two bits, plus a pointer to a > gpio_chip, plus likely other stuff (what?) to make it work? > What would the hot-path costs be (for getting/setting values of > an on-chip GPIO)? > the cost is as trivial as the current one. > > > b. and furthur more, one can avoid the use of ARCH_GPIOS_PER_CHIP, which > > leads to many holes > > Why should holes (in the GPIO number sequence) be a problem? In > this code, they don't cost much space at all. They'd cost more > if there were a per-GPIO structure though... > well, I don't think holes are problems, but think about the restriction ARCH_GPIOS_PER_CHIP enforces the numbering of GPIOs, don't you think we need a more flexible numbering scheme, so one can later adjust gpio_to_irq() and irq_to_gpio() easily?? > The only downside of GPIOS_PER_CHIP that I know of right now > is that it complicates mixing gpio bank sizes; it's a ceiling, > some controllers would allocate more than they need. The > upside of that is efficiency, and a closer match to how > underlying hardware works. > > Of course, GPIOS_PER_CHIP *could* be decoupled from how the > table of gpio_chip pointers is managed. If the table were to > group GPIOs in units of 8, a gpio_chip with 32 GPIOs could > take four adjacent entries while an 8-bit GPIO expander could > take just one. That'd be a very easy patch, supporting a more > dense allocation of GPIO numbers... although it would increase > static memory consumption by typically NR_GPIOS/4 pointers. > > > > c. gpio_to_chip() will be made easy and straight forward > > I'd say "return chips[gpio / ARCH_GPIOS_PER_CHIP]" already meets > both criteria! > > There's also "efficient" to consider; this way doesn't cost much > memory or add levels of indirection (compared to most platforms, > which already use a similar array). > > > > d. granularity of spin_lock()/_unlock() can be made small > > (per GPIO instead of per gpio_chip) > > Why would per-GPIO locking be needed though? Look again... > > The locking is there fundamentally because gpio_chip structures > may need to be unregistered; that's not a per-gpio issue. > Even when a gpio is marked in chip->requested under that lock, > that's part of ensuring that the unregistration is prevented so > long as the GPIO is in active use. > > Plus, fine grained locking is rarely a good idea; it normally > increases locking overhead by involving multiple locks. Only > add extra locks if a single lock sees too much contention; and > even then, only if that contention can't be removed by using a > smarter design. > well, I don't see much benefit for now, either. But binding/unbinding the gpio_chip to the gpio_desc could possibly be made locking free (RCU maybe), since removing a gpio_chip is really *rare*. > - Dave > > > > > > What do you think? > > > > - eric > > > > On Nov 6, 2007 5:05 AM, David Brownell <[EMAIL PROTECTED]> wrote: > > > On Monday 29 October 2007, David Brownell wrote: > > > > > > > > Provides new implementation infrastructure that platforms may choose to > > > > use > > > > when implementing the GPIO programming interface. Platforms can update > > > > their > > > > GPIO support to use this. The downside is slower access to non-inlined > > > > GPIOs; > > > > rarely a problem except when bitbanging some protocol. > > > > > > I was asked just what that overhead *is* ... and it surprised me. > > > A summary of the results is appended to this note. > > > > > > Fortuntely it turns out those problems all go away if the gpiolib > > > code uses a *raw* spinlock to guard its table lookups. With a raw > > > spinlock, any performance impact of gpiolib seems to be well under > > > a microsecond in this bitbang context (and not objectionable). > > > Preempt became free; enabling debug options had
Re: Enabling Magic SysRq Key on boot before INIT
On 11/13/2007 03:24 PM, Eric Schoeller wrote: > Hello, > > I would like to enable the Magic SysRq key immediately when the linux > kernel starts to boot, not when INIT begins. So, I am familiar with the > sysctl command and /etc/sysctl.conf - but I'd like to modify these types > of kernel variables earlier in the boot process. I thought that I could, > perhaps, pass an argument to my "kernel" line in my bootloader (grub) > configuration, but I have not been able to figure that out. > sysrq_always_enabled - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.24-rc2 displays incorrect DVD description
For example, 2.6.23.1: Linux version 2.6.23.1 ([EMAIL PROTECTED]) (gcc version 4.2.2) #1 SMP PREEMPT Fri Oct 26 13:09:09 CDT 2007 kernel: hdd: HP DVD Writer 1040d, ATAPI CD/DVD-ROM drive kernel: hdd: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(66) and 2.6.24-rc2: Linux version 2.6.24-rc2 ([EMAIL PROTECTED]) (gcc version 4.2.2) #1 SMP PREEMPT Fri Nov 9 20:41:37 CST 2007 kernel: hdd: HP DVD Writer 1040d, ATAPI CD/DVD-ROM drive kernel: hdd: ATAPI 126X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(66) The drive seems to work correctly, reading and writing just fine. I just happened to notice this and thought I'd pass it along. One other odd thing while looking through the logs, 2.6.23.1 has also reported the drive as follows: Linux version 2.6.23.1 ([EMAIL PROTECTED]) (gcc version 4.2.2) #1 SMP PREEMPT Fri Oct 26 13:09:09 CDT 2007 kernel: hdd: HP DVD Writer 1040d, ATAPI CD/DVD-ROM drive kernel: hdd: ATAPI 32X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(66) Any idea what is going on here? It's being reported as 48X, 126X, and 32X. Thanks, 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: [BUG] New Kernel Bugs
On 11/13/2007 04:12 PM, Alan Cox wrote: >> Bug fixing is not about finding someone to blame, it's about getting the >> bug fixed. > > Partly - its also about understanding why the bug occurred and making it > not happen again. Very few people think about that part. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [13/45] x86_64: Increase VDSO_TEXT_OFFSET for ancient binutils
On Fri, Sep 21, 2007 at 10:44:54PM +0200, Andi Kleen wrote: > For some reason old binutils genertate larger headers so > increase the text offset of the vdso to avoid linker errors. > > Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> > > --- > arch/x86_64/vdso/voffset.h |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Index: linux/arch/x86_64/vdso/voffset.h > === > --- linux.orig/arch/x86_64/vdso/voffset.h > +++ linux/arch/x86_64/vdso/voffset.h > @@ -1 +1 @@ > -#define VDSO_TEXT_OFFSET 0x500 > +#define VDSO_TEXT_OFFSET 0x600 This still breaks under Debian sarge. There is this (german) forum thread about it: http://www.debianforum.de/forum/viewtopic.php?p=570102 Robotic english translation: http://translate.google.com/translate?u=http%3A%2F%2Fwww.debianforum.de%2Fforum%2Fviewtopic.php%3Fp%3D569756%26sid%3D20278bfd231c5dac45fa0f2763c7ec54%23569756=de%7Cen=en=UTF-8 And it indicates that 0x510 would be the better offset due to 0x600 making it clash with the data section beneath. Indeed when I change it to 0x510 I can compile the kernel with binutils 2.15-6. I'm hoping this wont cause the kernel to eat my grandma. :) -- "To the extent that we overreact, we proffer the terrorists the greatest tribute." - High Court Judge Michael Kirby - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86/paravirt: revert exports to restore old behaviour
On Tue, 2007-11-13 at 22:22 +, Christoph Hellwig wrote: > On Tue, Nov 13, 2007 at 12:21:16PM -0800, Jeremy Fitzhardinge wrote: > > Subject: x86/paravirt: revert exports to restore old behaviour > > > > Subdividing the paravirt_ops structure caused a regression in certain > > non-GPL modules which try to use mmu_ops and cpu_ops. This restores > > the old behaviour, and makes it consistent with the > > non-CONFIG_PARAVIRT case. > > NACK, both of these are internal and graphics drivers should not be > using them. Some of them are internal, but some are not, they just happened to be privileged CPU operations available to anyone. Does anyone know what hooks they are actually using? Something like reading MSRs is not internal at all, it is CPU specific, and the graphics drivers might have very good reasons to read them to figure out how AGP is configured for example. The graphics drivers most certainly don't need to be paravirtualized however, so they could always work around this with raw asm constructs. The mmu_ops hook is more debatable. But until someone figures out what hooks they want, we can't know whether they are internal or not. In any case, this is a regression. Zach - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [kvm-devel] [PATCH 2/3] kvmclock - the host part.
>> >> +kvm_get_msr(vcpu, MSR_IA32_TIME_STAMP_COUNTER, >> + >hv_clock.last_tsc); >> + >> +ktime_get_ts(); >> +vcpu->hv_clock.now_ns = ts.tv_nsec + (NSEC_PER_SEC * >> (u64)ts.tv_sec); + vcpu->hv_clock.wc_sec = get_seconds(); >> >> I am even thinking we have to disable interrupt between these lines, >> otherwise guest wall clock may see backward time source when >> calculating the delta TSC since last vcpu->hv_clock.now_ns update. >> > > That's true. While we do need to handle vcpu migration and > descheduling, the code sequence you note needs to be as atomic as > possible. > Yes VCPU migration is another issue. Since the physical platform TSC is totally different across migration, so we can't expose host TSC to guest. For KVM, it should be simple to just use guest_TSC (=HOST_TSC + offset). thanks, eddie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] New Kernel Bugs
On Tuesday 13 November 2007 11:57, Gabriel C wrote: > > The main problem is finding experienced developers who spend time on > > looking into bug reports. > > There are already. IMO the problem is the development model. > > There are tons new features in each new kernel release and 'tons new bugs' > which are not fixed during the release cycle nor in the .XX stable kernels. > > Maybe after XX kernel releases there should be one just with bug-fixes > _without_ any new features , eg: cleaning bugs from bugzilla , know > regressions , cleaning up code , removing broken drivers and the like. Won't work. You cannot force people to work on things they don't find interesting, long-term. -- vda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] New Kernel Bugs
On Tuesday 13 November 2007 10:56, Adrian Bunk wrote: > On Tue, Nov 13, 2007 at 12:13:56PM -0500, Theodore Tso wrote: > > On Tue, Nov 13, 2007 at 04:52:32PM +0100, Benoit Boissinot wrote: > > > Btw, I used to test every -mm kernel. But since I've switched distros > > > (gentoo->ubuntu) > > > and I have less time, I feel it's harder to test -rc or -mm kernels (I > > > know this isn't a lkml problem > > > but more a distro problem, but I would love having an ubuntu blessed > > > repo with current dev kernel > > > for the latest stable ubuntu release). > > > > There are two parts to this. One is a Ubuntu development kernel which > > we can give to large numbers of people to expand our testing pool. > > But if we don't do a better job of responding to bug reports that > > would be generated by expanded testing this won't necessarily help us. > >... > > The main problem aren't missing testers [1] - we already have relatively > experienced people testing kernels and/or reporting bugs, and we slowly > scare them away due to the many bug reports without any reaction. > > The main problem is finding experienced developers who spend time on > looking into bug reports. > > Getting many relatively unexperienced users (who need more guidance for > debugging issues) as additional testers is therefore IMHO not > necessarily a good idea. And where experienced developrs are coming from? They are not born with Linux kernel skills. They grow up from within user base. Bigger user base -> more developers (eventually) -- vda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 3/3] arch_rebalance_pgtables call
On Tuesday 13 November 2007 01:30, [EMAIL PROTECTED] wrote: > From: Martin Schwidefsky <[EMAIL PROTECTED]> > > In order to change the layout of the page tables after an mmap has > crossed the adress space limit of the current page table layout a > architecture hook in get_unmapped_area is needed. The arguments > are the address of the new mapping and the length of it. Can you comment what this is supposed to be fore somewhere? > Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]> > --- > > mm/mmap.c |6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > Index: linux-2.6/mm/mmap.c > === > --- linux-2.6.orig/mm/mmap.c > +++ linux-2.6/mm/mmap.c > @@ -36,6 +36,10 @@ > #define arch_mmap_check(addr, len, flags)(0) > #endif > > +#ifndef arch_rebalance_pgtables > +#define arch_rebalance_pgtables(addr, len) (addr) > +#endif > + > static void unmap_region(struct mm_struct *mm, > struct vm_area_struct *vma, struct vm_area_struct *prev, > unsigned long start, unsigned long end); > @@ -1436,7 +1440,7 @@ get_unmapped_area(struct file *file, uns > if (addr & ~PAGE_MASK) > return -EINVAL; > > - return addr; > + return arch_rebalance_pgtables(addr, len); > } > > EXPORT_SYMBOL(get_unmapped_area); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 22/54] kset: convert /sys/devices/system to use kset_create
On Tue, Nov 13, 2007 at 04:01:44PM -0800, Andrew Morton wrote: > On Tue, 13 Nov 2007 15:14:10 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > > > On Mon, 5 Nov 2007 12:03:34 -0800 Greg KH <[EMAIL PROTECTED]> wrote: > > > > > > > > <4> [<00142548>] sys_reboot+0x1a4/0x1f4 > > > > > > <4> [<00111038>] sysc_noemu+0x10/0x16 > > > > > > <4> [<021048e0>] 0x21048e0 > > > > > > <4> > > > > > > <4> > > > > > > > > > > > > Huh? We want to shutdown an unknown device on a bus that wishes to > > > > > > stay > > > > > > anonymous? > > > > > > > > > > > > Any hints would be appreciated... > > > > > > > > > > I'll look into this, I wonder if we are walking off the end of an > > > > > unterminated list... > > > > > > > > Could well be. If I'm using lcrash's walk function correctly (which > > > > always manages to confuse me...), the list of devices_kset seems to be > > > > broken. > > > > > > Alright, I can reproduce something like this at shutdown time myself > > > here, I'll try to figure it out... > > > > > > > > The Vaio oopses during `reboot -f' and I bisected it down to this patch. > > > > http://userweb.kernel.org/~akpm/dsc00034.jpg > > http://userweb.kernel.org/~akpm/config-sony.txt > > http://userweb.kernel.org/~akpm/dmesg-sony.txt > > The G5 Mac oopses in the same place during `halt -pfn'. Crap, I can't duplicate this here anymore. I'll fire up the older boxes tonight and try to track this down... 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/
[PATCH] pci hotplug: fix rpaphp directory naming
Fix presentation of the slot number in the /sys/bus/pci/slots
directory to match that used in the majority of other drivers.
--
On Tue, Nov 13, 2007 at 02:58:30PM -0700, Matthew Wilcox wrote:
> On Tue, Nov 13, 2007 at 03:41:21PM -0600, Linas Vepstas wrote:
> > /sys/bus/pci/slots
> > /sys/bus/pci/slots/control
> > /sys/bus/pci/slots/control/remove_slot
> > /sys/bus/pci/slots/control/add_slot
> > /sys/bus/pci/slots/0001:00:02.0
> > /sys/bus/pci/slots/0001:00:02.0/phy_location
>
> Ugh. Almost two years ago, paulus promised me he was going to fix the
> slot name for rpaphp. Guess he didn't.
You have to ask the right person. :-) I've been defacto mainaining
the rpaphp code for unpteen years now. On the other hand, I am also
much, much better at promising than delivering.
> This is one of the hateful things about the current design -- hotplug
> drivers do too much. Instead of being just the interface between the
> Linux PCI code and the hardware, they create sysfs directories, add
> files,
> and generally have far too much freedom.
I chopped out several hundred LOC from rpaphp a year ago,
and hopefuly that might make furthre simplification easier
someday.
> We have four different schemes currently for naming in slots/,
> 1. slot number. Used by cpqphp, ibmphp, acpiphp, pciehp, shpc.
> 2. domain:bus:dev:fn. Used by fakephp.
> 3a. domain:bus:dev. Used by rpaphp and sgihp.
> 3b. Except that rpaphp uses phy_location to present the information
> that
> should be in the name and sgihp uses path.
>
> ... I've forgotten what cpci uses. And yenta doesn't use it.
>
> How is anyone supposed to write sane managability tools in the
> presence
> of such anarchy?
>
> > ~ # cat /sys/bus/pci/slots/:00:02.2/phy_location
> > U787A.001.DNZ00Z5-P1-C2
>
> Right. This should look like:
>
> # cat /sys/bus/pci/slots/U787A.001.DNZ00Z5-P1-C2/address
> :00:02
This patch implements exactly what you describe. Boot tested.
I assume you really mean it -- if so, then please review and
ack the patch !?
I have absolutely no clue if this breaks any existing IBM tools.
I'm pretty sure it doesn't ... but attention Mike Strosaker! does it?
drivers/pci/hotplug/rpaphp.h |1
drivers/pci/hotplug/rpaphp_pci.c | 14 ---
drivers/pci/hotplug/rpaphp_slot.c | 47 +++---
3 files changed, 24 insertions(+), 38 deletions(-)
Index: linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp_pci.c
===
--- linux-2.6.23-rc8-mm1.orig/drivers/pci/hotplug/rpaphp_pci.c 2007-07-08
18:32:17.0 -0500
+++ linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp_pci.c 2007-11-13
17:52:10.0 -0600
@@ -64,19 +64,6 @@ int rpaphp_get_sensor_state(struct slot
return rc;
}
-static void set_slot_name(struct slot *slot)
-{
- struct pci_bus *bus = slot->bus;
- struct pci_dev *bridge;
-
- bridge = bus->self;
- if (bridge)
- strcpy(slot->name, pci_name(bridge));
- else
- sprintf(slot->name, "%04x:%02x:00.0", pci_domain_nr(bus),
- bus->number);
-}
-
/**
* rpaphp_enable_slot - record slot state, config pci device
*
@@ -114,7 +101,6 @@ int rpaphp_enable_slot(struct slot *slot
info->adapter_status = EMPTY;
slot->bus = bus;
slot->pci_devs = >devices;
- set_slot_name(slot);
/* if there's an adapter in the slot, go add the pci devices */
if (state == PRESENT) {
Index: linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp_slot.c
===
--- linux-2.6.23-rc8-mm1.orig/drivers/pci/hotplug/rpaphp_slot.c 2007-07-08
18:32:17.0 -0500
+++ linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp_slot.c 2007-11-13
18:05:13.0 -0600
@@ -33,23 +33,31 @@
#include
#include "rpaphp.h"
-static ssize_t location_read_file (struct hotplug_slot *php_slot, char *buf)
+static ssize_t address_read_file (struct hotplug_slot *php_slot, char *buf)
{
- char *value;
- int retval = -ENOENT;
+ int retval;
struct slot *slot = (struct slot *)php_slot->private;
+ struct pci_bus *bus;
if (!slot)
- return retval;
+ return -ENOENT;
- value = slot->location;
- retval = sprintf (buf, "%s\n", value);
+ bus = slot->bus;
+ if (!bus)
+ return -ENOENT;
+
+ if (bus->self)
+ retval = sprintf(buf, pci_name(bus->self));
+ else
+ retval = sprintf(buf, "%04x:%02x:00.0",
+ pci_domain_nr(bus), bus->number);
+
return retval;
}
-static struct hotplug_slot_attribute php_attr_location = {
- .attr = {.name = "phy_location", .mode = S_IFREG | S_IRUGO},
- .show = location_read_file,
+static struct hotplug_slot_attribute php_attr_address = {
+ .attr = {.name = "address", .mode =
Re: [BUG] New Kernel Bugs
On Tuesday 13 November 2007 07:08, Mark Lord wrote: > Ingo Molnar wrote: > .. > > > This is all QA-101 that _cannot be argued against on a rational basis_, > > it's just that these sorts of things have been largely ignored for > > years, in favor of the all-too-easy "open source means many eyeballs and > > that is our QA" answer, which is a _good_ answer but by far not the most > > intelligent answer! Today "many eyeballs" is simply not good enough and > > nature (and other OS projects) will route us around if we dont change. > > .. > > QA-101 and "many eyeballs" are not at all in opposition. > The latter is how we find out about bugs on uncommon hardware, > and the former is what we need to track them and overall quality. > > A HUGE problem I have with current "efforts", is that once someone > reports a bug, the onus seems to be 99% on the *reporter* to find > the exact line of code or commit. Ghad what a repressive method. This is the only method that scales. Developer has only 24 hours in each day, and sometimes he needs to eat, sleep, and maybe even pay attention to e.g. his kids. But bug reporters are much more numerous and they have more hours in one day combined. BUT - it means that developers should try to increase user base, not scare users away. > And if the "developer" who broke the damn thing, or who at least > "claims" to be supporting that code, cannot "reproduce" the bug, > they drop it completely. Developer should let reporter know that reporter needs to help a bit here. Sometimes a bit of hand holding is needed, but it pays off because you breed more qualified testers/bug reporters. > Contrast that flawed approach with how Linus does things.. > he thinks through the symptoms, matches them to the code, > and figures out what the few possibilities might be, > and feeds back some trial balloon patches for the bug reporter to try. > > MUCH better. > > And remember, *I'm* an old-time Linux kernel developer.. just think about > the people reporting bugs who haven't been around here since 1992.. Yes. Developers should not grow more and more unhelpful and arrogant towards their users just because inexperienced users send incomplete/poorly written bug reports. They need to provide help, not humiliate/ignore. I think we agree here. -- vda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] [PATCH 000 of 2] md: Fixes for md in 2.6.23
On Tue, Nov 13, 2007 at 04:22:14PM -0800, Greg KH wrote: > On Mon, Oct 22, 2007 at 05:15:27PM +1000, NeilBrown wrote: > > > > It appears that a couple of bugs slipped in to md for 2.6.23. > > These two patches fix them and are appropriate for 2.6.23.y as well > > as 2.6.24-rcX > > > > Thanks, > > NeilBrown > > > > [PATCH 001 of 2] md: Fix an unsigned compare to allow creation of bitmaps > > with v1.0 metadata. > > [PATCH 002 of 2] md: raid5: fix clearing of biofill operations > > I don't see these patches in 2.6.24-rcX, are they there under some other > subject? Oh nevermind, I found them, sorry for the noise... 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 5/8] Immediate Values - x86 Optimization (update)
* H. Peter Anvin ([EMAIL PROTECTED]) wrote: > Mathieu Desnoyers wrote: >> Andi seemed to trust gas stability and you answered: >> "The comment was referring to x86-64, but I incorrectly remembered that >> applying to "movq $imm,%reg" as opposed to loading from an absolute >> address. gas actually has a special opcode (movabs) for the 64-bit >> version of the latter variant, which is only available with %rax and its >> subregisters. >> Nevermind, in other words. It's still true, though, that the immediate >> will always be the last thing in the instruction -- that's a fixture of >> the instruction format." >> So, in the end, is there a way to make x86_64 use a fixed-size opcode >> for the 1, 2, 4 and 8 bytes load immediates or we will have to force the >> use of a specific register ? >> (and we can't take a pointer from the end of the instruction, because we >> need to align the immediate value correctly) > > For a 64-bit load, you'll always have a REX prefix. For 8-, 16- and 32-bit > load, the length of the instruction will depend on the register chosen, > unless you constrain to either all legacy or all upper registers, or you > force gas to generate a prefix, but I don't think there is a way to do that > that will work with assemblers all the way back to 2.12, which is at least > what we officially support (I have no idea if assemblers that far back > actually *work*, mind you.) > > -hpa Ok, so the most flexible solution that I see, that should fit for both i386 and x86_64 would be : 1 byte : "=Q" : Any register accessible as rh: a, b, c, and d. 2, 4 bytes : "=R" : Legacy register—the eight integer registers available on all i386 processors (a, b, c, d, si, di, bp, sp). 8 bytes : (only for x86_64) "=r" : A register operand is allowed provided that it is in a general register. That should make sure x86_64 won't try to use REX prefixed opcodes for 1, 2 and 4 bytes values. Does it make sense ? Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [perfmon] Re: [perfmon2] perfmon2 merge news
Hi Andi, pfmon is a single tool and fairly low level, the HPC folks don't use it so much because it isn't parallel aware and is meant for power- users. It is not representative of the tools used in HPC at all. Our community uses tools built on the infrastructure provided by libpfm and PAPI for the most part. I know you don't want to hear this, but we actually use all of the features of perfmon, because a) we wanted to use the best methods available and b) areas where user level solutions could be made (like multiplexing) introduced too much noise and overhead to be of use. For years we relied on PerfCtr which did 'just enough' for us. But when Perfmon2 became available, we adopted technology where it meant a significant increase in accuracy for the resulting measurements, specifically for us that meant, kernel multiplexing and sample buffers. Note that PAPI is just middleware. The tools built upon it are what people use...some of those are commercial tools like Vampir but most are Open Source. These tools are cross platform, as such they run on nearly everything...although intel/amd/ppc systems dominate the HPC market. The usage cases are always the same and can be broken down into simple counting and sampling: - providing virtualized 64-bit counters per-thread - providing notification (buffered or non) on interrupt/overflow of the above. If you'd like to outline further what you'd like to hear from the community, I can arrange that. I seem to remember going through this once before, but I'd be happy to do it again. For reference, here's a quick list from memory of some of the tools in active use and built on this infrastructure. These are used heavily around the globe. You'll see that each basically follows one of the 2 usage models above. - HPCToolkit (Rice) - PerfSuite (NCSA) - Vampir (Dresden) - Kojak (Juelich) - TAU (UOregon) - PAPIEX (me) - GPTL (NCAR) - HPM-Linux (IBM) - Paraver (Barcelona) Time to go give a talk here at a tools session at SC'07 about this very subject. Phil On Nov 13, 2007, at 12:36 PM, Andi Kleen wrote: He speaks for quite a few people - they have serious need for this feature Most likely they have serious need for a very small subset of perfmon2. The point of my proposal was to get this very small subset in quickly. Phil, how many of the command line options of pfmon do you actually use? How many do the people at your conference use? Or what functions, what performance counters etc. in PAPI or whatever library you use? Make use understand the use cases better, that would already help a lot in merging by concentrating on what people actually really need. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] [PATCH 000 of 2] md: Fixes for md in 2.6.23
On Mon, Oct 22, 2007 at 05:15:27PM +1000, NeilBrown wrote: > > It appears that a couple of bugs slipped in to md for 2.6.23. > These two patches fix them and are appropriate for 2.6.23.y as well > as 2.6.24-rcX > > Thanks, > NeilBrown > > [PATCH 001 of 2] md: Fix an unsigned compare to allow creation of bitmaps > with v1.0 metadata. > [PATCH 002 of 2] md: raid5: fix clearing of biofill operations I don't see these patches in 2.6.24-rcX, are they there under some other subject? 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 2.6.24-rc2 1/3] generic gpio -- gpio_chip support
On Wednesday 14 November 2007 06:22, David Brownell wrote: > On Tuesday 13 November 2007, Ingo Molnar wrote: > > * David Brownell <[EMAIL PROTECTED]> wrote: > > > > > I speculate that either the design has changed (without fanfare), > > > > > or else that stuff is in RT kernels and has not yet gone upstream. > > > > > > > > Well whatever. We shouldn't have to resort to caller-side party > > > > tricks like this to get acceptable performance. > > > > > > I'd be happy if, as originally presented, it were possible to just > > > pass a raw_spinlock_t to spin_lock_irqsave() and friends. > > > > that's a spinlock type abstraction of PREEMPT_RT, not of mainline. Even when you're talking about the -rt tree, I suspect you really shouldn't be using raw spinlocks, right? I mean, if you have a timing critical operation, then you should ensure you have priorities set correctly so that you simply don't get preempted. By using a raw_spinlock_t, you're saying that you're more important than anyone else (for the period of the critical section) including processes which the user has explicitly set to a higher priority. If you get preempted, then you should be happy, because didn't occur. > Any reason that stuff shouldn't move into mainline? This sort of raw_spinlock_t arms race throughout drivers/ would be a huge reason not to move it into mainline. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/9] AOUT: Mark arches that support A.OUT format [try #6]
On Tue, Nov 13, 2007 at 07:23:46PM -0500, Kyle McMartin wrote: > On Wed, Nov 14, 2007 at 12:18:42AM +, David Howells wrote: > > Mark arches that support A.OUT format by including the following in their > > master Kconfig files: > > > > config ARCH_SUPPORTS_AOUT > > def_bool y > > > ... > > Signed-off-by: David Howells <[EMAIL PROTECTED]> > > > > big Acked-by: Kyle McMartin <[EMAIL PROTECTED]> to the whole set > arch-dependant set... > except parisc doesn't support a.out :P cheers, kyle - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [13/45] x86_64: Increase VDSO_TEXT_OFFSET for ancient binutils
On Wednesday 14 November 2007 01:21:07 CaT wrote: > On Fri, Sep 21, 2007 at 10:44:54PM +0200, Andi Kleen wrote: > > For some reason old binutils genertate larger headers so > > increase the text offset of the vdso to avoid linker errors. > > > > Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> > > > > --- > > arch/x86_64/vdso/voffset.h |2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > Index: linux/arch/x86_64/vdso/voffset.h > > === > > --- linux.orig/arch/x86_64/vdso/voffset.h > > +++ linux/arch/x86_64/vdso/voffset.h > > @@ -1 +1 @@ > > -#define VDSO_TEXT_OFFSET 0x500 > > +#define VDSO_TEXT_OFFSET 0x600 > > This still breaks under Debian sarge. There is this (german) forum > thread about it: iirc sarge was the one with the unfixable 2MB text pages, generating gigantic vDSOs. At least from my side i essentially gave up on that one because there was no way to generate a reasonable vDSO. You'll need to either up- or downgrade your binutils. There was only a narrow window where binutils were broken such, but that release unfortunately hit it. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 9/9] MN10300: Add MTD flash support for the ASB2303 board [try #6]
Add MTD flash support for the ASB2303 board.
Signed-off-by: David Howells <[EMAIL PROTECTED]>
---
arch/mn10300/configs/asb2303_defconfig |1
drivers/mtd/chips/jedec_probe.c|2
drivers/mtd/maps/Kconfig |8 +
drivers/mtd/maps/Makefile |1
drivers/mtd/maps/asb2303-flash.c | 177
5 files changed, 189 insertions(+), 0 deletions(-)
diff --git a/arch/mn10300/configs/asb2303_defconfig
b/arch/mn10300/configs/asb2303_defconfig
index 7855257..75e2cd7 100644
--- a/arch/mn10300/configs/asb2303_defconfig
+++ b/arch/mn10300/configs/asb2303_defconfig
@@ -282,6 +282,7 @@ CONFIG_MTD_CFI_UTIL=y
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PHYSMAP is not set
# CONFIG_MTD_PLATRAM is not set
+CONFIG_MTD_ASB2303=y
#
# Self-contained MTD device drivers
diff --git a/drivers/mtd/chips/jedec_probe.c b/drivers/mtd/chips/jedec_probe.c
index 75fbdcf..a5330b7 100644
--- a/drivers/mtd/chips/jedec_probe.c
+++ b/drivers/mtd/chips/jedec_probe.c
@@ -1882,11 +1882,13 @@ static inline __u8 finfo_uaddr(const struct
amd_flash_info *finfo, int device_ty
uaddr = finfo->uaddr[uaddr_idx];
+#ifndef CONFIG_MN10300_UNIT_ASB2303
if (uaddr != MTD_UADDR_NOT_SUPPORTED ) {
/* ASSERT("The unlock addresses for non-8-bit mode
are bollocks. We don't really need an array."); */
uaddr = finfo->uaddr[0];
}
+#endif
uaddr_done:
return uaddr;
diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
index a592fc0..37157de 100644
--- a/drivers/mtd/maps/Kconfig
+++ b/drivers/mtd/maps/Kconfig
@@ -597,5 +597,13 @@ config MTD_PLATRAM
This selection automatically selects the map_ram driver.
+config MTD_ASB2303
+ tristate "CFI Flash device mapped on MEI ASB2303"
+ depends on MTD_CFI && MN10300_UNIT_ASB2303 && MTD_PARTITIONS
+ help
+ This enables access to the flash chips on the ASB2303 board with
+ the MN10300 processor.
+ Say 'Y' if you have this board.
+
endmenu
diff --git a/drivers/mtd/maps/Makefile b/drivers/mtd/maps/Makefile
index 316382a..6f28f35 100644
--- a/drivers/mtd/maps/Makefile
+++ b/drivers/mtd/maps/Makefile
@@ -69,3 +69,4 @@ obj-$(CONFIG_MTD_PLATRAM) += plat-ram.o
obj-$(CONFIG_MTD_OMAP_NOR) += omap_nor.o
obj-$(CONFIG_MTD_MTX1) += mtx-1_flash.o
obj-$(CONFIG_MTD_INTEL_VR_NOR) += intel_vr_nor.o
+obj-$(CONFIG_MTD_ASB2303) += asb2303-flash.o
diff --git a/drivers/mtd/maps/asb2303-flash.c b/drivers/mtd/maps/asb2303-flash.c
new file mode 100644
index 000..9962948
--- /dev/null
+++ b/drivers/mtd/maps/asb2303-flash.c
@@ -0,0 +1,177 @@
+/* Handle mapping of the flash on the ASB2303 board
+ *
+ * Copyright (C) 2007 Red Hat, Inc. All Rights Reserved.
+ * Written by David Howells ([EMAIL PROTECTED])
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public Licence
+ * as published by the Free Software Foundation; either version
+ * 2 of the Licence, or (at your option) any later version.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PROM_ADDR 0xA000
+#define FLASH_ADDR 0xA400
+#define CONFIG_ADDR0xA600
+
+static struct map_info asb2303_maps[2] = {
+ {
+ .name = "BootPROM",
+ .size = 2 * 1024 * 1024,
+ .bankwidth = 2,
+ .phys = PROM_ADDR,
+ }, {
+ .name = "SysFlash",
+ .size = 32 * 1024 * 1024,
+ .bankwidth = 4,
+ .phys = FLASH_ADDR,
+ }
+};
+
+static struct mtd_partition asb2303_partitions[] = {
+ {
+ .name = "Bootloader",
+ .size = 0x0004,
+ .offset = 0,
+ .mask_flags = MTD_WRITEABLE /* force read-only */
+ }, {
+ .name = "Kernel",
+ .size = 0x0040,
+ .offset = 0x0004,
+ }, {
+ .name = "Filesystem",
+ .size = MTDPART_SIZ_FULL,
+ .offset = 0x0044
+ }
+};
+
+static struct mtd_info *mymtds[3];
+static struct mtd_partition *parsed_parts[3];
+static int nr_parsed_parts[3];
+
+static const char *probes[] = { "RedBoot", "cmdlinepart", NULL };
+
+static int __init init_asb2303(void)
+{
+ int ret = 0, nr, i;
+
+ for (i = 0; i < ARRAY_SIZE(asb2303_maps); i++) {
+ printk(KERN_NOTICE
+ "Probing ASB2303 %s device: %08lx at %08lx\n",
+ asb2303_maps[i].name,
+ asb2303_maps[i].size,
+ (unsigned long) asb2303_maps[i].phys);
+
+
Re: [PATCH 2/9] AOUT: Mark arches that support A.OUT format [try #6]
On Wed, Nov 14, 2007 at 12:18:42AM +, David Howells wrote: > Mark arches that support A.OUT format by including the following in their > master Kconfig files: > > config ARCH_SUPPORTS_AOUT > def_bool y > ... > Signed-off-by: David Howells <[EMAIL PROTECTED]> > big Acked-by: Kyle McMartin <[EMAIL PROTECTED]> to the whole set arch-dependant set... Thanks, Kyle - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 6/9] USB: net2280 can't have a function called show_registers() [try #6]
net2280 can't have a function called show_registers() because this can produce
a namespace clash with an arch function of the same name.
All this driver's functions and variables should really be prefixed with
"net2280_" to avoid such a problem in future.
Signed-off-by: David Howells <[EMAIL PROTECTED]>
---
drivers/usb/gadget/net2280.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/net2280.c b/drivers/usb/gadget/net2280.c
index d5d473f..8afe3a4 100644
--- a/drivers/usb/gadget/net2280.c
+++ b/drivers/usb/gadget/net2280.c
@@ -1418,8 +1418,8 @@ show_function (struct device *_dev, struct
device_attribute *attr, char *buf)
}
static DEVICE_ATTR (function, S_IRUGO, show_function, NULL);
-static ssize_t
-show_registers (struct device *_dev, struct device_attribute *attr, char *buf)
+static ssize_t net2280_show_registers(struct device *_dev,
+ struct device_attribute *attr, char *buf)
{
struct net2280 *dev;
char*next;
@@ -1571,7 +1571,7 @@ show_registers (struct device *_dev, struct
device_attribute *attr, char *buf)
return PAGE_SIZE - size;
}
-static DEVICE_ATTR (registers, S_IRUGO, show_registers, NULL);
+static DEVICE_ATTR(registers, S_IRUGO, net2280_show_registers, NULL);
static ssize_t
show_queues (struct device *_dev, struct device_attribute *attr, char *buf)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 7/9] MN10300: Allocate serial port UART IDs for on-chip serial ports [try #6]
Allocate serial port UART type IDs for the MN10300 on-chip serial ports. Signed-off-by: David Howells <[EMAIL PROTECTED]> Acked-by: Alan Cox <[EMAIL PROTECTED]> --- include/linux/serial_core.h |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h index 6a5203f..04e1319 100644 --- a/include/linux/serial_core.h +++ b/include/linux/serial_core.h @@ -149,6 +149,9 @@ /* Freescale ColdFire */ #define PORT_MCF 78 +/* MN10300 on-chip UART numbers */ +#define PORT_MN10300 79 +#define PORT_MN10300_CTS 80 #ifdef __KERNEL__ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/9] AOUT: Suppress A.OUT library support if !CONFIG_ARCH_SUPPORTS_AOUT [try #6]
Suppress A.OUT library support if CONFIG_ARCH_SUPPORTS_AOUT is not set.
Not all architectures support the A.OUT binfmt, so the ELF binfmt should not
be permitted to go looking for A.OUT libraries to load in such a case. Not
only that, but under such conditions A.OUT core dumps are not produced either.
To make this work, this patch also does the following:
(1) Makes the existence of the contents of linux/a.out.h contingent on
CONFIG_ARCH_SUPPORTS_AOUT.
(2) Renames dump_thread() to aout_dump_thread() as it's only called by A.OUT
core dumping code.
(3) Moves aout_dump_thread() into asm/a.out-core.h and makes it inline. This
is then included only where needed. This means that this bit of arch
code will be stored in the appropriate A.OUT binfmt module rather than
the core kernel.
(4) Drops A.OUT support for Blackfin (according to Mike Frysinger it's not
needed) and FRV.
This patch depends on the previous patch to move STACK_TOP[_MAX] out of
asm/a.out.h and into asm/processor.h as they're required whether or not A.OUT
format is available.
Signed-off-by: David Howells <[EMAIL PROTECTED]>
---
arch/alpha/kernel/process.c | 62 ---
arch/arm/kernel/process.c | 29 -
arch/blackfin/kernel/bfin_ksyms.c |1
arch/blackfin/kernel/process.c | 45 ---
arch/m68k/kernel/process.c | 47
arch/sparc/kernel/process.c | 32 --
arch/sparc/kernel/sparc_ksyms.c |2 -
arch/sparc64/kernel/binfmt_aout32.c |3 +
arch/sparc64/kernel/process.c | 11 -
arch/um/kernel/ksyms.c |1
arch/um/kernel/process.c|5 --
arch/x86/kernel/process_32.c| 43 ---
fs/Kconfig.binfmt |3 +
fs/binfmt_aout.c|3 +
fs/binfmt_elf.c | 34 +++
fs/exec.c |2 -
include/asm-alpha/a.out-core.h | 81 +++
include/asm-arm/a.out-core.h| 50 ++
include/asm-frv/a.out.h |5 --
include/asm-generic/Kbuild.asm |2 +
include/asm-m68k/a.out-core.h | 69 ++
include/asm-sparc/a.out-core.h | 55
include/asm-sparc64/a.out-core.h| 31 +
include/asm-um/a.out-core.h | 27
include/asm-x86/a.out-core.h| 67 +
include/linux/Kbuild|2 +
include/linux/a.out.h | 12 +
include/linux/kernel.h |2 -
28 files changed, 429 insertions(+), 297 deletions(-)
diff --git a/arch/alpha/kernel/process.c b/arch/alpha/kernel/process.c
index 92b6162..9aed477 100644
--- a/arch/alpha/kernel/process.c
+++ b/arch/alpha/kernel/process.c
@@ -318,68 +318,6 @@ copy_thread(int nr, unsigned long clone_flags, unsigned
long usp,
}
/*
- * Fill in the user structure for an ECOFF core dump.
- */
-void
-dump_thread(struct pt_regs * pt, struct user * dump)
-{
- /* switch stack follows right below pt_regs: */
- struct switch_stack * sw = ((struct switch_stack *) pt) - 1;
-
- dump->magic = CMAGIC;
- dump->start_code = current->mm->start_code;
- dump->start_data = current->mm->start_data;
- dump->start_stack = rdusp() & ~(PAGE_SIZE - 1);
- dump->u_tsize = ((current->mm->end_code - dump->start_code)
->> PAGE_SHIFT);
- dump->u_dsize = ((current->mm->brk + PAGE_SIZE-1 - dump->start_data)
->> PAGE_SHIFT);
- dump->u_ssize = (current->mm->start_stack - dump->start_stack
-+ PAGE_SIZE-1) >> PAGE_SHIFT;
-
- /*
-* We store the registers in an order/format that is
-* compatible with DEC Unix/OSF/1 as this makes life easier
-* for gdb.
-*/
- dump->regs[EF_V0] = pt->r0;
- dump->regs[EF_T0] = pt->r1;
- dump->regs[EF_T1] = pt->r2;
- dump->regs[EF_T2] = pt->r3;
- dump->regs[EF_T3] = pt->r4;
- dump->regs[EF_T4] = pt->r5;
- dump->regs[EF_T5] = pt->r6;
- dump->regs[EF_T6] = pt->r7;
- dump->regs[EF_T7] = pt->r8;
- dump->regs[EF_S0] = sw->r9;
- dump->regs[EF_S1] = sw->r10;
- dump->regs[EF_S2] = sw->r11;
- dump->regs[EF_S3] = sw->r12;
- dump->regs[EF_S4] = sw->r13;
- dump->regs[EF_S5] = sw->r14;
- dump->regs[EF_S6] = sw->r15;
- dump->regs[EF_A3] = pt->r19;
- dump->regs[EF_A4] = pt->r20;
- dump->regs[EF_A5] = pt->r21;
- dump->regs[EF_T8] = pt->r22;
- dump->regs[EF_T9] = pt->r23;
- dump->regs[EF_T10] = pt->r24;
- dump->regs[EF_T11] = pt->r25;
- dump->regs[EF_RA] = pt->r26;
- dump->regs[EF_T12] = pt->r27;
- dump->regs[EF_AT] = pt->r28;
-
[PATCH 5/9] MTD: Add support for the SST 39VF1601 flash chip [try #6]
Add support for the SST 39VF1601 flash chip.
Signed-off-by: David Howells <[EMAIL PROTECTED]>
---
drivers/mtd/chips/jedec_probe.c | 16 +++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/chips/jedec_probe.c b/drivers/mtd/chips/jedec_probe.c
index a67b23b..75fbdcf 100644
--- a/drivers/mtd/chips/jedec_probe.c
+++ b/drivers/mtd/chips/jedec_probe.c
@@ -1527,7 +1527,21 @@ static const struct amd_flash_info jedec_table[] = {
ERASEINFO(0x1000,256),
ERASEINFO(0x1000,256)
}
-
+ }, {
+ .mfr_id = MANUFACTURER_SST, /* should be CFI */
+ .dev_id = SST39VF1601,
+ .name = "SST 39VF1601",
+ .uaddr = {
+ [0] = MTD_UADDR_0x_0x2AAA, /* x8 */
+ [1] = MTD_UADDR_0x_0x2AAA /* x16 */
+ },
+ .DevSize= SIZE_2MiB,
+ .CmdSet = P_ID_AMD_STD,
+ .NumEraseRegions = 2,
+ .regions= {
+ ERASEINFO(0x1000, 256),
+ ERASEINFO(0x1000, 256)
+ }
}, {
.mfr_id = MANUFACTURER_ST,
.dev_id = M29F800AB,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/9] AOUT: Remove unnecessary inclusions of {asm, linux}/a.out.h [try #6]
Remove now unnecessary inclusions of {asm,linux}/a.out.h.
Signed-off-by: David Howells <[EMAIL PROTECTED]>
---
arch/alpha/kernel/osf_sys.c |1 -
arch/alpha/kernel/process.c |1 -
arch/alpha/kernel/setup.c |1 -
arch/arm/kernel/process.c |1 -
arch/blackfin/kernel/process.c |1 -
arch/m68k/kernel/process.c |1 -
arch/m68k/kernel/traps.c|1 -
arch/sparc/kernel/process.c |1 -
arch/sparc/kernel/setup.c |1 -
arch/sparc/kernel/sparc_ksyms.c |1 -
arch/sparc/mm/loadmmu.c |1 -
arch/sparc/mm/srmmu.c |1 -
arch/sparc64/kernel/binfmt_elf32.c |2 --
arch/sparc64/kernel/process.c |1 -
arch/sparc64/kernel/setup.c |1 -
arch/sparc64/kernel/sparc64_ksyms.c |1 -
arch/sparc64/kernel/sys_sparc.c |1 -
arch/sparc64/kernel/sys_sparc32.c |1 -
arch/um/kernel/ksyms.c |1 -
arch/x86/kernel/process_32.c|1 -
arch/x86/kernel/process_64.c|1 -
arch/x86/kernel/setup_64.c |1 -
fs/exec.c |1 -
fs/proc/kcore.c |1 -
include/asm-sparc/uaccess.h |1 -
include/asm-sparc64/processor.h |1 -
include/asm-sparc64/uaccess.h |1 -
27 files changed, 0 insertions(+), 28 deletions(-)
diff --git a/arch/alpha/kernel/osf_sys.c b/arch/alpha/kernel/osf_sys.c
index 6413c5f..c8cf2f9 100644
--- a/arch/alpha/kernel/osf_sys.c
+++ b/arch/alpha/kernel/osf_sys.c
@@ -22,7 +22,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/arch/alpha/kernel/process.c b/arch/alpha/kernel/process.c
index 9aed477..96ed82f 100644
--- a/arch/alpha/kernel/process.c
+++ b/arch/alpha/kernel/process.c
@@ -19,7 +19,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/arch/alpha/kernel/setup.c b/arch/alpha/kernel/setup.c
index bd5e68c..c044db0 100644
--- a/arch/alpha/kernel/setup.c
+++ b/arch/alpha/kernel/setup.c
@@ -18,7 +18,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 436380a..46bf2ed 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -18,7 +18,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/arch/blackfin/kernel/process.c b/arch/blackfin/kernel/process.c
index 1a8cf33..8bf6b96 100644
--- a/arch/blackfin/kernel/process.c
+++ b/arch/blackfin/kernel/process.c
@@ -31,7 +31,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/arch/m68k/kernel/process.c b/arch/m68k/kernel/process.c
index 5f45567..5de4e4e 100644
--- a/arch/m68k/kernel/process.c
+++ b/arch/m68k/kernel/process.c
@@ -23,7 +23,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/arch/m68k/kernel/traps.c b/arch/m68k/kernel/traps.c
index 97f556f..fd4858e 100644
--- a/arch/m68k/kernel/traps.c
+++ b/arch/m68k/kernel/traps.c
@@ -23,7 +23,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/arch/sparc/kernel/process.c b/arch/sparc/kernel/process.c
index a248e81..19186ce 100644
--- a/arch/sparc/kernel/process.c
+++ b/arch/sparc/kernel/process.c
@@ -20,7 +20,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/arch/sparc/kernel/setup.c b/arch/sparc/kernel/setup.c
index f822838..dbd1f6d 100644
--- a/arch/sparc/kernel/setup.c
+++ b/arch/sparc/kernel/setup.c
@@ -16,7 +16,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/arch/sparc/kernel/sparc_ksyms.c b/arch/sparc/kernel/sparc_ksyms.c
index 62f6221..c1025e5 100644
--- a/arch/sparc/kernel/sparc_ksyms.c
+++ b/arch/sparc/kernel/sparc_ksyms.c
@@ -51,7 +51,6 @@
#ifdef CONFIG_PCI
#include
#endif
-#include
#include
#include
diff --git a/arch/sparc/mm/loadmmu.c b/arch/sparc/mm/loadmmu.c
index 36b4d24..2d9cd65 100644
--- a/arch/sparc/mm/loadmmu.c
+++ b/arch/sparc/mm/loadmmu.c
@@ -14,7 +14,6 @@
#include
#include
#include
-#include
#include
#include
diff --git a/arch/sparc/mm/srmmu.c b/arch/sparc/mm/srmmu.c
index 17b485f..dc98e38 100644
--- a/arch/sparc/mm/srmmu.c
+++ b/arch/sparc/mm/srmmu.c
@@ -34,7 +34,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/arch/sparc64/kernel/binfmt_elf32.c
b/arch/sparc64/kernel/binfmt_elf32.c
index 1587a29..bf635be 100644
--- a/arch/sparc64/kernel/binfmt_elf32.c
+++ b/arch/sparc64/kernel/binfmt_elf32.c
@@ -151,8 +151,6 @@ MODULE_AUTHOR("Eric Youngdale, David S. Miller, Jakub
Jelinek");
#undef MODULE_DESCRIPTION
#undef MODULE_AUTHOR
-#include
-
#undef TASK_SIZE
#define TASK_SIZE STACK_TOP32
diff --git a/arch/sparc64/kernel/process.c b/arch/sparc64/kernel/process.c
index
[PATCH 2/9] AOUT: Mark arches that support A.OUT format [try #6]
Mark arches that support A.OUT format by including the following in their master Kconfig files: config ARCH_SUPPORTS_AOUT def_bool y This should also be set if the arch provides compatibility A.OUT support for an older arch, for instance x86_64 for i386 or sparc64 for sparc. I've guessed at which arches don't, based on comments in the code, however I'm sure that some of the ones I've marked as 'yes' actually should be 'no'. Signed-off-by: David Howells <[EMAIL PROTECTED]> --- arch/alpha/Kconfig |3 +++ arch/arm/Kconfig |3 +++ arch/avr32/Kconfig |3 +++ arch/blackfin/Kconfig |3 +++ arch/cris/Kconfig |3 +++ arch/frv/Kconfig |3 +++ arch/h8300/Kconfig |3 +++ arch/ia64/Kconfig |3 +++ arch/m32r/Kconfig |3 +++ arch/m68k/Kconfig |3 +++ arch/m68knommu/Kconfig |3 +++ arch/mips/Kconfig |3 +++ arch/parisc/Kconfig|3 +++ arch/powerpc/Kconfig |3 +++ arch/ppc/Kconfig |3 +++ arch/s390/Kconfig |3 +++ arch/sh/Kconfig|3 +++ arch/sh64/Kconfig |3 +++ arch/sparc/Kconfig |3 +++ arch/sparc64/Kconfig |3 +++ arch/um/Kconfig.i386 |2 ++ arch/um/Kconfig.x86_64 |2 ++ arch/v850/Kconfig |3 +++ arch/xtensa/Kconfig|3 +++ 24 files changed, 70 insertions(+), 0 deletions(-) diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig index 4c002ba..92e0c9f 100644 --- a/arch/alpha/Kconfig +++ b/arch/alpha/Kconfig @@ -66,6 +66,9 @@ config AUTO_IRQ_AFFINITY depends on SMP default y +config ARCH_SUPPORTS_AOUT + def_bool y + source "init/Kconfig" diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index a0cdaaf..ded0725 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -114,6 +114,9 @@ config GENERIC_CALIBRATE_DELAY bool default y +config ARCH_SUPPORTS_AOUT + def_bool y + config ARCH_MAY_HAVE_PC_FDC bool diff --git a/arch/avr32/Kconfig b/arch/avr32/Kconfig index bbecbd8..6ee54d9 100644 --- a/arch/avr32/Kconfig +++ b/arch/avr32/Kconfig @@ -70,6 +70,9 @@ config GENERIC_BUG default y depends on BUG +config ARCH_SUPPORTS_AOUT + def_bool y + source "init/Kconfig" menu "System Type and features" diff --git a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig index 9f9de3e..b184c06 100644 --- a/arch/blackfin/Kconfig +++ b/arch/blackfin/Kconfig @@ -69,6 +69,9 @@ config GENERIC_CALIBRATE_DELAY bool default y +config ARCH_SUPPORTS_AOUT + def_bool n + config IRQCHIP_DEMUX_GPIO bool depends on (BF52x || BF53x || BF561 || BF54x) diff --git a/arch/cris/Kconfig b/arch/cris/Kconfig index 21900a9..74ce4c1 100644 --- a/arch/cris/Kconfig +++ b/arch/cris/Kconfig @@ -47,6 +47,9 @@ config IRQ_PER_CPU config NO_IOPORT def_bool y +config ARCH_SUPPORTS_AOUT + def_bool n + config CRIS bool default y diff --git a/arch/frv/Kconfig b/arch/frv/Kconfig index 43153e7..49056a9 100644 --- a/arch/frv/Kconfig +++ b/arch/frv/Kconfig @@ -57,6 +57,9 @@ config ARCH_HAS_ILOG2_U64 bool default y +config ARCH_SUPPORTS_AOUT + def_bool n + mainmenu "Fujitsu FR-V Kernel Configuration" source "init/Kconfig" diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig index ff6a871..7009b0e 100644 --- a/arch/h8300/Kconfig +++ b/arch/h8300/Kconfig @@ -65,6 +65,9 @@ config TIME_LOW_RES bool default y +config ARCH_SUPPORTS_AOUT + def_bool y + config NO_IOPORT def_bool y diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig index bef4772..02793f0 100644 --- a/arch/ia64/Kconfig +++ b/arch/ia64/Kconfig @@ -99,6 +99,9 @@ config AUDIT_ARCH bool default y +config ARCH_SUPPORTS_AOUT + def_bool n + choice prompt "System type" default IA64_GENERIC diff --git a/arch/m32r/Kconfig b/arch/m32r/Kconfig index ab9a264..7c96765 100644 --- a/arch/m32r/Kconfig +++ b/arch/m32r/Kconfig @@ -34,6 +34,9 @@ config NO_IOPORT config NO_DMA def_bool y +config ARCH_SUPPORTS_AOUT + def_bool y + source "init/Kconfig" diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig index 01dee84..8d35d9d 100644 --- a/arch/m68k/Kconfig +++ b/arch/m68k/Kconfig @@ -52,6 +52,9 @@ config NO_IOPORT config NO_DMA def_bool SUN3 +config ARCH_SUPPORTS_AOUT + def_bool y + mainmenu "Linux/68k Kernel Configuration" source "init/Kconfig" diff --git a/arch/m68knommu/Kconfig b/arch/m68knommu/Kconfig index f4b582c..8de61df 100644 --- a/arch/m68knommu/Kconfig +++ b/arch/m68knommu/Kconfig @@ -60,6 +60,9 @@ config TIME_LOW_RES config NO_IOPORT def_bool y +config ARCH_SUPPORTS_AOUT + def_bool y + source "init/Kconfig" menu "Processor type and features" diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 2c7d6c2..b6e0418 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -722,6 +722,9 @@ config
[PATCH 1/9] AOUT: Move STACK_TOP[_MAX] to asm/processor.h [try #6]
Move STACK_TOP[_MAX] out of asm/a.out.h and into asm/processor.h as they're
required whether or not A.OUT format is available.
Signed-off-by: David Howells <[EMAIL PROTECTED]>
---
include/asm-alpha/a.out.h |8 +---
include/asm-alpha/processor.h |5 +
include/asm-arm/a.out.h|6 --
include/asm-arm/processor.h|6 ++
include/asm-avr32/a.out.h |7 ---
include/asm-avr32/processor.h |5 +
include/asm-blackfin/a.out.h |6 --
include/asm-blackfin/processor.h |4
include/asm-cris/a.out.h |6 --
include/asm-cris/processor.h |3 +++
include/asm-h8300/a.out.h |7 ---
include/asm-h8300/processor.h |5 +
include/asm-ia64/a.out.h |3 ---
include/asm-m32r/a.out.h |7 ---
include/asm-m32r/processor.h |5 +
include/asm-m68k/a.out.h |7 ---
include/asm-m68k/processor.h |5 +
include/asm-mips/a.out.h | 13 -
include/asm-mips/processor.h |7 +++
include/asm-parisc/a.out.h | 10 --
include/asm-parisc/processor.h | 10 ++
include/asm-powerpc/a.out.h| 19 ---
include/asm-powerpc/processor.h| 19 +++
include/asm-s390/a.out.h |7 ---
include/asm-s390/processor.h |7 +++
include/asm-sh/a.out.h |7 ---
include/asm-sh/processor.h |7 +++
include/asm-sh64/a.out.h |7 ---
include/asm-sparc/a.out.h |9 -
include/asm-sparc/processor.h |4
include/asm-sparc64/a.out.h| 12
include/asm-sparc64/processor.h| 12
include/asm-sparc64/user.h |2 +-
include/asm-um/a.out.h | 13 -
include/asm-um/processor-generic.h |8
include/asm-x86/a.out.h| 10 --
include/asm-x86/processor_32.h |2 ++
include/asm-x86/processor_64.h |2 ++
include/asm-xtensa/a.out.h |5 -
include/asm-xtensa/processor.h |2 ++
40 files changed, 120 insertions(+), 169 deletions(-)
diff --git a/include/asm-alpha/a.out.h b/include/asm-alpha/a.out.h
index e43cf61..02ce847 100644
--- a/include/asm-alpha/a.out.h
+++ b/include/asm-alpha/a.out.h
@@ -98,11 +98,5 @@ struct exec
set_personality (((BFPM->sh_bang || EX.ah.entry < 0x1L \
? ADDR_LIMIT_32BIT : 0) | PER_OSF4))
-#define STACK_TOP \
- (current->personality & ADDR_LIMIT_32BIT ? 0x8000 : 0x0012000UL)
-
-#define STACK_TOP_MAX 0x0012000UL
-
-#endif
-
+#endif /* __KERNEL__ */
#endif /* __A_OUT_GNU_H__ */
diff --git a/include/asm-alpha/processor.h b/include/asm-alpha/processor.h
index 425b7b6..94afe58 100644
--- a/include/asm-alpha/processor.h
+++ b/include/asm-alpha/processor.h
@@ -20,6 +20,11 @@
*/
#define TASK_SIZE (0x400UL)
+#define STACK_TOP \
+ (current->personality & ADDR_LIMIT_32BIT ? 0x8000 : 0x0012000UL)
+
+#define STACK_TOP_MAX 0x0012000UL
+
/* This decides where the kernel will search for a free chunk of vm
* space during mmap's.
*/
diff --git a/include/asm-arm/a.out.h b/include/asm-arm/a.out.h
index d7165e8..79489fd 100644
--- a/include/asm-arm/a.out.h
+++ b/include/asm-arm/a.out.h
@@ -27,12 +27,6 @@ struct exec
#define M_ARM 103
-#ifdef __KERNEL__
-#define STACK_TOP ((current->personality == PER_LINUX_32BIT) ? \
-TASK_SIZE : TASK_SIZE_26)
-#define STACK_TOP_MAX TASK_SIZE
-#endif
-
#ifndef LIBRARY_START_TEXT
#define LIBRARY_START_TEXT (0x00c0)
#endif
diff --git a/include/asm-arm/processor.h b/include/asm-arm/processor.h
index 1bbf161..bd8029e 100644
--- a/include/asm-arm/processor.h
+++ b/include/asm-arm/processor.h
@@ -22,6 +22,12 @@
#include
#include
+#ifdef __KERNEL__
+#define STACK_TOP ((current->personality == PER_LINUX_32BIT) ? \
+TASK_SIZE : TASK_SIZE_26)
+#define STACK_TOP_MAX TASK_SIZE
+#endif
+
union debug_insn {
u32 arm;
u16 thumb;
diff --git a/include/asm-avr32/a.out.h b/include/asm-avr32/a.out.h
index 9f398ab..e46375a 100644
--- a/include/asm-avr32/a.out.h
+++ b/include/asm-avr32/a.out.h
@@ -17,11 +17,4 @@ struct exec
#define N_DRSIZE(a)((a).a_drsize)
#define N_SYMSIZE(a) ((a).a_syms)
-#ifdef __KERNEL__
-
-#define STACK_TOP TASK_SIZE
-#define STACK_TOP_MAX STACK_TOP
-
-#endif
-
#endif /* __ASM_AVR32_A_OUT_H */
diff --git a/include/asm-avr32/processor.h b/include/asm-avr32/processor.h
index 6a64833..545520e 100644
--- a/include/asm-avr32/processor.h
+++ b/include/asm-avr32/processor.h
@@ -13,6 +13,11 @@
#define TASK_SIZE 0x8000
+#ifdef __KERNEL__
+#define STACK_TOP TASK_SIZE
+#define STACK_TOP_MAX STACK_TOP
+#endif
+
#ifndef __ASSEMBLY__
[PATCH 0/9] MN10300: Add the MN10300 architecture to Linux kernel [try #6]
These patches add the MEI/Panasonic MN10300/AM33 architecture to the Linux
kernel.
The first four patches make it possible to suppress A.OUT support in the kernel
for an arch (CONFIG_ARCH_SUPPORTS_AOUT must be set to 'y' to unsuppress).
MN10300 does not support the AOUT binfmt, so the ELF binfmt should not be
permitted to go looking for AOUT libraries to load, nor should random bits of
the kernel depend on asm/a.out.h.
The fifth patch adds support for a flash chip not previously attested.
The sixth patch fixes a namespace collision in the net2280 USB driver.
The seventh patch allocates a couple of UART port type IDs.
The eighth patch adds the architecture itself, to be selected by ARCH=mn10300
on the make command line.
The ninth patch adds a map driver for the flashes on the ASB2303 board.
The patches can also be downloaded from:
http://people.redhat.com/~dhowells/mn10300/mn10300-arch.tar.bz2
A suitable toolchain can be downloaded from:
ftp://ftp.redhat.com/pub/redhat/gnupro/AM33/
The latest is currently:
am33-04r2-5/tools/i686-pc-linux-gnulibc2.3-x-am33_2.0-linux-gnu.tar.bz2
Changes:
(*) Split the A.OUT suppression patch at Adrian Bunk's request.
(*) Made the A.OUT support have to be explicitly requested by an arch that
uses it. This allows use of the {asm,linux}/a.out.h headers with or
without the enablement of CONFIG_BINFMT_AOUT or its equivalent.
(*) Sorted out a lot of checkpatch gripes to make Andrew happy. checkpatch
still gets a lot wrong, mostly due to the eighth patch adding an arch.
(*) Removed an addition to linux/kprobes.h and fixed the arch to deal with it
elsewhere.
David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] [PATCH 00/12] xen/paravirt_ops patches for 2.6.24
On Wed, Nov 14, 2007 at 12:53:33AM +0100, Andi Kleen wrote: > > > > Subject: [PATCH 12/12] xfs: eagerly remove vmap mappings to avoid > > > upsetting Xen > > This patch was the wrong fix anyways as discussed; David Chinner > finally came up with a better one. Ok, that's good to know, if someone wants to send me the correct one, that would be appreciated. Although, it's not like anyone actually uses the in-kernel Xen on 2.6.23, so it's probably not really worth 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 0/5][RFC] Physical PCI slot objects
On Tue, Nov 13, 2007 at 03:33:14PM -0800, Kristen Carlson Accardi wrote: > As far as being able to retrieve the slot number (which it seemed from > the HP manageablity application perspective is the goal here), that > information is available from userspace as well for at least standard PCI > and pcie based systems for occupied slots. For standard pci, you have > to make something up anyway - for shpchp we just use an incremental > number and combine it with the bus number to represent the slot. For > pcie, you can get this info from the slot capabilities register. Ummm ... that's not what the /spec/ says. I've never worked on any shpc machines, but the shpc driver reads the slot values from the SLOT_CONFIG register, just like the spec says to. I don't understand how you're supposed to get the slot number for standard PCI for occupied slots. Could you explain? -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
uml doesn't work on 2.6.24-rc2
UML doesn't run on 2.6.24-rc2 as host (config attached). Guest is 2.6.23-mm1, but I guess it's irrelevant. 2.6.23 as host was OK. When booting there are zillions of lines like this: "arch_switch_tls failed, errno = EINVAL" then it finally fails with: "BUG: spinlock cpu recursion on CPU#0, syslogd/434" Any ideas? Thanks, Miklos -- Core dump limits : soft - 0 hard - NONE Checking that ptrace can change system call numbers...OK Checking syscall emulation patch for ptrace...missing Checking for tmpfs mount on /dev/shm...nothing mounted on /dev/shm Checking PROT_EXEC mmap in /tmp/...OK Checking for the skas3 patch in the host: - /proc/mm...not found: No such file or directory - PTRACE_FAULTINFO...not found: Invalid argument - PTRACE_LDT...not found: Invalid argument UML running in SKAS0 mode [42949372.96] Linux version 2.6.23-mm1 ([EMAIL PROTECTED]) (gcc version 4.2.1 (SUSE Linux)) #2 Tue Nov 13 22:04:22 CET 2007 [42949372.96] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8128 [42949372.96] Kernel command line: root=98:0 [42949372.96] PID hash table entries: 128 (order: 7, 512 bytes) [42949372.96] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes) [42949372.96] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes) [42949372.96] Memory: 29964k available [42949373.22] Mount-cache hash table entries: 512 [42949373.22] Checking for host processor cmov support...Yes [42949373.22] Checking for host processor xmm support...No [42949373.22] Checking that host ptys support output SIGIO...Yes [42949373.22] Checking that host ptys support SIGIO on close...No, enabling workaround [42949373.22] net_namespace: 64 bytes [42949373.22] Using 2.6 host AIO [42949373.22] NET: Registered protocol family 16 [42949373.25] NET: Registered protocol family 2 [42949373.26] Time: itimer clocksource has been installed. [42949373.34] IP route cache hash table entries: 1024 (order: 0, 4096 bytes) [42949373.34] TCP established hash table entries: 1024 (order: 2, 20480 bytes) [42949373.34] TCP bind hash table entries: 1024 (order: 2, 20480 bytes) [42949373.34] TCP: Hash tables configured (established 1024 bind 1024) [42949373.34] TCP reno registered [42949373.37] Checking host MADV_REMOVE support...<3>MADV_REMOVE failed, err = -38 [42949373.37] Can't release memory to the host - memory hotplug won't be supported [42949373.37] mconsole (version 2) initialized on /home/mszeredi/.uml/uml/mconsole [42949373.37] Host TLS support detected [42949373.37] Detected host type: x86_64 [42949373.37] fuse init (API version 7.9) [42949373.37] io scheduler noop registered (default) [42949373.37] loop: module loaded [42949373.37] TCP cubic registered [42949373.37] NET: Registered protocol family 1 [42949373.37] Initialized stdio console driver [42949373.37] Console initialized on /dev/tty0 [42949373.37] console [tty0] enabled [42949373.37] console [mc-1] enabled [42949373.37] ubda: unknown partition table [42949388.31] EXT3-fs: INFO: recovery required on readonly filesystem. [42949388.31] EXT3-fs: write access will be enabled during recovery. [42950014.32] kjournald starting. Commit interval 5 seconds [42950014.32] EXT3-fs: recovery complete. [42950021.12] EXT3-fs: mounted filesystem with ordered data mode. [42950021.12] VFS: Mounted root (ext3 filesystem) readonly. [42950245.52] arch_switch_tls failed, errno = EINVAL [42950278.62] arch_switch_tls failed, errno = EINVAL [42950283.61] arch_switch_tls failed, errno = EINVAL -- # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-rc2 # Wed Nov 14 00:16:07 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set #
Re: 2.6.24-rc2: Network commit causes SLUB performance regression with tbench
On Tuesday 13 November 2007 06:44, Christoph Lameter wrote: > On Sat, 10 Nov 2007, Nick Piggin wrote: > > BTW. your size-2048 kmalloc cache is order-1 in the default setup, > > wheras kmalloc(1024) or kmalloc(4096) will be order-0 allocations. And > > SLAB also uses order-0 for size-2048. It would be nice if SLUB did the > > same... > > You can try to see the effect that order 0 would have by booting with > > slub_max_order=0 Yeah, that didn't help much, but in general I think it would give more consistent and reliable behaviour from slub. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 22/54] kset: convert /sys/devices/system to use kset_create
On Tue, 13 Nov 2007 15:14:10 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > On Mon, 5 Nov 2007 12:03:34 -0800 Greg KH <[EMAIL PROTECTED]> wrote: > > > > > > <4> [<00142548>] sys_reboot+0x1a4/0x1f4 > > > > > <4> [<00111038>] sysc_noemu+0x10/0x16 > > > > > <4> [<021048e0>] 0x21048e0 > > > > > <4> > > > > > <4> > > > > > > > > > > Huh? We want to shutdown an unknown device on a bus that wishes to > > > > > stay > > > > > anonymous? > > > > > > > > > > Any hints would be appreciated... > > > > > > > > I'll look into this, I wonder if we are walking off the end of an > > > > unterminated list... > > > > > > Could well be. If I'm using lcrash's walk function correctly (which > > > always manages to confuse me...), the list of devices_kset seems to be > > > broken. > > > > Alright, I can reproduce something like this at shutdown time myself > > here, I'll try to figure it out... > > > > The Vaio oopses during `reboot -f' and I bisected it down to this patch. > > http://userweb.kernel.org/~akpm/dsc00034.jpg > http://userweb.kernel.org/~akpm/config-sony.txt > http://userweb.kernel.org/~akpm/dmesg-sony.txt The G5 Mac oopses in the same place during `halt -pfn'. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] [PATCH 00/12] xen/paravirt_ops patches for 2.6.24
> > Subject: [PATCH 12/12] xfs: eagerly remove vmap mappings to avoid > > upsetting Xen This patch was the wrong fix anyways as discussed; David Chinner finally came up with a better one. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Posix file capabilities in 2.6.24rc2
Quoting Chris Friedhoff ([EMAIL PROTECTED]): > Hello, > > everything works as expected, but ... > > closing X and no capabilities set for xinit does shutdown only the > windowmanager and not the X server (Xorg server 1.4) > Consolemessage is: > xinit: Operation not permitted (errno 1): Can't kill X server > > > the xattr capability is removed, when the file is chown'ed. Hi Chris, yes on chown the capability is removed. I'm not quite sure what you're asking? Is your setup depending on being able to chown while keeping file capabilities? Can you give some more details? thanks, -serge - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Better support for Delkin cardbus CF adapters -- IDE layer
Bah, you're right. He gave me the name for the wrong device. It's really an Interfirm HS-CF32 device. He said the company has gone out of business, but a quick google shows an interfirm.co.jp site with this HS-CF32 device on it. I'll try and get specifications there. --Ron On Nov 13, 2007 5:57 PM, Alan Cox <[EMAIL PROTECTED]> wrote: > On Tue, 13 Nov 2007 17:04:57 -0500 > "Ron Yorgason" <[EMAIL PROTECTED]> wrote: > > > I received a response from Synchrotech, the supplier of one of my > > cards. He said that they were under NDA with their manufacturing > > partner and couldn't offer the full specs. However he could tell me > > the specific bridge chip: > > > > JMicron JMB368 PCIe to PATA controller > > Seems odd for the cardbus controller as cardbus is PCI not PCIe but would > make sense for Expresscard devices. In theory a Jmicron plug in card > would just work. > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 03:18:07PM -0500, Mark Lord wrote: > Russell King wrote: > > On Tue, Nov 13, 2007 at 09:08:32AM -0500, Mark Lord wrote: > >> Ingo Molnar wrote: > >> .. > >>> This is all QA-101 that _cannot be argued against on a rational basis_, > >>> it's just that these sorts of things have been largely ignored for > >>> years, in favor of the all-too-easy "open source means many eyeballs and > >>> that is our QA" answer, which is a _good_ answer but by far not the most > >>> intelligent answer! Today "many eyeballs" is simply not good enough and > >>> nature (and other OS projects) will route us around if we dont change. > >> .. > >> > >> QA-101 and "many eyeballs" are not at all in opposition. > >> The latter is how we find out about bugs on uncommon hardware, > >> and the former is what we need to track them and overall quality. > >> > >> A HUGE problem I have with current "efforts", is that once someone > >> reports a bug, the onus seems to be 99% on the *reporter* to find > >> the exact line of code or commit. Ghad what a repressive method. > > > > 99% on the reporter? Is that why I always try to understand the > > reporters problem (*provided* it's in an area I know about) and come > > up with a patch to test a theory or fix the issue? > .. > > Same here. > > I just find it weird that something can be known broken for several -rc* > kernels before I happen to install it, discover it's broken on my own machine, > and then I track it down, fix it, and submit the patch, generally all within a > couple of hours. Where the heck was the dude(ess) that broke it ?? AWOL. Same thing can be said for compile breakages as well. Looking at the latest kautobuild output: ARM ep93xx defconfig has been broken since 2.6.23-git1 due to: drivers/net/arm/ep93xx_eth.c:420: error: implicit declaration of function '__netif_rx_schedule_prep' caused by: [NET]: Make NAPI polling independent of struct net_device objects. ARM netx defconfig has been broken since 2.6.23-git1 due to: drivers/net/netx-eth.c: In function 'netx_eth_hard_start_xmit': drivers/net/netx-eth.c:131: error: 'dev' undeclared (first use in this function) drivers/net/netx-eth.c:131: error: (Each undeclared identifier is reported only once drivers/net/netx-eth.c:131: error: for each function it appears in.) drivers/net/netx-eth.c: In function 'netx_eth_receive': drivers/net/netx-eth.c:158: error: 'dev' undeclared (first use in this function) caused by: [NET] drivers/net: statistics cleanup #1 -- save memory and shrink code Haven't got a report for either of those, but Kautobuild lets people know if folk can be bothered to subscribe to its mailing list and/or look at the site occasionally. I suspect the maintainers of the above drivers aren't aware that their drivers are broken. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.24-rc2 slab vs slob tbench numbers
On Tuesday 13 November 2007 07:13, Matt Mackall wrote: > On Fri, Nov 09, 2007 at 11:36:56PM +1100, Nick Piggin wrote: > > Hi, > > > > Just ran some tbench numbers (from dbench-3.04), on a 2 socket, 8 > > core x86 system, with 1 NUMA node per socket. With kernel 2.6.24-rc2, > > comparing slab vs slub allocators. > > Damn your misleading subject! I thought this was going to be about > something interesting. Actually I did test slob as well -- it's competitive with slab and slub up to about 4 cores, which is nice. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] powerpc: Add support for PORTA and PORTB odr registers
Jochen Friedrich wrote:
@@ -474,6 +481,12 @@ static void cpm1_set_pin16(int port, int pin, int
flags)
else
clrbits16(>par, pin);
+if (port == CPM_PORTA) {
+if (flags & CPM_PIN_OPENDRAIN)
+setbits16(>odr, pin);
+else
+clrbits16(>odr, pin);
+}
if (port == CPM_PORTC) {
if (flags & CPM_PIN_SECONDARY)
setbits16(>sor, pin);
Where is the odr field of cpm_ioport16 defined? It's the same position
as sor, so maybe call it odr_sor or something.
Also, please add an extra newline after the closing brace.
-Scott
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] New Kernel Bugs
On Tue, 13 Nov 2007 23:29:54 + Russell King <[EMAIL PROTECTED]> wrote: > On Tue, Nov 13, 2007 at 09:13:19PM +0100, Adrian Bunk wrote: > > On Tue, Nov 13, 2007 at 07:32:19PM +, Russell King wrote: > > >... > > > There's another issue I want to raise concerning bugzilla. We have the > > > classic case of "not enough people reading bugzilla bugs" - which is one > > > of the biggest problems with bugzilla. Virtually no one in the ARM > > > community looks for ARM bugs in bugzilla. > > > > > > Let's not forget that it would be a waste of time for people to manually > > > check bugzilla for ARM bugs. There's soo few people reporting ARM bugs > > > into bugzilla that a weekly manual check by every maintainer would just > > > return the same old boring results for months and months at a time. > > >... > > > > What about having all ARM bugs in Bugzilla by default assigned to > > [EMAIL PROTECTED] [1] > > That would also work, probably much better than setting up yet another > list. cpufreq (at least) does it this way. I don't know how well it is turning out in practice. It's useful if the initial report makes it clear (ie; to me) that the report has already gone to a mailing list so I don't go and forward a duplicate. But there are so few arm reports in bugzilla that this is all rather moot. > My experience of trying to get mbligh to do this when I stopped looking > after PCMCIA stuff was *extremely* painful. Wonder if it's become any > easier of late? He's a bad, bad man ;) But he's been turning these things around pretty rapidly lately. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] New Kernel Bugs
Thomas Gleixner wrote: On Tue, 13 Nov 2007, Mark Lord wrote: Thomas Gleixner wrote: On Tue, 13 Nov 2007, Mark Lord wrote: Andrew Morton wrote: On Mon, 12 Nov 2007 22:42:32 -0800 "Natalie Protasevich" <[EMAIL PROTECTED]> wrote: .. with CONFIG_NO_HZ and/or CONFIG_HPET_TIMER set kernel 2.6.23 doesn't boot (ARM, Timer) http://bugzilla.kernel.org/show_bug.cgi?id=9229 Kernel: 2.6.23 No response from developers .. The bug report is bogus. ARM has no CONFIG_HPET_TIMER. Note: that same bug exists/existed on i386 back when NO_HZ was introduced (2.6.21?). I still see it from time to time on my Quad core system (very rare), but not any more on my Duo notebook where it used to happen about 1 in n boots (n < 10). AFAICT no fix was ever released for it. Hmm, at which point does the boot stop ? .. Just as it prints out these messages, sometimes one of them, sometimes both (or all four on the quad core): kernel: switched to high resolution mode on cpu 1 kernel: switched to high resolution mode on cpu 0 It's completely dead afterwards ? Yeah. No magic sysrq key or anything. There's gotta be a race somewhere that's causing it, but it's not obvious where to look for it. My regular 2-core notebook no longer suffers from it, and subtle .config changes used to make it come and go back when it first appeared. The quad-core has only done it twice on me thus far. Tracking this one down looks tricky. It might require some early lockup detection code to be tailor made or something. Cheers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] [PATCH 00/12] xen/paravirt_ops patches for 2.6.24
On Mon, Oct 15, 2007 at 02:59:50PM -0700, Jeremy Fitzhardinge wrote: > Greg KH wrote: > > Yeah, but you cc:ed all 12 patches to [EMAIL PROTECTED] The majority of > > which we > > don't want to take, right? Which specific ones should stable@ care > > about? > > Crap, sorry about that. I'd just intended to send the overview and the > four patches, which have explicit CC: stable lines in the patch > descriptions. They are: > > Subject: [PATCH 06/12] xen: add batch completion callbacks > Subject: [PATCH 07/12] xen: deal with stale cr3 values when unpinning > pagetables > Subject: [PATCH 10/12] xen: fix incorrect vcpu_register_vcpu_info > hypercall argument > Subject: [PATCH 12/12] xfs: eagerly remove vmap mappings to avoid > upsetting Xen These don't apply now due to the x86 merge. Care to backport them and send them to the [EMAIL PROTECTED] address so we can apply them properly? 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 0/5][RFC] Physical PCI slot objects
On Tue, 13 Nov 2007 16:04:00 -0700 Matthew Wilcox <[EMAIL PROTECTED]> wrote: > On Tue, Nov 13, 2007 at 02:56:05PM -0800, Greg KH wrote: > > Why not just use the code in the linux firmware kit that does this > > already today from userspace (thanks to Kristen for pointing this out to > > me on irc.)? > > So then we have something that works on ACPI-based machines. Who will > add support for all the other kinds of firmware and non-firmware based > slots? > As far as being able to retrieve the slot number (which it seemed from the HP manageablity application perspective is the goal here), that information is available from userspace as well for at least standard PCI and pcie based systems for occupied slots. For standard pci, you have to make something up anyway - for shpchp we just use an incremental number and combine it with the bus number to represent the slot. For pcie, you can get this info from the slot capabilities register. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 09:13:19PM +0100, Adrian Bunk wrote: > On Tue, Nov 13, 2007 at 07:32:19PM +, Russell King wrote: > >... > > There's another issue I want to raise concerning bugzilla. We have the > > classic case of "not enough people reading bugzilla bugs" - which is one > > of the biggest problems with bugzilla. Virtually no one in the ARM > > community looks for ARM bugs in bugzilla. > > > > Let's not forget that it would be a waste of time for people to manually > > check bugzilla for ARM bugs. There's soo few people reporting ARM bugs > > into bugzilla that a weekly manual check by every maintainer would just > > return the same old boring results for months and months at a time. > >... > > What about having all ARM bugs in Bugzilla by default assigned to > [EMAIL PROTECTED] [1] That would also work, probably much better than setting up yet another list. My experience of trying to get mbligh to do this when I stopped looking after PCMCIA stuff was *extremely* painful. Wonder if it's become any easier of late? -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
