ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc1/2.6.23-rc1-mm... - New git tree "git-dma": replaces git-md-accel (I think) ("Nelson, Shannon" <shannon.nelson@intel.com>) - New git tree git-e1000new: a new e1000 driver (Auke Kok <auke-jan.h.kok@intel.com>). Source of some controversy. Boilerplate: - See the `hot-fixes' directory for any important updates to this patchset. - To fetch an -mm tree using git, use (for example) git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git tag v2.6.16-rc2-mm1 git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1 - -mm kernel commit activity can be reviewed by subscribing to the mm-commits mailing list. echo "subscribe mm-commits" | mail majordomo@vger.kernel.org - If you hit a bug in -mm and it is not obvious which patch caused it, it is most valuable if you can perform a bisection search to identify which patch introduced the bug. Instructions for this process are at http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt But beware that this process takes some time (around ten rebuilds and reboots), so consider reporting the bug first and if we cannot immediately identify the faulty patch, then perform the bisection search. - When reporting bugs, please try to Cc: the relevant maintainer and mailing list on any email. - When reporting bugs in this kernel via email, please also rewrite the email Subject: in some manner to reflect the nature of the bug. Some developers filter by Subject: when looking for messages to read. - Occasional snapshots of the -mm lineup are uploaded to ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on the mm-commits list. Changes since 2.6.22-rc6-mm1: origin.patch git-acpi.patch git-alsa.patch git-agpgart.patch git-arm-master.patch git-audit-master.patch git-dma.patch git-drm.patch git-dvb.patch git-hwmon.patch ...
Looks like -rc1-mm2 came out while I was hunting this, haven't tried that yet) File-backed loopback seems to be broken (note that I use a LVM volume with a 'mount -o loop,encryption=aes /dev/mapper/...' every day - that *does* work). loop-use-unlocked_ioctl.patch is the offender after bisecting. I had created an ISO image with genisoimage, and to test it, I had done: mount -o loop.ro /path/to/temp.iso /mnt (Note that the image itself is good - I burned it to a CD, and then 'mount /dev/cdrom /mnt' worked just fine, so it's definitely the loopback, and on file-backed mounts...). and got treated to this wonderful oops: [ 170.420603] Unable to handle kernel NULL pointer dereference at 00000000000000b8 RIP: [ 170.420877] [<ffffffff803bf9b1>] lo_ioctl+0x21/0x94a [ 170.421243] PGD 41c5067 PUD 6111067 PMD 0 [ 170.421464] Oops: 0000 [1] PREEMPT SMP [ 170.421671] CPU 0 [ 170.421775] Modules linked in: sha256 aes video output thermal processor fan container button bay battery ac nvram pcmcia firmware_class ohci1394 yenta_socket ieee1394 rsrc_nonstatic iTCO_wdt pcmcia_core iTCO_vendor_support intel_agp rtc [ 170.422989] Pid: 1616, comm: mount Not tainted 2.6.23-rc1 #3 [ 170.423254] RIP: 0010:[<ffffffff803bf9b1>] [<ffffffff803bf9b1>] lo_ioctl+0x21/0x94a [ 170.423627] RSP: 0018:ffff8100047076d8 EFLAGS: 00010296 [ 170.423876] RAX: ffffffff80698720 RBX: 00000000fffffdfd RCX: ffffffff803bf990 [ 170.424210] RDX: ffff810004707b18 RSI: 0000000000005310 RDI: 0000000000000000 [ 170.424544] RBP: ffff8100047078d8 R08: ffff810004707b18 R09: ffff810004707968 [ 170.424878] R10: ffff810004707b18 R11: ffff810004707b18 R12: 0000000000005310 [ 170.425212] R13: ffff810004707b18 R14: ffff810004707b18 R15: 0000000000000000 [ 170.425547] FS: 00002b82792a4740(0000) GS:ffffffff806e1000(0000) knlGS:0000000000000000 [ 170.425928] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 170.426197] CR2: 00000000000000b8 CR3: 000000000610b000 CR4: 00000000000006e0 [ 170.42...
On Wed, 25 Jul 2007 04:03:04 -0700 Hi, I get an oops when trying to mount an ISO file using the loopback device. If I revert the patch 'loop-use-unlocked_ioctl.patch' the mount works. Here's the oops: [ 85.697033] Unable to handle kernel NULL pointer dereference at 0000000000000100 RIP: [ 85.702528] [<ffffffff80477885>] lo_ioctl+0x25/0xaa0 [ 85.710066] PGD 73fd067 PUD 735b067 PMD 0 [ 85.714221] Oops: 0000 [1] PREEMPT SMP [ 85.718117] CPU 1 [ 85.720159] Modules linked in: [ 85.723242] Pid: 3976, comm: mount Not tainted 2.6.23-rc1-mm1 #4 [ 85.729247] RIP: 0010:[<ffffffff80477885>] [<ffffffff80477885>] lo_ioctl+0x25/0xaa0 [ 85.737011] RSP: 0018:ffff8100076a3708 EFLAGS: 00010282 [ 85.742326] RAX: ffffffff80477860 RBX: 00000000fffffdfd RCX: 0000000000005310 [ 85.749459] RDX: ffff8100076a3b58 RSI: 0000000000005310 RDI: 0000000000000000 [ 85.756591] RBP: ffff8100076a3908 R08: ffff8100076a3b58 R09: ffff81000649da80 [ 85.763723] R10: 0000000000000000 R11: 2222222222222222 R12: 0000000000005310 [ 85.770856] R13: ffff8100076a3b58 R14: 0000000000005310 R15: 0000000000000000 [ 85.777988] FS: 00002b4fab3a0e20(0000) GS:ffff810004017180(0000) knlGS:0000000000000000 [ 85.786081] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 85.791829] CR2: 0000000000000100 CR3: 00000000073d7000 CR4: 00000000000006e0 [ 85.798970] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 85.806102] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 85.813235] Process mount (pid: 3976, threadinfo ffff8100076a2000, task ffff8100062f66d0) [ 85.821413] Stack: 0000000200000001 ffff8100062f6e90 ffff8100062f6e90 000000000013638a [ 85.829533] ffffffff80a78ef0 0000000000000000 ffff8100076a37b8 ffffffff8025c690 [ 85.837020] ffff8100062f66d0 ffff8100062f6e58 0000000200000001 0000000000000000 [ 85.844308] Call Trace: [ 85.846961] [<ffffffff8025c690>] __lock_acquire+0x3d0/0x1170 [ 85.852715] [<fffffff...
Hi, andrew, I debugged this problem. The oops is caused by NUll file pointer. I change the unlocked_ioctl to ioctl in fops. print some debug info : [ 51.018272] hidave ### cmd : get_status [ 51.018281] hidave ### cmd : 19459 inode : c2024b9c file : c2e89c00 [ 51.052419] hidave ### cmd : set_fd [ 51.052426] hidave ### cmd : 19456 inode : c2024b9c file : c2e89100 [ 51.052494] hidave ### cmd : set_status64 [ 51.052500] hidave ### cmd : 19460 inode : c2024b9c file : c2e89100 unlocked_ioctl interface only the file pointer is transfered, so NULL caused the panic. PS: I noticed the fs/block_dev.c: line 1374: res = blkdev_ioctl(bdev->bd_inode, NULL, cmd, arg); So, just changeback from unlocked_ioctl to ioctl, the lock_kernel remove is still ok. Regards dave -
On Mon, 30 Jul 2007 09:58:34 +0000
ho hum, crap. Yes, ioctl_by_bdev() doesn't have a file* and so it makes
unlocked_ioctl() rather tricky. We could cook up a `struct file' on the
stack (we do that in various places), but that sucks.
Christoph, have you any clever suggestions?
Thanks.
From: Andrew Morton <akpm@linux-foundation.org>
The last lock_kernel() has disappeared from loop.c. Switch it over to using
unlocked_ioctl.
Cc: Diego Woitasen <diego@woitasen.com.ar>
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/block/loop.c | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
diff -puN drivers/block/loop.c~loop-use-unlocked_ioctl drivers/block/loop.c
--- a/drivers/block/loop.c~loop-use-unlocked_ioctl
+++ a/drivers/block/loop.c
@@ -1124,12 +1124,14 @@ loop_get_status64(struct loop_device *lo
return err;
}
-static int lo_ioctl(struct inode * inode, struct file * file,
- unsigned int cmd, unsigned long arg)
+static long lo_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
- struct loop_device *lo = inode->i_bdev->bd_disk->private_data;
+ struct inode *inode;
+ struct loop_device *lo;
int err;
+ inode = file->f_mapping->host;
+ lo = inode->i_bdev->bd_disk->private_data;
mutex_lock(&lo->lo_ctl_mutex);
switch (cmd) {
case LOOP_SET_FD:
@@ -1304,7 +1306,7 @@ static long lo_compat_ioctl(struct file
arg = (unsigned long) compat_ptr(arg);
case LOOP_SET_FD:
case LOOP_CHANGE_FD:
- err = lo_ioctl(inode, file, cmd, arg);
+ err = lo_ioctl(file, cmd, arg);
break;
default:
err = -ENOIOCTLCMD;
@@ -1340,7 +1342,7 @@ static struct block_device_operations lo
.owner = THIS_MODULE,
.open = lo_open,
.release = lo_release,
- .ioctl = lo_ioctl,
+ .unlocked_ioctl = lo_ioctl,
#ifdef CONFIG_COMPAT
.compat_ioctl = lo_compat_ioctl,
#endif
_
-There's two ways to deal with it, one ugly and quick and one to do it right. The quick hack is to fake up a file struct similar to blkdev_get(). The proper solutions is to get rid of the file (and inode) in the blockdev ->ioctl prototype. Only thing keeping is from that is floppy.c (and some cut & paste variants for m68k) due to their awkard permission checking hacks. -
Gargh, please no. I've been thinking of how to get rid of that fake on-stack file and dentry stuff from blkdev_get() myself -- it makes pktcdvd incompatible with 4k kernel stacks ... btw any reason why we Hmm, care to explain this in more detail? Satyam -
Why pick file as param in unlocked_ioctl, why not inode, could someone explain this? THX. -
This patch contains the following cleanups that are now possible:
- remove the unused security_operations->inode_xattr_getsuffix
- remove the no longer used security_operations->unregister_security
- remove some no longer required exit code
- remove a bunch of no longer used exports
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/usb/core/usb.c | 1
fs/exec.c | 2 -
include/linux/security.h | 15 ----------
kernel/capability.c | 4 --
mm/mmap.c | 2 -
mm/nommu.c | 1
security/commoncap.c | 21 --------------
security/dummy.c | 12 --------
security/inode.c | 8 -----
security/security.c | 58 ---------------------------------------
security/selinux/hooks.c | 20 -------------
11 files changed, 1 insertion(+), 143 deletions(-)
--- linux-2.6.23-rc1-mm1/include/linux/security.h.old 2007-07-26 03:03:21.000000000 +0200
+++ linux-2.6.23-rc1-mm1/include/linux/security.h 2007-07-26 03:08:11.000000000 +0200
@@ -1136,10 +1136,6 @@ struct request_sock;
* allow module stacking.
* @name contains the name of the security module being stacked.
* @ops contains a pointer to the struct security_operations of the module to stack.
- * @unregister_security:
- * remove a stacked module.
- * @name contains the name of the security module being unstacked.
- * @ops contains a pointer to the struct security_operations of the module to unstack.
*
* @secid_to_secctx:
* Convert secid to security context.
@@ -1235,7 +1231,6 @@ struct security_operations {
int (*inode_getxattr) (struct dentry *dentry, char *name);
int (*inode_listxattr) (struct dentry *dentry);
int (*inode_removexattr) (struct dentry *dentry, char *name);
- const char *(*inode_xattr_getsuffix) (void);
int (*inode_getsecurity)(const struct inode *inode, const char *name, void *buffer, size_t size, int err);
int (*inode_setsecurity)(struct inode *inode, const char *name, const vo...Acked-by: James Morris <jmorris@namei.org> -- James Morris <jmorris@namei.org> -
sdio_dev_attrs[] can become static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
--- linux-2.6.23-rc1-mm1/drivers/mmc/core/sdio_bus.c.old 2007-07-26 16:09:20.000000000 +0200
+++ linux-2.6.23-rc1-mm1/drivers/mmc/core/sdio_bus.c 2007-07-26 16:09:30.000000000 +0200
@@ -45,7 +45,7 @@
func->class, func->vendor, func->device);
}
-struct device_attribute sdio_dev_attrs[] = {
+static struct device_attribute sdio_dev_attrs[] = {
__ATTR_RO(class),
__ATTR_RO(vendor),
__ATTR_RO(device),
-On Sun, 29 Jul 2007 16:58:09 +0200 Thanks, applied. Rgds Pierre
This patch removes two unused exports.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
kernel/pid.c | 2 --
1 file changed, 2 deletions(-)
--- linux-2.6.23-rc1-mm1/kernel/pid.c.old 2007-07-28 07:31:12.000000000 +0200
+++ linux-2.6.23-rc1-mm1/kernel/pid.c 2007-07-28 07:31:23.000000000 +0200
@@ -69,13 +69,11 @@ struct pid_namespace init_pid_ns = {
.last_pid = 0,
.child_reaper = &init_task
};
-EXPORT_SYMBOL(init_pid_ns);
int is_global_init(struct task_struct *tsk)
{
return tsk == init_pid_ns.child_reaper;
}
-EXPORT_SYMBOL(is_global_init);
/*
* Note: disable interrupts while the pidmap_lock is held as an
-scsi_host_link_pm_policy() can become static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
--- linux-2.6.23-rc1-mm1/drivers/scsi/scsi_sysfs.c.old 2007-07-26 21:31:24.000000000 +0200
+++ linux-2.6.23-rc1-mm1/drivers/scsi/scsi_sysfs.c 2007-07-26 21:31:57.000000000 +0200
@@ -200,7 +200,7 @@
{ SHOST_MEDIUM_POWER, "medium_power" },
};
-const char *scsi_host_link_pm_policy(enum scsi_host_link_pm policy)
+static const char *scsi_host_link_pm_policy(enum scsi_host_link_pm policy)
{
int i;
char *name = NULL;
-dev_attr_authorized_default can become static. Signed-off-by: Adrian Bunk <bunk@stusta.de> --- --- linux-2.6.23-rc1-mm1/drivers/usb/core/hcd.c.old 2007-07-26 21:50:30.000000000 +0200 +++ linux-2.6.23-rc1-mm1/drivers/usb/core/hcd.c 2007-07-26 21:50:45.000000000 +0200 @@ -717,9 +717,9 @@ return result; } -DEVICE_ATTR(authorized_default, 0644, - usb_host_authorized_default_show, - usb_host_authorized_default_store); +static DEVICE_ATTR(authorized_default, 0644, + usb_host_authorized_default_show, + usb_host_authorized_default_store); /* Group all the USB bus attributes */ -
Ack, patchset updated -- thanks! -
This patch fixes the following build error:
<-- snip -->
...
MODPOST 2135 modules
ERROR: "v4l2_int_device_register" [drivers/media/video/tcm825x.ko] undefined!
ERROR: "v4l2_int_device_unregister" [drivers/media/video/tcm825x.ko] undefined!
make[2]: *** [__modpost] Error 1
<-- snip -->
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
drivers/media/video/v4l2-int-device.c | 2 ++
1 file changed, 2 insertions(+)
--- linux-2.6.23-rc1-mm1/drivers/media/video/v4l2-int-device.c.old 2007-07-27 14:03:33.000000000 +0200
+++ linux-2.6.23-rc1-mm1/drivers/media/video/v4l2-int-device.c 2007-07-27 14:04:03.000000000 +0200
@@ -101,6 +101,7 @@
return 0;
}
+EXPORT_SYMBOL_GPL(v4l2_int_device_register);
void v4l2_int_device_unregister(struct v4l2_int_device *d)
{
@@ -114,6 +115,7 @@
}
mutex_unlock(&mutex);
}
+EXPORT_SYMBOL_GPL(v4l2_int_device_unregister);
/* Adapted from search_extable in extable.c. */
static v4l2_int_ioctl_func *find_ioctl(struct v4l2_int_slave *slave, int cmd,
-This patch makes two needlessly global variables static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
--- linux-2.6.23-rc1-mm1/kernel/printk.c.old 2007-07-26 22:40:09.000000000 +0200
+++ linux-2.6.23-rc1-mm1/kernel/printk.c 2007-07-26 22:40:50.000000000 +0200
@@ -166,8 +166,8 @@
#ifdef CONFIG_BOOT_PRINTK_DELAY
-unsigned int boot_delay; /* msecs delay after each printk during bootup */
-unsigned long long printk_delay_msec; /* per msec, based on boot_delay */
+static unsigned int boot_delay; /* msecs delay after each printk during bootup */
+static unsigned long long printk_delay_msec; /* per msec, based on boot_delay */
static int __init boot_delay_setup(char *str)
{
---- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -
This patch makes the needlessly global struct info static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
--- linux-2.6.23-rc1-mm1/drivers/mtd/onenand/onenand_sim.c.old 2007-07-26 16:11:57.000000000 +0200
+++ linux-2.6.23-rc1-mm1/drivers/mtd/onenand/onenand_sim.c 2007-07-26 16:12:19.000000000 +0200
@@ -78,7 +78,7 @@
struct onenand_flash flash;
};
-struct onenand_info *info;
+static struct onenand_info *info;
#define DPRINTK(format, args...) \
do { \
-This patch makes some needlessly global code static. Signed-off-by: Adrian Bunk <bunk@stusta.de> --- fs/ecryptfs/crypto.c | 15 +++++------ fs/ecryptfs/ecryptfs_kernel.h | 10 ------- fs/ecryptfs/keystore.c | 43 +++++++++++++++++----------------- 3 files changed, 29 insertions(+), 39 deletions(-) --- linux-2.6.23-rc1-mm1/fs/ecryptfs/ecryptfs_kernel.h.old 2007-07-26 13:50:59.000000000 +0200 +++ linux-2.6.23-rc1-mm1/fs/ecryptfs/ecryptfs_kernel.h 2007-07-26 14:09:15.000000000 +0200 @@ -156,7 +156,6 @@ } token; } __attribute__ ((packed)); -int ecryptfs_get_auth_tok_sig(char **sig, struct ecryptfs_auth_tok *auth_tok); void ecryptfs_dump_auth_tok(struct ecryptfs_auth_tok *auth_tok); extern void ecryptfs_to_hex(char *dst, char *src, size_t src_size); extern void ecryptfs_from_hex(char *dst, char *src, int dst_size); @@ -290,9 +289,6 @@ unsigned char cipher_name[ECRYPTFS_MAX_CIPHER_NAME_SIZE + 1]; }; -extern struct list_head key_tfm_list; -extern struct mutex key_tfm_list_mutex; - /** * This struct is to enable a mount-wide passphrase/salt combo. This * is more or less a stopgap to provide similar functionality to other @@ -520,9 +516,6 @@ void ecryptfs_destruct_mount_crypt_stat( struct ecryptfs_mount_crypt_stat *mount_crypt_stat); int ecryptfs_init_crypt_ctx(struct ecryptfs_crypt_stat *crypt_stat); -int ecryptfs_crypto_api_algify_cipher_name(char **algified_name, - char *cipher_name, - char *chaining_modifier); #define ECRYPTFS_LOWER_I_MUTEX_NOT_HELD 0 #define ECRYPTFS_LOWER_I_MUTEX_HELD 1 int ecryptfs_write_inode_size_to_metadata(struct file *lower_file, @@ -563,13 +556,10 @@ struct ecryptfs_crypt_stat *crypt_stat, struct dentry *ecryptfs_dentry, size_t *len, size_t max); -int process_request_key_err(long err_code); int ecryptfs_parse_packet_set(struct ecryptfs_crypt_stat *crypt_stat, unsigned char *src, struct dentry *ecryptfs_dentry); int ecryptfs_truncate(...
hugetlbfs_read() can become static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
--- linux-2.6.23-rc1-mm1/fs/hugetlbfs/inode.c.old 2007-07-26 13:28:52.000000000 +0200
+++ linux-2.6.23-rc1-mm1/fs/hugetlbfs/inode.c 2007-07-26 13:29:30.000000000 +0200
@@ -217,8 +217,8 @@
* data. Its *very* similar to do_generic_mapping_read(), we can't use that
* since it has PAGE_CACHE_SIZE assumptions.
*/
-ssize_t
-hugetlbfs_read(struct file *filp, char __user *buf, size_t len, loff_t *ppos)
+static ssize_t hugetlbfs_read(struct file *filp, char __user *buf,
+ size_t len, loff_t *ppos)
{
struct address_space *mapping = filp->f_mapping;
struct inode *inode = mapping->host;
-Hi Jeff,
I noticed this warnings when CONFIG_PM=n
...
drivers/ata/libata-core.c:5993: warning: 'ata_host_disable_link_pm' defined but not used
drivers/ata/libata-core.c:6004: warning: 'ata_host_enable_link_pm' defined but not used
...
Signed-off-by: Gabriel Craciunescu <nix.or.die@googlemail.com>
---
--- linux-2.6.23-rc1/drivers/ata/libata-core.c.orig 2007-07-28 21:17:31.000000000 +0200
+++ linux-2.6.23-rc1/drivers/ata/libata-core.c 2007-07-28 21:17:48.000000000 +0200
@@ -5989,6 +5989,7 @@ int ata_flush_cache(struct ata_device *d
return 0;
}
+#ifdef CONFIG_PM
static void ata_host_disable_link_pm(struct ata_host *host)
{
int i;
@@ -6011,7 +6012,7 @@ static void ata_host_enable_link_pm(stru
}
}
-#ifdef CONFIG_PM
+
static int ata_host_request_pm(struct ata_host *host, pm_message_t mesg,
unsigned int action, unsigned int ehi_flags,
int wait)
-Hi, next randconfig error ( http://194.231.229.228/MM/randconfig-auto-87.mm_sparse.error ) ... mm/sparse.c: In function 'sparse_init': mm/sparse.c:482: error: implicit declaration of function 'sparse_early_usemap_alloc' mm/sparse.c:482: warning: assignment makes pointer from integer without a cast make[1]: *** [mm/sparse.o] Error 1 make: *** [mm] Error 2 make: *** Waiting for unfinished jobs.... ... guessing while this patch , but I am not really sure : fix-corruption-of-memmap-on-ia64-sparsemem-when-mem_section-is-not-a-power-of-2.patch Regards, Gabriel C -
That seems to have been fixed by one of the post-2.6.23-rc1-mm1 patches I merged, thanks. -
I believe that this was fixed by a patch from Mel Gorman which I believe merged into -mm as: fix-corruption-of-memmap-on-ia64-sparsemem-when-mem_section-is-not-a-power-of-2-fix.patch -apw -
... sound/pci/ac97/ac97_patch.h:86: warning: 'snd_ac97_restore_status' declared 'static' but never defined sound/pci/ac97/ac97_patch.h:87: warning: 'snd_ac97_restore_iec958' declared 'static' but never defined ... Got that with a randconfig ( http://194.231.229.228/MM/randconfig-auto-86.ioat ) Regards, Gabriel C -
Hi, I got this error with a randconfig ( http://194.231.229.228/MM/randconfig-auto-86.ioat ) ... LD .tmp_vmlinux1 drivers/built-in.o: In function `ioat_shutdown_functionality': ioat.c:(.text+0x21ed32): undefined reference to `unregister_dca_provider' ioat.c:(.text+0x21ed3a): undefined reference to `free_dca_provider' drivers/built-in.o: In function `ioat_dca_init': (.text+0x2201f3): undefined reference to `alloc_dca_provider' drivers/built-in.o: In function `ioat_dca_init': (.text+0x22022e): undefined reference to `register_dca_provider' drivers/built-in.o: In function `ioat_dca_init': (.text+0x22023b): undefined reference to `free_dca_provider' make: *** [.tmp_vmlinux1] Error 1 ... Regards, Gabriel C -
Hi, I got this compile error with a randconfig ( http://194.231.229.228/MM/randconfig-auto-82.broken.netpoll.c ). ... net/core/netpoll.c: In function 'netpoll_poll': net/core/netpoll.c:155: error: 'struct net_device' has no member named 'poll_controller' net/core/netpoll.c:159: error: 'struct net_device' has no member named 'poll_controller' net/core/netpoll.c: In function 'netpoll_setup': net/core/netpoll.c:670: error: 'struct net_device' has no member named 'poll_controller' make[2]: *** [net/core/netpoll.o] Error 1 make[1]: *** [net/core] Error 2 make: *** [net] Error 2 make: *** Waiting for unfinished jobs.... ... I think is because KGDBOE selects just NETPOLL. Regards, Gabriel -
Looks like it. Select went and selected NETPOLL and NETPOLL_TRAP but things like CONFIG_NETDEVICES and CONFIG_NET_POLL_CONTROLLER remain unset. `select' remains evil. Something like this.. --- a/lib/Kconfig.kgdb~kgdb-kconfig-fix +++ a/lib/Kconfig.kgdb @@ -175,8 +175,7 @@ endchoice config KGDBOE tristate "KGDB: On ethernet" if !KGDBOE_NOMODULE depends on m && KGDB - select NETPOLL - select NETPOLL_TRAP + depends on NETPOLL_TRAP && NET_POLL_CONTROLLER help Uses the NETPOLL API to communicate with the host GDB via UDP. In order for this to work, the ethernet interface specified must _ -
That doesn't fix it. With that patch an 'make oldconfig' all NETPOLL stuff gone and we end up with :
...
drivers/built-in.o: In function `option_setup':
/work/crazy/linux-git/MM/linux-2.6.23-rc1/drivers/net/kgdboe.c:160: undefined reference to `netpoll_parse_options'
drivers/built-in.o: In function `configure_kgdboe':
/work/crazy/linux-git/MM/linux-2.6.23-rc1/drivers/net/kgdboe.c:183: undefined reference to `netpoll_setup'
/work/crazy/linux-git/MM/linux-2.6.23-rc1/drivers/net/kgdboe.c:189: undefined reference to `netpoll_cleanup'
drivers/built-in.o: In function `eth_post_exception_handler':
/work/crazy/linux-git/MM/linux-2.6.23-rc1/drivers/net/kgdboe.c:119: undefined reference to `netpoll_set_trap'
drivers/built-in.o: In function `eth_pre_exception_handler':
/work/crazy/linux-git/MM/linux-2.6.23-rc1/drivers/net/kgdboe.c:111: undefined reference to `netpoll_set_trap'
drivers/built-in.o: In function `eth_flush_buf':
/work/crazy/linux-git/MM/linux-2.6.23-rc1/drivers/net/kgdboe.c:138: undefined reference to `netpoll_send_udp'
drivers/built-in.o: In function `eth_get_char':
/work/crazy/linux-git/MM/linux-2.6.23-rc1/drivers/net/kgdboe.c:127: undefined reference to `netpoll_poll'
drivers/built-in.o: In function `cleanup_kgdboe':
/work/crazy/linux-git/MM/linux-2.6.23-rc1/drivers/net/kgdboe.c:217: undefined reference to `netpoll_cleanup'
make: *** [.tmp_vmlinux1] Error 1
...
If I get that right select is needed here because all NETPOLL{_*} depends on if NETDEVICES && if NET_ETHERNET.
Also doing
...
select NETPOLL_TRAP
select NETPOLL
select NET_POLL_CONTROLLER
...
makes the driver happy and everything compiles fine.
I think there may be a logical issue ( again if I got it right ).
We need some ethernet card to work with kgdboe right ? but we don't have any if !NETDEVICES && !NET_ETHERNET.
So maybe some ' depends on ... && NETDEVICES!=n && NET_ETHERNET!=n ' is needed too ?
( really sory if I said something stupid these Kconfig...IMHO, the only logical issue here is netpoll.c mustn't use CONFIG_NET_POLL_CONTROLLER code without #ifdef if it doesn't add this dependency itself. Cheers, Jarek P. -
Well it does if NETDEVICES && if NET_ETHERNET which booth are N when !NETDEVICES is why KGDBOE uses select and not depends on. Now KGDBOE just selects NETPOLL and NETPOLL_TRAP. Gabriel -
Why kgdboe should care what netpoll needs? So, I hope, you are adding this select under config NETPOLL. On the other hand, if NETPOLL should depend on NET_POLL_CONTROLLER there is probably no reason to have them both. The "does it work" question isn't logical issue, so it's irrelevant here... Jarek P. -
does not work.
...
menuconfig FOO
bool "FOO"
depends on BAR
default y
-- help --
something
if FOO
config BAZ
depends on WHATEVR && !NOT_THIS
menuconfig SOMETHING_ELSE
....
if SOMETHING_ELSE
config BLUBB
depends on PCI && WHATNOT
endif # SOMETHING_ELSE
config NETPOLL
def_bool NETCONSOLE
config NETPOLL_TRAP
bool "Netpoll traffic trapping"
default n
depends on NETPOLL
config NET_POLL_CONTROLLER
def_bool NETPOLL
endif # FOO
NET_POLL_CONTROLLER has def_bool NETPOLL if NETDEVICES .
Gabriel
-So, according to this netpoll could presume NETDEVICES and
NET_POLL_CONTROLLER are always on.
But, as you've found, it's possible to select NETPOLL and !NETDEVICES,
so this comment is at least not precise.
On the other side something like this:
...
endif # NETDEVICES
config NETPOLL
depends on NETDEVICES
def_bool NETCONSOLE
config NETPOLL_TRAP
bool "Netpoll traffic trapping"
default n
depends on NETPOLL
config NET_POLL_CONTROLLER
def_bool NETPOLL
depends on NETPOLL
seems to select NET_POLL_CONTROLLER after selecting NETPOLL, but
OK, I wasn't right here: there is no visible reason for both in the
kernel code, but I can imagine there could be some external users of
This was kind of joking, but since some people prefer things to work,
and it's hard to do this right (logical) way, some strange (unlogical)
measures have to be done like repeating dependencies here.
Regards,
Jarek P.
-I don't know of any. As far as I can tell at this point, NET_POLL_CONTROLLER == NETPOLL. -- Mathematics is the supreme nostalgia of our time. -
select is evil.... select will by brute force set a symbol equal to 'y' without visiting the dependencies. So abusing select you are able to select a symbol FOO even if FOO depends on BAR that is not set. In general use select only for non-visible symbols (no promts anywhere) and for symbols with no dependencies. That will limit the suefullness but on the other hand avoid the illegal configurations all over. kconfig should one day warn about such things but I have not fel inclined to dive into the matters hoping that Roman does one day. Sam -
Hi, If there are no other plans of kconfig docs update I think this message of yours should be useful enough. I made minimal fixes, so if they are wrong or you prefer it otherwise, I'm OK with any change to this proposal, including replacement with something else. Thanks & regards, Jarek P. On Thu, Aug 02, 2007 at 11:36:59AM +0200, Sam Ravnborg wrote: -----------> Subject: docs: a warning note about select in kconfig-language.txt A warning note of Sam Ravnborg about kconfig's select evilness, dependencies and the future (slightly corrected). Signed-off-by: Jarek Poplawski <jarkao2@o2.pl> Cc: Sam Ravnborg <sam@ravnborg.org> --- diff -Nu9r 2.6.23-rc1-/Documentation/kbuild/kconfig-language.txt 2.6.23-rc1/Documentation/kbuild/kconfig-language.txt --- 2.6.23-rc1-/Documentation/kbuild/kconfig-language.txt 2007-07-09 01:32:17.000000000 +0200 +++ 2.6.23-rc1/Documentation/kbuild/kconfig-language.txt 2007-08-06 12:50:34.000000000 +0200 @@ -92,18 +92,27 @@ - reverse dependencies: "select" <symbol> ["if" <expr>] While normal dependencies reduce the upper limit of a symbol (see below), reverse dependencies can be used to force a lower limit of another symbol. The value of the current menu symbol is used as the minimal value <symbol> can be set to. If <symbol> is selected multiple times, the limit is set to the largest selection. Reverse dependencies can only be used with boolean or tristate symbols. + Note: + select is evil.... select will by brute force set a symbol + equal to 'y' without visiting the dependencies. So abusing + select you are able to select a symbol FOO even if FOO depends + on BAR that is not set. In general use select only for + non-visible symbols (no promts anywhere) and for symbols with + no dependencies. That will limit the usefulness but on the + other hand avoid the illegal configurations all over. kconfig + should one day warn about such things. - numerical ranges: "range" ...
Hi, I just noticed this thread, but I wonder what the fuss is all about :-) Kconfig dependencies are easy, really -- any code that pulls in code from elsewhere, must explicitly "depends on" it. It is possible to use "select" as well, but could lead to breakages as discussed to death on at least 64592 other threads on LKML already and hence should only be used for library-like code that does not The problem with using "depends on" is that your config symbol becomes invisible unless the dependency has already been selected. So, there's a workaround: make the ultimate config symbol itself depend upon the grand-dependency (excuse the nomenclature) and just "select" the immediate-parent-dependency, i.e. the following: CONFIG_BAZ ... CONFIG BAR depends on BAZ CONFIG_FOO depends on BAZ select BAR is perfectly legal, and doesn't cause any build problems. Perhaps such a Yup, I've wanted to do this myself, in fact I wanted to implement an idea I had in mind ( http://lkml.org/lkml/2007/5/16/257 ) but for some reason I tend to stay away from stuff in scripts/ :-) Satyam -
So, it seems at least one time not enough (or maybe it would be better How often "common" developer has to make such decisions in Kconfig? Probably no more than once per year. So, it's fair to blame anybody for not reading lkml to find if there are some bugs or recommendations before using apparently simple tool? I think there is usually some README for such things (maybe in Documentation/)? Thanks, Jarek P. PS: if it's so easy and it's enough to read only 64592 lkml messages, I wonder why Andrew, who knows all lkml, and reads more messages per hour, cared to remember mainly one short conclusion... -
Whoops, I only said that in humour, probably should've snuck in a smiley or two. Definitely not blaming anybody. Apologies to anyone who felt offended, sorry, nothing such was intended, I assure. Satyam -
On Thu, Aug 02, 2007 at 05:26:12PM +0530, Satyam Sharma wrote: I see you probably didn't notice my smileys too. I need them so often that I've to abbreviate them with something like this: ",.?!" But, I'm also sorry if you felt confused I felt offended etc... Jarek P. -
[ Read through the thread, looked at Kconfig files, Gargh, what we're seeing here is a whole bunch of bugs, I think. First I thought this must be one of those randconfig-producing-wrong-configs issues, but surprisingly, running "make oldconfig" on this .config on a fresh 2.6.23-rc1-mm1 tree didn't change anything in the .config. Kconfig bug #1: =============== Which means, although: ***** menuconfig BAZ if BAZ config BAR endif ***** is widely believed (by most folks, I've heard this on several threads, and as written in the comment in drivers/net/Kconfig) to be equivalent to: ***** menuconfig BAZ if BAZ endif config BAR depends on BAZ ***** this is *not* enforced by "make oldconfig"! And hence, the NETPOLL && !NETDEVICES situation we're seeing here. [ We could also categorize this as a bug in Kconfig's "if", fwiw. ] Kconfig bug #2: =============== config FOO def_bool BAR is supposed to ensure that FOO == BAR (as Matt mentioned earlier). However, even this is *not* enforced by "make oldconfig". And hence, the NETPOLL && !NET_POLL_CONTROLLER situation we're seeing here. In fact, I believe it's possible to even pass a NETCONSOLE but !NETPOLL kind of .config through "make oldconfig" but it still won't catch it, and build breakages *will* occur. [ We could also categorize this as a bug in Kconfig's "def_bool", fwiw. ] Possibly, we could also decide to just blame "randconfig" for the whole issue, and forget about these, because I think it's highly unlikely (though not impossible) for people with "real" .configs to hit the problems we saw above. KGDBOE bug #1: ============== config KGDBOE in lib/Kconfig.kgdb must also "depend on" NETDEVICES, and select NET_POLL_CONTROLLER also. KGDBOE bug #2: ============== config KGDBOE_NOMODULE is a sad, sad option, and must be killed. The "if !KGDBOE_NOMODULE" in KGDBOE must be removed, and it must lose its dependency on "m". Satyam -
Looks right, but after reading Andrew's opinion about select I'd be Is there a new one or do you suggest possibility of abusing the authority of the netpoll's author with such trifles...?! BTW, I can't find any official meaning of def_bool, but it's name suggests only default value, so logically it should be not enough to assure NET_POLL_CONTROLLER=y, and netpoll should use "depends", "require" or "select" (IMHO more readable too), but on the other There are some notions about "other diagnostic tools" in some net drivers, eg. 3c509.c, so there would be a little bit of work if, after changing this, they really exist (and even if not - maybe it's reasonable to save such possibility for the future?). Best regards, Jarek P. -
I'm just subtly suggesting that if you're going to have a discussion I created it for netpoll, only netpoll clients have ever cared. -- Mathematics is the supreme nostalgia of our time. -
Thanks! I'm very honored. I've suspected there is some subtlety, but wasn't sure of possible new patches to MAINTAINERS, so tried to be So, probably you're the best person to change this! Alas, it seems, for some time any changes to netpoll could have a cold reception here (pity for Ingo's laptop...). Regards, Jarek P. -
kgdboe is completely useless without a network card that has a polling driver. It seems to me that the simple and easy fix is to set it to depend on NETDEVICES but allow it to use select on NETPOLL. Would that seem reasonable? Jason. -
On Tue, Jul 31, 2007 at 06:44:52AM -0500, Jason Wessel wrote: Maybe I miss your point but polling drivers don't need NETPOLL to work (unless you need netconsole). But I don't know if there is any easy method to check such driver's dependency with select. Jarek P. -
Hi, This patch removes one of the two linux/console.h included in arch/xtensa/platform-iss/console.c Signed-off-by: Frederik Deweerdt <frederik.deweerdt@gmail.com> diff --git a/arch/xtensa/platform-iss/console.c b/arch/xtensa/platform-iss/console.c index 2f4f20f..854677d 100644 --- a/arch/xtensa/platform-iss/console.c +++ b/arch/xtensa/platform-iss/console.c @@ -20,7 +20,6 @@ #include <linux/param.h> #include <linux/serial.h> #include <linux/serialP.h> -#include <linux/console.h> #include <asm/uaccess.h> #include <asm/irq.h> -
Fix sparsemem_vmemmap init. sorry if known bug.
This patch fixes page table handling in sparsemem_vmammap.
Without this, part of vmem_map is not mapped because each section's start addr of
mem_map is not aligned to PGD/PMD/PUD.
(In ia64, secion's mem_map size is 3670016bytes. )
for example,
addr pmd_addr_end(addr_end) addr + PMD_SIZE
|XXXXXXXXXX|??????????????????????????????|XXXXXXXXXXXXXXXXXX
X ... initialized vmem_map
? ... not intialized
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
---
mm/sparse.c | 24 +++++++++++++-----------
1 file changed, 13 insertions(+), 11 deletions(-)
Index: devel-2.6.23-rc1-mm1/mm/sparse.c
===================================================================
--- devel-2.6.23-rc1-mm1.orig/mm/sparse.c
+++ devel-2.6.23-rc1-mm1/mm/sparse.c
@@ -320,7 +320,7 @@ static int __meminit vmemmap_populate_pt
{
pte_t *pte;
- for (pte = pte_offset_map(pmd, addr); addr < end;
+ for (pte = pte_offset_kernel(pmd, addr); addr < end;
pte++, addr += PAGE_SIZE)
if (pte_none(*pte)) {
pte_t entry;
@@ -345,9 +345,10 @@ int __meminit vmemmap_populate_pmd(pud_t
{
pmd_t *pmd;
int error = 0;
+ unsigned long next;
for (pmd = pmd_offset(pud, addr); addr < end && !error;
- pmd++, addr += PMD_SIZE) {
+ pmd++, addr = next) {
if (pmd_none(*pmd)) {
void *p = vmemmap_alloc_block(PAGE_SIZE, node);
if (!p)
@@ -357,9 +358,8 @@ int __meminit vmemmap_populate_pmd(pud_t
} else
vmemmap_verify((pte_t *)pmd, node,
pmd_addr_end(addr, end), end);
-
- error = vmemmap_populate_pte(pmd, addr,
- pmd_addr_end(addr, end), node);
+ next = pmd_addr_end(addr, end);
+ error = vmemmap_populate_pte(pmd, addr, next, node);
}
return error;
}
@@ -370,9 +370,10 @@ static int __meminit vmemmap_populate_pu
{
pud_t *pud;
int error = 0;
+ unsigned long next;
for (pud = pud_offset(pgd, addr); addr < end && !error;
- ...I think the code change below is safe enough. I have not found it easy to understand your description above but I think that you are saying that if the section we are initialising is bigger than a PMD size, but falls offset from the PMD start we will initialise the end of the first PMD and the end of the second PMD and so on. The "start" of the second PMD is missed. Ahh yes, that I think is what your diagram shows. Yes this is pretty clearly wrong for any sort of offset initialisation, and would be worse lower down in the hierachy. This seems like a clean way to fix the bug. Thanks for finding this. -apw -
Andrew, I'll fold this one into a new version when I get through the other feedback, but could you pull this into -mm on top for now as its a boot issue. -apw -
Booting SPARSEMEM on NUMA systems trips a BUG in page_alloc.c:
Initializing HighMem for node 0 (00038000:00100000)
Initializing HighMem for node 1 (00100000:001ffe00)
------------[ cut here ]------------
kernel BUG at /home/apw/git/linux-2.6/mm/page_alloc.c:456!
[...]
This occurs because the section to node id mapping is not being
setup correctly during init under SPARSEMEM_STATIC, leading to an
attempt to free pages from all nodes into the zones on node 0.
When the zone_table[] was removed in the following commit, a new
section to node mapping table was introduced:
commit 89689ae7f95995723fbcd5c116c47933a3bb8b13
[PATCH] Get rid of zone_table[]
That conversion inadvertantly only initialised the node mapping in
SPARSEMEM_EXTREME. Ensure we initialise the node mapping in
SPARSEMEM_STATIC.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
diff --git a/mm/sparse.c b/mm/sparse.c
index 0320f86..5bfd9a7 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -43,6 +43,15 @@ int page_to_nid(struct page *page)
return section_to_node_table[page_to_section(page)];
}
EXPORT_SYMBOL(page_to_nid);
+
+void set_section_nid(unsigned long section_nr, int nid)
+{
+ section_to_node_table[section_nr] = nid;
+}
+#else /* !NODE_NOT_IN_PAGE_FLAGS */
+void set_section_nid(unsigned long section_nr, int nid)
+{
+}
#endif
#ifdef CONFIG_SPARSEMEM_EXTREME
@@ -70,10 +79,6 @@ static int __meminit sparse_index_init(unsigned long section_nr, int nid)
struct mem_section *section;
int ret = 0;
-#ifdef NODE_NOT_IN_PAGE_FLAGS
- section_to_node_table[section_nr] = nid;
-#endif
-
if (mem_section[root])
return -EEXIST;
@@ -150,6 +155,7 @@ void __init memory_present(int nid, unsigned long start, unsigned long end)
struct mem_section *ms;
sparse_index_init(section, nid);
+ set_section_nid(section, nid);
ms = __nr_to_section(section);
if (!ms->section_mem_map)
-This results in an ARM-only driver in an X86-only menu... What about the patch below instead that also improves a few other things? <-- snip --> This patch contains the following changes to the DMA engine menus: - switch to menuconfig - INTEL_IOATDMA must depend on X86 - INTEL_IOATDMA must select DCA - device drivers shouldn't "default m" - DCA shouldn't be a user visible option - make it clear in the INTEL_IOATDMA help text that this driver is for rare hardware the user most likely doesn't has - let DMA_ENGINE be select'ed by the DMA devices, making it less likely for a user to accidentally enable NET_DMA Signed-off-by: Adrian Bunk <bunk@stusta.de> --- drivers/dca/Kconfig | 7 +---- drivers/dma/Kconfig | 59 +++++++++++++++++++++++++------------------- 2 files changed, 36 insertions(+), 30 deletions(-) --- linux-2.6.23-rc1-mm1/drivers/dma/Kconfig.old 2007-07-26 06:45:46.000000000 +0200 +++ linux-2.6.23-rc1-mm1/drivers/dma/Kconfig 2007-07-26 07:08:46.000000000 +0200 @@ -2,42 +2,51 @@ # DMA engine configuration # -menu "DMA Engine support" - depends on HAS_DMA +menuconfig DMADEVICES + bool "DMA Engine support" + depends on (PCI && X86) || ARCH_IOP32X || ARCH_IOP33X || ARCH_IOP13XX + help + Intel(R) DMA engines + +if DMADEVICES + +comment "DMA Devices" + +config INTEL_IOATDMA + tristate "Intel I/OAT DMA support" + depends on PCI && X86 + select DMA_ENGINE + select DCA + help + Enable support for the Intel(R) I/OAT DMA engine present + in recent Intel Xeon CPUs. + + Say yes if you have such a CPU. + + If unsure, say N. + +config INTEL_IOP_ADMA + tristate "Intel IOP ADMA support" + depends on ARCH_IOP32X || ARCH_IOP33X || ARCH_IOP13XX + select ASYNC_CORE + select DMA_ENGINE + help + Enable support for the Intel(R) IOP Series RAID engines. config DMA_ENGINE - bool "Support for DMA engines" - ---help--- - DMA engines offload bulk memory operations from the CPU to dedicated ...
Thanks, Adrian. With a couple minor notes changes, I'm using this patch. What's nice is this also takes care of the DCA configuration issue as well such that I don't need to add #ifdef's to the code. Doing this changes an argument I gave to Satyam, but the effect is small enough that it shouldn't matter. Once I get my git tree cleaned up again (I'll learn this part yet...) I'll have it out, probably tomorrow. sln ====================================================================== Mr. Shannon Nelson LAN Access Division, Intel Corp. Shannon.Nelson@intel.com I don't speak for Intel (503) 712-7659 Parents can't afford to be squeamish. -
Perhaps we should go ahead and define ARCH_HAS_DMA_OFFLOAD and have DMADEVICES depend on that option. A ppc32 driver is in the works: It is actually in recent chipsets, not the CPU, but yes the user should have more help making this decision. Regards, Dan (for Shannon while he is on vacation) -
That would be overkill - what my patch does here is just a minor
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-It built and booted on the first try for my Dell Latitude D820 laptop, Core2 T7200 x86_64 kernel. Now at about 5 hours of uptime. I guess I got lucky and my stock .config doesn't trip over any of the issues others are hitting. I did hit *one* problem: Under 2.6.22-rc6-mm1, 'modprobe tpm_tis' did this: [ 10.028000] tpm_tis 00:0f: 1.2 TPM (device-id 0x1001, rev-id 2) [ 10.088000] tpm_tis 00:0f: Unable to request irq: 8 for probe and the modprobe returned immediately. Under 23-rc1-mm1, the modprobe takes a *long* time: [ 23.787331] tpm_tis 00:0f: 1.2 TPM (device-id 0x1001, rev-id 2) [ 23.787353] tpm0 (IRQ 3) handled a spurious interrupt [ 143.803891] tpm_tis 00:0f: tpm_transmit: tpm_send: error -62 [ 143.803920] tpm0 (IRQ 3) handled a spurious interrupt [ 263.736163] tpm_tis 00:0f: tpm_transmit: tpm_send: error -62 [ 383.668381] tpm_tis 00:0f: tpm_transmit: tpm_send: error -62 [ 385.667261] tpm_tis 00:0f: tpm_transmit: tpm_send: error -62 then it finally returns. I snuck in a few 'echo t > /proc/sysrq_trigger', and it's always waiting here: [ 193.154317] modprobe S 0000001eeae8252d 5488 1446 1 [ 193.154321] ffff8100043d7a98 0000000000000082 0000000000000000 ffffffff80795480 [ 193.154325] ffff8100043d7a48 ffff810003538000 ffffffff806813e0 ffff810003538290 [ 193.154329] 0000000004173800 0000000000000202 00000000000000ff ffffffff8023ba74 [ 193.154332] Call Trace: [ 193.154336] [<ffffffff8023ba74>] __mod_timer+0xc4/0xd6 [ 193.154340] [<ffffffff805273cc>] schedule_timeout+0x8d/0xb4 [ 193.154344] [<ffffffff8023b7be>] process_timeout+0x0/0xb [ 193.154347] [<ffffffff805273c7>] schedule_timeout+0x88/0xb4 [ 193.154353] [<ffffffff880b328a>] :tpm_tis:wait_for_stat+0xb0/0x11a [ 193.154356] [<ffffffff802460ef>] autoremove_wake_function+0x0/0x38 [ 193.154360] [<ffffffff880b31b0>] :tpm_tis:get_burstcount+0x63/0x8d [ 193.154365] [<ffffffff880b367e>] :tpm_tis:tpm_tis_send+0x191/0x1d3 [ 1...
I can't imagine what we did to break tpm_tis, sorry. Nothing has changed
in there for ages.
Perhaps something broke at the bus level. It would be useful to add
--- a/drivers/char/tpm/tpm_tis.c~a
+++ a/drivers/char/tpm/tpm_tis.c
@@ -595,9 +595,11 @@ static int __devinit tpm_tis_pnp_init(st
const struct pnp_device_id *pnp_id)
{
resource_size_t start, len;
+
start = pnp_mem_start(pnp_dev, 0);
len = pnp_mem_len(pnp_dev, 0);
-
+ printk("%s: start=%llu, len=%llu\n",
+ (unsigned long long)start, (unsigned long long)end);
return tpm_tis_init(&pnp_dev->dev, start, len);
}
_
to both a good and a bad kernel, see what it says.
-This is a multipart MIME message.
--==_Exmh_1185507681_33070
Content-Type: text/plain; charset=us-ascii
OK, so I made a more intrusive printk-all-over patch to track what it was
doing, and got several tests in under 2.6.22-rc6-mm1 and 2.6.23-rc1-mm1.
I've attached:
debug.22-rc6-mm1 - things apparently working under the previous kernel.
debug.rc1-a - this one complained but didn't time out for long times. I've
only seen 23-rc1-mm1 *not* take timeouts this one time. Oddness.
debug.rc1-b - this one complained, and took 2 120-second waits
debug.patch - the printf's I added, for those who want to follow along..
Apparently, things go pe