login
Search
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc1/2.6.23-rc1-mm1/ - 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 ...
Both e1000 drivers compiled into the kernel resulted in the following compile error: <-- snip --> ... LD drivers/net/built-in.o drivers/net/e1000/built-in.o: In function `e1000_read_mac_addr': (.text+0xb9f2): multiple definition of `e1000_read_mac_addr' drivers/net/e1000new/built-in.o:(.text+0x821a): first defined here drivers/net/e1000/built-in.o: In function `e1000_phy_setup_autoneg': (.text+0x8799): multiple definition of `e1000_phy_setup_autoneg' drivers/net/e1000new/built-in.o:(.text+0xa9bd): first defined here ... make[3]: *** [drivers/net/built-in.o] Error 1 <-- snip --> Signed-off-by: Adrian Bunk <bunk@stusta.de> --- BTW: Unless I'm misunderstanding anything, the new driver should support a superset of what the old driver supported. Therefore, it would be good if the final merge into Linus' tree will do an rm -r drivers/net/e1000 mv drivers/net/e1000new drivers/net/e1000 --- linux-2.6.23-rc1-mm1/drivers/net/Kconfig.old 2007-07-25 15:06:13.000000000 +0200 +++ linux-2.6.23-rc1-mm1/drivers/net/Kconfig 2007-07-25 15:09:59.000000000 +0200 @@ -2036,7 +2036,7 @@ config E1000 tristate "Intel(R) PRO/1000 Gigabit Ethernet support" - depends on PCI + depends on PCI && E1000NEW=n ---help--- This driver supports Intel(R) PRO/1000 gigabit ethernet family of adapters. For more information on how to identify your adapter, go -
Based on the most recent discussion, e1000new (or whatever it will be called) should support only the newer PCI-Express chips, while e1000 will retain support for the older chips. Over the long term this will allow e1000new to grow without affecting support for the older, stable chips. So, e1000 is not going away. Jeff -
I found the discussion, and Christoph's e1000e sounds like the best name
("new" doesn't say whether it's a new driver for old hardware or a
No problem for me, but this obviously implies that global code in the
new driver has to be renamed.
And please ensure that they will always support distinct PCI IDs, or
there will be the following common pattern if both drivers support
a card:
- user tries driver A
- driver A doesn't work (although it should have worked)
- user tries driver B
- driver B works
- a later kernel removes support for this card from driver B
- user tries driver A
- driver A still doesn't work
- user writes bug report
Users should report bugs early instead of bouncing between different
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
-
Yeah, I think "e1000new" is a lame name. IIRC I think Auke said there is some minor PCI ID overlap that must be addressed in the transition. Disappointing and it raises transition issues, but that's the way the split falls out naturally AFAICS. Jeff -
yes, these are some of the kinks I still need to address. Allthough minor, it's going to take me some time to get it to the first step before I want to submit I'll submit it with only ich9 id's at first, but it will be able to drive (sysfs bind) to some other devices too. This allows me to keep an eye out on the future structure that I want to give it without removing too much code that I might then later have to add back. Auke -
On Wed, 25 Jul 2007 08:21:10 -0700 gone.. -
Hello, I'm having issue compiling on i386 and x86_64. make defconfig on i386 : LD init/built-in.o LD .tmp_vmlinux1 probably this commit fd4aff1a28eecbd729b409bf7d3eff5948f20414 in the acpi tree. Thanks, C. -
Looks like mm's git-acpi.patch is missing a few things that are in the latest acpi tree. Apparently I exposed this issue to Andrew before I exposed the fix, and he got the former, but not the later -- my fault. The root problem is that CONFIG_ACPI_SLEEP is not set in defconfig, and it is not set because CONFIG_SMP=y, but CONFIG_HOTPLUG_CPU=n So tweaking that will get i386 and x86_64 building. However, it will not fix ia64. For that, the changes in the latest acpi tree are necessary. Andrew, you want to re-pull the acpi tree, or do you want me to send you some patches on top of the current mm? -Len -
On Wed, 25 Jul 2007 13:23:04 -0400 I'd appreciate a fix for this one, please - I'll drop it int he hot-fixes directory as quite a few people seem to be hitting this. -
I hit something similar: CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 drivers/built-in.o: In function `acpi_pci_choose_state': drivers/pci/pci-acpi.c:253: undefined reference to `acpi_pm_device_sleep_state' drivers/built-in.o: In function `pnpacpi_suspend': drivers/pnp/pnpacpi/core.c:124: undefined reference to `acpi_pm_device_sleep_state' make: *** [.tmp_vmlinux1] Error 1 I also have CONFIG_SMP=y and CONFIG_HOTPLUG_CPU=n Will try to investigate more... Torsten -
Removing (!SMP || SUSPEND_SMP) from the depends of ACPI_SLEEP and activation this option lets me build the kernel. But it does not boot: [ 0.000000] Linux version 2.6.23-rc1-mm1 (root@treogen) (gcc version 4.2.0 (Gentoo 4.2.0 p1.4)) #3 SMP Wed Jul 25 21:18:44 CEST 2007 [ 0.000000] Command line: earlyprintk=serial,ttyS0,38400 console=ttyS0,38400 console=tty1 crypt_root=/dev/md1 [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) [ 0.000000] BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 00000000dfff0000 (usable) [ 0.000000] BIOS-e820: 00000000dfff0000 - 00000000dfffe000 (ACPI data) [ 0.000000] BIOS-e820: 00000000dfffe000 - 00000000e0000000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fef00000 (reserved) [ 0.000000] BIOS-e820: 00000000ff700000 - 0000000100000000 (reserved) [ 0.000000] BIOS-e820: 0000000100000000 - 0000000120000000 (usable) [ 0.000000] console [earlyser0] enabled [ 0.000000] end_pfn_map = 1179648 kernel direct mapping tables up to 120000000 @ 8000-e000 [ 0.000000] DMI present. [ 0.000000] ACPI: RSDP 000FB5E0, 0014 (r0 ACPIAM) [ 0.000000] ACPI: RSDT DFFF0000, 003C (r1 A M I OEMRSDT 6000626 MSFT 97) [ 0.000000] ACPI: FACP DFFF0200, 0084 (r2 A M I OEMFACP 6000626 MSFT 97) [ 0.000000] ACPI: DSDT DFFF0450, 48E1 (r1 S0027 S0027000 0 INTL 20051117) [ 0.000000] ACPI: FACS DFFFE000, 0040 [ 0.000000] ACPI: APIC DFFF0390, 0080 (r1 A M I OEMAPIC 6000626 MSFT 97) [ 0.000000] ACPI: MCFG DFFF0410, 003C (r1 A M I OEMMCFG 6000626 MSFT 97) [ 0.000000] ACPI: OEMB DFFFE040, 0060 (r1 A M I AMI_OEM 6000626 MSFT 97) [ 0.000000] ACPI: SRAT DFFF4D40, 0110 (r1 AMD HAMMER ...
On Wed, 25 Jul 2007 22:22:41 +0200 Yes, I'm trying to hunt down a fix for that. Apparently it got repaired in the acpi pull which Linus just did. Quite a few people have been playing in that area. Can you please send the .config? -
# # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-rc1-mm1 # Wed Jul 25 21:18:15 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_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_NR_QUICK=2 CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=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 is not set CONFIG_SWAP=y CONFIG_SWAP_PREFETCH=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=18 # CONFIG_CONTAINERS is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_CONTAINER_NS is not set CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not ...
It boots OK on my test box, bummer. Please test -mm2 and if it also fails, it'd be great if you could run through http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt - it doesn't take very long. Thanks. -
I did two major changes when upgrading from 22-rc6-mm1 to 23-rc1-mm1. I switched from DISCONTIGMEM to SPARSEMEM and from SLAB to SLUB. The other combinations: SPARSEMEM+SLAB: [ 0.000000] early_node_map[4] active PFN ranges [ 0.000000] 0: 0 -> 159 [ 0.000000] 0: 256 -> 524288 [ 0.000000] 1: 524288 -> 917488 [ 0.000000] 1: 1048576 -> 1179648 PANIC: early exception rip ffffffff807c4ac5 error 2 cr2 ffffe20003000010 [ 0.000000] [ 0.000000] Call Trace: DISCONTIGMEM+SLUB: [ 39.833272] ..MP-BIOS bug: 8254 timer not connected to IO-APIC [ 40.016659] Kernel panic - not syncing: IO-APIC + timer doesn't work! Try using the 'noapic' kernel parameter DISCONTIGMEM+SLAB: Boots until it can't find / because I didn't append the correct initrd It also hit the MP-BIOS bug, but was not bothered by it: [ 36.696965] ..MP-BIOS bug: 8254 timer not connected to IO-APIC [ 36.880537] Using local APIC timer interrupts. [ 36.932215] result 12500283 [ 36.940581] Detected 12.500 MHz APIC timer. So I think, I will postpone SPARSEMEM until -mm2, as there are seem to be some problems in that area (Re: 2.6.23-rc1-mm1 sparsemem_vmemamp fix) But maybee I will get SLUB to work. ;) Torsten -
SLUB works, if I reboot (Alt+SysRq+B) from a 2.6.22-rc6-mm1 kernel. Otherwise it will panic with IO-APIC + timer not working. Differences in dmesg 2.6.22-rc6-mm1 has: [ 0.000000] Nvidia board detected. Ignoring ACPI timer override. [ 0.000000] If you got timer trouble try acpi_use_timer_override and [ 0.000000] ACPI: BIOS IRQ0 pin2 override ignored. and [ 0.000000] TSC calibrated against PM_TIMER 23-rc1-mm1 has: [ 0.000000] ACPI: IRQ0 used by override. [ 0.000000] ACPI: IRQ2 used by override. and [ 37.340319] ..MP-BIOS bug: 8254 timer not connected to IO-APIC I did not need to use acpi_use_timer_override with the older kernel. Do you need more info about my board/ BIOS/ ACPI tables? After the warm-boot trick 2.6.23-rc1-mm1 seems stable right now... Torsten -
Maybe simpler for mm1 to go backwards in time rather than forwards.
This should fix the problem at hand.
cheers,
-Len
commit 106994f83cdd97c77bfe1b333ca369560b6d0649
Author: Len Brown <len.brown@intel.com>
Date: Wed Jul 25 19:17:38 2007 -0400
ACPI: revert d-states branch from Jun-17 to Jun-19 for 2.6.23-rc1-mm1
Signed-off-by: Len Brown <len.brown@intel.com>
---
drivers/acpi/sleep/main.c | 75 ---------------------------------
drivers/pci/pci-acpi.c | 28 +-----------
drivers/pci/pci.c | 8 +--
drivers/pci/pci.h | 2
drivers/pnp/driver.c | 5 --
drivers/pnp/pnpacpi/core.c | 14 ------
include/acpi/acpi_bus.h | 2
include/linux/pnp.h | 4 -
8 files changed, 9 insertions(+), 129 deletions(-)
diff --git a/drivers/acpi/sleep/main.c b/drivers/acpi/sleep/main.c
index 34abe8e..ada2a6e 100644
--- a/drivers/acpi/sleep/main.c
+++ b/drivers/acpi/sleep/main.c
@@ -261,81 +261,6 @@ static struct platform_hibernation_ops acpi_hibernation_ops = {
};
#endif /* CONFIG_SOFTWARE_SUSPEND */
-/**
- * acpi_pm_device_sleep_state - return preferred power state of ACPI device
- * in the system sleep state given by %acpi_target_sleep_state
- * @dev: device to examine
- * @wake: if set, the device should be able to wake up the system
- * @d_min_p: used to store the upper limit of allowed states range
- * Return value: preferred power state of the device on success, -ENODEV on
- * failure (ie. if there's no 'struct acpi_device' for @dev)
- *
- * Find the lowest power (highest number) ACPI device power state that
- * device @dev can be in while the system is in the sleep state represented
- * by %acpi_target_sleep_state. If @wake is nonzero, the device should be
- * able to wake up the system from this sleep state. If @d_min_p is set,
- * the highest power (lowest number) device power state of @dev allowed
- * in this system sleep state is stored at the location pointed to by it.
- *
- * The caller ...I see this made it to the hot-fix directory. It fixes the problem for me Thanks Len -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -
Hello, found that one on ppc, drivers/char/hw_random/pasemi-rng.c:140: error: unknown field 'type' specified in initializer drivers/char/hw_random/pasemi-rng.c:140: warning: initialization makes pointer from integer without a cast hwrng-add-type-categories.patch modifies a struct of the wrong type. the pasemi-rng driver registers a 'of_platform_driver' not a 'hwrng'. cheers, C. -
On Wed, 25 Jul 2007 14:40:49 +0200 OK, thanks. Those patches generated a decent-sized flamewar anyway so I think I'll drop them as obviosuly some more thought/discussion is needed there. -
from pm-move-definition-of-struct-pm_ops-to-suspendh.patch : drivers/video/chipsfb.c: In function 'chipsfb_pci_suspend': drivers/video/chipsfb.c:461: error: 'PM_SUSPEND_MEM' undeclared (first use in this function) drivers/video/chipsfb.c:461: error: (Each undeclared identifier is reported only once drivers/video/chipsfb.c:461: error: for each function it appears in.) Cheers, C. Signed-off-by: Cedric Le Goater <clg@fr.ibm.com> --- drivers/video/chipsfb.c | 1 + 1 file changed, 1 insertion(+) Index: 2.6.23-rc1-mm1/drivers/video/chipsfb.c =================================================================== --- 2.6.23-rc1-mm1.orig/drivers/video/chipsfb.c +++ 2.6.23-rc1-mm1/drivers/video/chipsfb.c @@ -27,6 +27,7 @@ #include <linux/init.h> #include <linux/pci.h> #include <linux/console.h> +#include <linux/suspend.h> #include <asm/io.h> #ifdef CONFIG_PMAC_BACKLIGHT -
Well, actually, this is a bug in chipsfb.c, as it shouldn't use PM_SUSPEND_MEM in there, but PMSG_SUSPEND (patch untested). Greetings, Rafael --- drivers/video/chipsfb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6.23-rc1/drivers/video/chipsfb.c =================================================================== --- linux-2.6.23-rc1.orig/drivers/video/chipsfb.c +++ linux-2.6.23-rc1/drivers/video/chipsfb.c @@ -458,7 +458,7 @@ static int chipsfb_pci_suspend(struct pc if (state.event == pdev->dev.power.power_state.event) return 0; - if (state.event != PM_SUSPEND_MEM) + if (state != PMSG_SUSPEND) goto done; acquire_console_sem(); -
On Wed, 25 Jul 2007 15:48:10 +0200 For reasons which aren't immediately obvious, the compiler didn't like that: comparing with an immediate struct liek that is a bit tricky. This is equivalent, and works: --- a/drivers/video/chipsfb.c~chipsfb-use-correct-pm-state +++ a/drivers/video/chipsfb.c @@ -24,6 +24,7 @@ #include <linux/delay.h> #include <linux/interrupt.h> #include <linux/fb.h> +#include <linux/pm.h> #include <linux/init.h> #include <linux/pci.h> #include <linux/console.h> @@ -458,7 +459,7 @@ static int chipsfb_pci_suspend(struct pc if (state.event == pdev->dev.power.power_state.event) return 0; - if (state.event != PM_SUSPEND_MEM) + if (state.event != PM_EVENT_SUSPEND) goto done; acquire_console_sem(); _ Is this a 2.6.23 thing? -
Should not hurt anything, i'd say so. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -
nokturn vs. reiserfs 1:0
[ 1228.964379] =============================================
[ 1228.971271] [ INFO: possible recursive locking detected ]
[ 1228.976674] 2.6.23-rc1-mm1 #1
[ 1228.979655] ---------------------------------------------
[ 1228.985064] chcon/21470 is trying to acquire lock:
[ 1228.989858] (&inode->i_mutex){--..}, at: [<c06993ea>] mutex_lock+0x1c/0x1f
[ 1228.996968]
[ 1228.996972] but task is already holding lock:
[ 1229.002834] (&inode->i_mutex){--..}, at: [<c06993ea>] mutex_lock+0x1c/0x1f
[ 1229.009958]
[ 1229.009962] other info that might help us debug this:
[ 1229.016510] 3 locks held by chcon/21470:
[ 1229.020434] #0: (&inode->i_mutex){--..}, at: [<c06993ea>] mutex_lock+0x1c/0x1f
[ 1229.027971] #1: (&REISERFS_I(inode)->xattr_sem){----}, at: [<fdd59d36>] reiserfs_setxattr+0x54/0xf2 [reiserfs]
[ 1229.038282] #2: (&REISERFS_SB(s)->xattr_dir_sem){----}, at: [<fdd59d55>] reiserfs_setxattr+0x73/0xf2 [reiserfs]
[ 1229.048682]
[ 1229.048687] stack backtrace:
[ 1229.053070] [<c04053eb>] show_trace_log_lvl+0x1a/0x30
[ 1229.058254] [<c0406073>] show_trace+0x12/0x14
[ 1229.062734] [<c04061a8>] dump_stack+0x16/0x18
[ 1229.067222] [<c044c887>] __lock_acquire+0xe19/0x125c
[ 1229.072309] [<c044cd71>] lock_acquire+0xa7/0xc1
[ 1229.076967] [<c069908e>] __mutex_lock_slowpath+0x9b/0x3db
[ 1229.082493] [<c06993ea>] mutex_lock+0x1c/0x1f
[ 1229.086972] [<fdd5a2d1>] reiserfs_xattr_set+0x14c/0x2db [reiserfs]
[ 1229.093281] [<fdd5a7e2>] security_set+0x4d/0x51 [reiserfs]
[ 1229.098898] [<fdd59d6d>] reiserfs_setxattr+0x8b/0xf2 [reiserfs]
[ 1229.104950] [<c04aee43>] vfs_setxattr+0x8a/0x199
[ 1229.109696] [<c04aefcf>] setxattr+0x7d/0x109
[ 1229.114087] [<c04af0ec>] sys_setxattr+0x41/0x53
[ 1229.118737] [<c04043ba>] syscall_call+0x7/0xb
[ 1229.123215] =======================
[ 1229.249502] chcon used greatest stack depth: 1080 bytes ...On Wed, 25 Jul 2007 18:32:58 +0200 The usual two-unrelated-i_mutexes-taken problem. Usually solved by adding lockdep annotation to say "this is OK". -
Of the machines we test releases on automatically this only compiles on NUMA-Q and does not boot there (some PCI issue). ppc64 (beavis): make: *** [.tmp_vmlinux1] Error 1 x86_64 (bl6-13): ERROR: "scsi_tgt_it_nexus_destroy" [drivers/scsi/scsi_transport_srp.ko] undefined! ERROR: "scsi_tgt_it_nexus_create" [drivers/scsi/scsi_transport_srp.ko] undefined! make[1]: *** [__modpost] Error 1 ia64 (elm3a170): drivers/built-in.o: In function `acpi_pci_choose_state': pci-acpi.c:(.text+0x18d02): undefined reference to `acpi_pm_device_sleep_state' drivers/built-in.o: In function `pnpacpi_suspend': core.c:(.text+0x86ec2): undefined reference to `acpi_pm_device_sleep_state' make: *** [.tmp_vmlinux1] Error 1 ia64 (elm3b10): LD vmlinux.o ld: dynreloc miscount for kernel/built-in.o, section .opd ld: can not edit opd Bad value make: *** [vmlinux.o] Error 1 ppc64 (gekko-lp1): make: *** [.tmp_vmlinux1] Error 1 Will investigate the NUMA-Q explosion and report on that separatly. -apw -
On powerpc we had something similar. It was a binutils bug (see: http://article.gmane.org/gmane.comp.gnu.binutils/33650) I tracked it down to be fixed by the following: diff --git a/include/linux/mm.h b/include/linux/mm.h index c456c3a..2ea222f 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -1246,7 +1246,7 @@ void drop_slab(void); extern int randomize_va_space; #endif -__attribute__((weak)) const char *arch_vma_name(struct vm_area_struct *vma); +//__attribute__((weak)) const char *arch_vma_name(struct vm_area_struct *vma); #endif /* __KERNEL__ */ #endif /* _LINUX_MM_H */ This is obviously just a quick hack and I used brutal force to find out how to fix it - but does not yet understand why this weak prototype cause the bug. Sam -
Caused-By : git-scsi-target.patch
Workaround : enable CONFIG_SCSI_TGT
Is there any good reason why all the SCSI transport attributes options
are user visible?
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
-
From: Adrian Bunk <bunk@stusta.de> Subject: 2.6.23-rc1-mm1: SCSI_SRP_ATTRS compile error Sorry about this. Andrew, could you drop the scsi-target tree from -mm? I was surprised that the scsi-target tree is still in -mm (it had been tested in -mm before the mainline inclusion). I guess that it's the No, I messed up the dependency somewhere. I'll fix it before it is merged into scsi-misc. Thanks, -
Ok, I've been looking at the NUMA-Q boot panic below:
BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000
printing eip:
c111689f
*pdpt = 0000000001387001
*pde = 0000000000000000
Oops: 0000 [#1]
SMP
Modules linked in:
CPU: 0
EIP: 0060:[<c111689f>] Not tainted VLI
EFLAGS: 00010286 (2.6.23-rc1-mm1-gc8131905-dirty #251)
EIP is at pci_create_bus+0x11b/0x277
eax: 00000000 ebx: c9352e00 ecx: c9073e94 edx: c9325400
esi: c9325400 edi: c932559c ebp: 00000002 esp: c9073e90
ds: 007b es: 007b fs: 00d8 gs: 0000 ss: 0068
Process swapper (pid: 1, ti=c9072000 task=c9070030 task.ti=c9072000)
Stack: c12adc4f c9325400 00000000 00000002 00000000 00000000 00000000 c934c800
000000d6 00000000 c1116a09 00000000 c9073ed5 c11b178a 00000000 c934c940
00000000 02fffff4 c12bd8ac c934c800 c12bd8b4 c9325000 c1119825 c934c800
Call Trace:
[<c1116a09>] pci_scan_bus_parented+0xe/0x21
[<c11b178a>] pci_fixup_i450nx+0xa7/0x101
[<c1119825>] pci_do_fixups+0x2d/0x38
[<c111665c>] pci_device_add+0x48/0x77
[<c11166a5>] pci_scan_single_device+0x1a/0x1f
[<c11166bf>] pci_scan_slot+0x15/0x47
[<c111670a>] pci_scan_child_bus+0x19/0x7c
[<c1116a14>] pci_scan_bus_parented+0x19/0x21
[<c11b259d>] pcibios_scan_root+0x75/0x7e
[<c1369ee3>] pci_numa_init+0x2c/0xe4
[<c1354b87>] kernel_init+0x0/0xa1
[<c1354a15>] do_initcalls+0x73/0x1a3
[<c109032c>] proc_register+0xa0/0xa7
[<c10905cd>] create_proc_entry+0x73/0x86
[<c103a5c9>] register_irq_proc+0x75/0x92
[<c1354b87>] kernel_init+0x0/0xa1
[<c1354be6>] kernel_init+0x5f/0xa1
[<c10031c3>] kernel_thread_helper+0x7/0x10
=======================
Code: ff 8b 83 84 00 00 00 c7 04 24 4f dc 2a c1 89 44 24 04 e8 f8 42 f0 ff 83 7c 24 14 00 75 15 8b 93 84 00 00 00 85 d2 74 0b 8b 43 44 <8b> 00 89 82 50 01 00 00 c7 44 24 04 9a 04 00 00 8d bb 88 00 00
EIP: [<c111689f>] pci_create_bus+0x11b/0x277 SS:ESP 0068:c9073e90
Kernel panic - not syncing: Attempted to kill init!
This seems to have been caused by ...All this could have happened due to my hamfisted repairing of yet another ok.. -
Can we add .node and .iommu to pci_bus? YH -
This patch causes the following compile error:
<-- snip -->
...
CC net/ipv4/fib_trie.o
/home/bunk/linux/kernel-2.6/linux-2.6.23-rc1-mm1/net/ipv4/fib_trie.c: In function ‘trie_rebalance’:
/home/bunk/linux/kernel-2.6/linux-2.6.23-rc1-mm1/net/ipv4/fib_trie.c:969: error: lvalue required as unary ‘&’ operand
/home/bunk/linux/kernel-2.6/linux-2.6.23-rc1-mm1/net/ipv4/fib_trie.c:971: error: lvalue required as unary ‘&’ operand
/home/bunk/linux/kernel-2.6/linux-2.6.23-rc1-mm1/net/ipv4/fib_trie.c:977: error: lvalue required as unary ‘&’ operand
/home/bunk/linux/kernel-2.6/linux-2.6.23-rc1-mm1/net/ipv4/fib_trie.c:980: error: lvalue required as unary ‘&’ operand
...
make[3]: *** [net/ipv4/fib_trie.o] Error 1
<-- snip -->
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
-
<-- snip -->
...
LD .tmp_vmlinux1
lib/built-in.o: In function `lzo1x_1_compress':
(.text+0x13eae): multiple definition of `lzo1x_1_compress'
fs/built-in.o:(.text+0x117075): first defined here
make[1]: *** [.tmp_vmlinux1] Error 1
<-- snip -->
AFAIR, we once had a patch in -mm changing reiser4 to use the
LZO code that is now in the kernel?
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
-
Sorry, guys, I am not happy with the modified LZO: the compressor tries to test bytes which are out of bounds. The attached module testlzo.c causes an oops in the second pass: AFAIK, both, @m and @m_pos should be in [wrkmem, wrkmem + 64K); I have attached trace.txt with their actual values. Not ready to migrate to this library. Any ideas? Thanks, Edward. P.S. kernel: 2.6.23-rc1-mm1 box: x86
I can confirm its broken, it give an oops on ARM 2.6.23-rc1 too in the first pass. I guess the only real solution now is to compare the byte code from the new and original and find out where this problem has crept in from and check there are no others. I'll look into it but its going to take time. There goes my weekend :-( Richard -
Andi, this might be interesting for you make allmodconfig make [...] WARNING: Absolute relocations present Offset Info Type Sym.Value Sym.Name c02041b3 00705601 R_386_32 c0308aa8 _sdata Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ -
Who did spit out this warning. Can you please provide make V=1 where we see the lines preceeding the warning. And config please. Sam -
config: "make allmodconfig" System.map would be more interesting, especially what is at 0xc02041b3. -hpa -
I get here : WARNING: Absolute relocations present Offset Info Type Sym.Value Sym.Name c0202e73 00703601 R_386_32 c03071bc _sdata $ grep c03071bc System.map c03071bc R __tracedata_end Gabriel -
Guessing is this patch ? gregkh-driver-warn-when-statically-allocated-kobjects-are-used.patch: __tracedata_end = .; gregkh-driver-warn-when-statically-allocated-kobjects-are-used.patch:+ _sdata = .; /* End of text section */ -
This patch is a horrible hack to try to see if kobjects are static and not dynamically created. Dave, any ideas what is happening here? thanks, greg k-h -
On Wed, 25 Jul 2007 17:07:05 -0700 You could perhaps use something like module_address_lookup() for this debugging aid. -
There's a hopeful-fix for this in ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc1/2.6.23-rc1-mm... (will be readable in a few minutes - I had to chmod it) -
I've seen those warnings for other random stuff, but I have no idea what they mean. :( Is there a preferred way to access symbol addresses? -- Dave -
... drivers/char/nozomi.c: In function 'interrupt_handler': drivers/char/nozomi.c:1298: warning: overflow in implicit constant conversion drivers/char/nozomi.c: In function 'nozomi_card_init': drivers/char/nozomi.c:1568: warning: overflow in implicit constant conversion drivers/char/nozomi.c:1592: warning: overflow in implicit constant conversion drivers/char/nozomi.c: In function 'nozomi_card_exit': drivers/char/nozomi.c:1673: warning: overflow in implicit constant conversion ... config is a allmodconfig. Regards, Gabriel C -
Ick, yeah, that driver needs help. Luckily someone is starting to work on it now and help clean it up. thanks for letting me know. greg k-h -
m32r was forgotten:
<-- snip -->
...
CC arch/m32r/mm/fault.o
arch/m32r/mm/fault.c: In function 'do_page_fault':
arch/m32r/mm/fault.c:274: error: implicit declaration of function 'is_init'
make[2]: *** [arch/m32r/mm/fault.o] Error 1
<-- snip -->
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
-
Adrian Bunk [bunk@stusta.de] wrote: | On Wed, Jul 25, 2007 at 04:03:04AM -0700, Andrew Morton wrote: | >... | > Changes since 2.6.22-rc6-mm1: | >... | > +pid-namespaces-define-is_global_init-and-is_container_init.patch | >... | > pid namespaces | >... | | m32r was forgotten: | | <-- snip --> | | ... | CC arch/m32r/mm/fault.o | arch/m32r/mm/fault.c: In function 'do_page_fault': | arch/m32r/mm/fault.c:274: error: implicit declaration of function 'is_init' | make[2]: *** [arch/m32r/mm/fault.o] Error 1 | | <-- snip --> Sorry. Here is a fix for it. --- From: Sukadev Bhattiprolu <sukadev@us.ibm.com> Subject: [PATCH] Use is_global_init() in arch/m32r/mm/fault.c Use is_global_init() in arch/m32r/mm/fault.c. Signed-off-by: Sukadev Bhattiprolu <sukadev@us.ibm.com> Cc: Cedric Le Goater <clg@fr.ibm.com> Cc: Dave Hansen <haveblue@us.ibm.com> Cc: Serge Hallyn <serue@us.ibm.com> Cc: containers@lists.osdl.org --- arch/m32r/mm/fault.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: lx26-23-rc1-mm1/arch/m32r/mm/fault.c =================================================================== --- lx26-23-rc1-mm1.orig/arch/m32r/mm/fault.c 2007-07-25 14:24:18.000000000 -0700 +++ lx26-23-rc1-mm1/arch/m32r/mm/fault.c 2007-07-25 14:32:23.000000000 -0700 @@ -271,7 +271,7 @@ no_context: */ out_of_memory: up_read(&mm->mmap_sem); - if (is_init(tsk)) { + if (is_global_init(tsk)) { yield(); down_read(&mm->mmap_sem); goto survive; -
This causes the following compile error on sh:
<-- snip -->
...
CC drivers/serial/sh-sci.o
drivers/serial/sh-sci.c: In function 'put_string':
drivers/serial/sh-sci.c:188: error: 'hexchars' undeclared (first use in this function)
drivers/serial/sh-sci.c:188: error: (Each undeclared identifier is reported only once
drivers/serial/sh-sci.c:188: error: for each function it appears in.)
make[3]: *** [drivers/serial/sh-sci.o] Error 1
<-- snip -->
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
-
Cool, it's like 5 years ago all over again. It looks like most of the kgdb stuff is going to need to be re-ported, as it's effectively thrown out years of changes, and perhaps not surprisingly, blows up quite spectacularly in the process. At least this problem with KGDB disabled is an easy fix. I'll see about getting CONFIG_KGDB=y resynced with the current serial driver and arch stub. ----- serial: sh-sci: Fix build failure from kgdb fallout. CC drivers/serial/sh-sci.o drivers/serial/sh-sci.c: In function 'put_string': drivers/serial/sh-sci.c:188: error: 'hexchars' undeclared (first use in this function) drivers/serial/sh-sci.c:188: error: (Each undeclared identifier is reported only once drivers/serial/sh-sci.c:188: error: for each function it appears in.) make[3]: *** [drivers/serial/sh-sci.o] Error 1 Reported-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Paul Mundt <lethal@linux-sh.org> -- drivers/serial/sh-sci.c | 1 + 1 file changed, 1 insertion(+) diff -X linux-2.6.23-rc1-mm1/Documentation/dontdiff -urN linux-2.6.23-rc1-mm1.orig/drivers/serial/sh-sci.c linux-2.6.23-rc1-mm1/drivers/serial/sh-sci.c --- linux-2.6.23-rc1-mm1.orig/drivers/serial/sh-sci.c 2007-07-26 10:23:51.000000000 +0900 +++ linux-2.6.23-rc1-mm1/drivers/serial/sh-sci.c 2007-07-26 10:34:59.000000000 +0900 @@ -161,6 +161,7 @@ #if defined(CONFIG_SH_STANDARD_BIOS) || defined(CONFIG_SH_KGDB) int checksum; + const char hexchars[] = "0123456789abcdef"; int usegdb=0; #ifdef CONFIG_SH_STANDARD_BIOS -
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 [ 193.154370] [<ffffffff803ba945>] ...
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 pear-shaped in tis_tpm_send(), when they get to the
'if (chip->vendor.irq)' - under 22-rc6-mm1, we never got into this code,
because earlier initialization complained it couldn't get IRQ8. Now, we
get IRQ3, and apparently get into this if statement, and then spend 120
seconds while wait_for_stat() times out. So the root cause does look like
it's this IRQ8/IRQ3 issue.
I'll try to find time to do a bisect on -rc1-mm1 tomorrow to track down
what exactly did this.
(And remember to keep in mind the very real possibility that in fact, both
releases are broken in different ways - I've never actually *done* anything
with the chip further than "the driver loads". Anybody got a very basic
userspace program to test-harness /dev/tpm0 (open, do a few test calls, close)?
--==_Exmh_1185507681_33070
Content-Type: text/plain ; name="debug.22-rc6-mm1"; charset=us-ascii
Content-Description: debug.22-rc6-mm1
Content-Disposition: attachment; filename="debug.22-rc6-mm1"
[ 32.324000] tpm_tis_pnp_init: start=4275306496, len=20480
[ 32.324000] tpm_tis 00:0f: 1.2 TPM (device-id 0x1001, rev-id 2)
[ 32.324000] tpm_tis 00:0f: TPM interface capabilities (0x97):
[ 32.324000] tpm_tis 00:0f: Command Ready Int Support
[ 32.324000] tpm_tis 00:0f: Interrupt Level Low
[ 32.324000] tpm_tis 00:0f: Locality Change Int ...And we have a winner. In my bisect 'hunt' file, I ended at:
fs-use-kmem_cache_zalloc-instead.patch GOOD
# remove-kconfig-setting-config_debug_shirq.patch: Ingo worried
remove-kconfig-setting-config_debug_shirq.patch BAD
Looks like Ingo was right. :) As a cross-check, I tested a 'GOOD' kernel,
but rebuilt with CONFIG_DEBUG_SHIRQ=y, and that *also* died.
Looks like the problematic code is in tpm_tis.c tpm_tis_init() near here:
for (i = 3; i < 16 && chip->vendor.irq == 0; i++) {
iowrite8(i, chip->vendor.iobase +
TPM_INT_VECTOR(chip->vendor.locality));
if (request_irq
(i, tis_int_probe, IRQF_SHARED,
chip->vendor.miscdev.name, chip) != 0) {
dev_info(chip->dev,
"Unable to request irq: %d for probe\n"
,
i);
continue;
}
This seems to be misbehaving differently for the two different DEBUG_SHIRQ
cases.
With DEBUG_SHIRQ=n, it starts at IRQ3, gets to at least 8 (where it complains
it can't request it for probing), and possibly all the way to 15, without ever
actually selecting and assigning an IRQ (to refresh memories, in that range
/proc/interrupts only lists:
8: 0 0 IO-APIC-edge rtc
9: 3 0 IO-APIC-fasteoi acpi
12: 94 0 IO-APIC-edge i8042
14: 148166 0 IO-APIC-edge libata
15: 94 0 IO-APIC-edge libata
So there's certainly IRQ's available. No idea why it doesn't choose one. But
since it never chose one, it never gets into the "wait for the IRQ" protected
by 'if (chip->vendor.irq)' at the end of tpm_tis_send.
With DEBUG_SHIRQ=y, It starts at IRQ3, and assigns it (which seems a good thing).
Unfortunately, this then ...On Fri, 27 Jul 2007 09:28:09 -0400 Fernando, those patches are just too scary for me because of stuff like this. Perhaps we should look at implementing this new behaviour on a per-driver basis? Pass smoe new flag into request_irq(), perhaps? -
Has anybody else hit an actual problem with this, or is the borkage restricted to this one driver? And, quite frankly, given that *before*, the driver would try and reject 5 different unused IRQs and then complain when it found one in use, I'm not totally convinced that the driver wasn't on crack *before*. The only thing I've been able to prove to myself is that it's acting differently, but I'm pretty sure that *both* before and after are broken, just in different ways. I'd not fault Fernando's patch here - if I'd enabled the DEBUG_SHIRQ on previous kernels, I'd have spotted it then. I never enabled it because I didn't know I had drivers that might have bugs in that area. Kylene or somebody else who actually understands the TPM chipsets would have to provide guidance on how it's *supposed* to work, and I'm certainly willing to testbed patches. For what it's worth - I actually read the source some more, discovered the module parm 'interrupts=0' (which forces polling mode), and managed to get things at least semi-working with the libtpm-2.0 test suite: ~/src/libtpm-2.0/utils % ./tpm_demo TPM version 1.1.0.0 24 PCR registers are available PCR-00: 48 88 FD B3 F6 04 AF 54 9F 6A 53 19 96 38 4F BF 02 52 3F C7 PCR-01: 5B 93 BB A0 A6 64 A7 10 52 59 4A 70 95 B2 07 75 77 03 45 0B PCR-02: 5B 93 BB A0 A6 64 A7 10 52 59 4A 70 95 B2 07 75 77 03 45 0B PCR-03: 5B 93 BB A0 A6 64 A7 10 52 59 4A 70 95 B2 07 75 77 03 45 0B PCR-04: 7D 89 C5 0D C7 E5 2F F1 2C 56 0C C2 84 40 FD ED 06 B4 D6 B7 PCR-05: 23 E4 5B 96 79 C4 52 F7 4A EA 76 04 46 FF BB D1 02 D0 3D 27 PCR-06: 5B 93 BB A0 A6 64 A7 10 52 59 4A 70 95 B2 07 75 77 03 45 0B PCR-07: 5B 93 BB A0 A6 64 A7 10 52 59 4A 70 95 B2 07 75 77 03 45 0B PCR-08: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCR-09: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCR-10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCR-11: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 PCR-12: 00 00 ...
I don't know why tpm_tis_init() is messing around trying different IRQs between 3 and 16. That looks suspiciously x86-dependent. Maybe if you don't have PNP (though I doubt TPMs exist on any pre-PNPBIOS machines) the "check-IRQ" loop would be necessary. But you're using the PNP probe, and PNP should just tell you what IRQ the device is configured for (and whether the IRQ can be shared -- see 8250_pnp.c for an example). The BIOS should have configured the TPM IRQ, and if we go and mess with that IRQ setting without going through the PNP interface, e.g., the ACPI _SRS method, we're liable to mess something up. The TPM is often behind a few bridges, and if the bridge has any IRQ routing configuration, only the BIOS knows how to keep that in What's in /sys/bus/pnp/devices/00:0e/resources? Bjorn -
I think tpm_tis should do something like the patch below to discover
its interrupt. If ACPI tells us the device's IRQ, we should just use
it rather than blindly trying a few possibilities. So the patch below
might make it work, because it should skip the problematic code you
identified above.
But there could still be an issue with DEBUG_SHIRQ and the IRQ probe
loop. Even if we used the attached patch, we'd probably still want
the IRQ probe to work when you specify tpm_tis.force=1.
Index: w/drivers/char/tpm/tpm_tis.c
===================================================================
--- w.orig/drivers/char/tpm/tpm_tis.c 2007-07-30 11:29:31.000000000 -0600
+++ w/drivers/char/tpm/tpm_tis.c 2007-07-30 11:35:20.000000000 -0600
@@ -433,17 +433,12 @@
MODULE_PARM_DESC(interrupts, "Enable interrupts");
static int tpm_tis_init(struct device *dev, resource_size_t start,
- resource_size_t len)
+ resource_size_t len, unsigned int irq)
{
u32 vendor, intfcaps, intmask;
int rc, i;
struct tpm_chip *chip;
- if (!start)
- start = TIS_MEM_BASE;
- if (!len)
- len = TIS_MEM_LEN;
-
if (!(chip = tpm_register_hardware(dev, &tpm_tis)))
return -ENODEV;
@@ -510,7 +505,9 @@
iowrite32(intmask,
chip->vendor.iobase +
TPM_INT_ENABLE(chip->vendor.locality));
- if (interrupts) {
+ if (interrupts)
+ chip->vendor.irq = irq;
+ if (interrupts && !chip->vendor.irq) {
chip->vendor.irq =
ioread8(chip->vendor.iobase +
TPM_INT_VECTOR(chip->vendor.locality));
@@ -595,10 +592,13 @@
const struct pnp_device_id *pnp_id)
{
resource_size_t start, len;
+ unsigned int irq;
+
start = pnp_mem_start(pnp_dev, 0);
len = pnp_mem_len(pnp_dev, 0);
+ irq = pnp_irq(pnp_dev, 0);
- return tpm_tis_init(&pnp_dev->dev, start, len);
+ return tpm_tis_init(&pnp_dev->dev, start, len, irq);
}
static int tpm_tis_pnp_suspend(struct pnp_dev *dev, pm_message_t msg)
@@ -658,7 +658,7 @@
return rc;
if ...Well, it's a 6 month old Dell Latitude, and PNP is most certainly there, % cat /sys/bus/pnp/devices/00:0e/resources state = active io 0x378-0x37f io 0x778-0x77b irq 7 dma 1 IRQ 7. That would certainly explain why I was seeing massive timeouts when the driver chose to use IRQ 3. ;) I'll test-drive your patch from Monday's e-mail when I get home tonight.
Scratch that. When I wrote the first note, I was at home, and the TPM chip
did its PNP thing and became 00:0e. I failed to notice that in my reply,
I was at work, and the printer port on the docking station became 00:0e and
the TPM became 00:0f.
% cat /sys/devices/pnp0/00:0f/id
BCM0102
PNP0c31
% cat /sys/devices/pnp0/00:0f/resources
state = active
io 0xcb0-0xcbb
mem 0xfed40000-0xfed44fff
So there *isn't* an IRQ assigned. When I tried the patch you sent,
I added a few debugging printk's, thusly:
if (interrupts)
chip->vendor.irq = irq;
printk(KERN_DEBUG "in tis_init, interrupts=%d irq=%d\n",interrupts,irq);
if (interrupts && !chip->vendor.irq) {
chip->vendor.irq =
ioread8(chip->vendor.iobase +
TPM_INT_VECTOR(chip->vendor.locality));
printk(KERN_DEBUG "after ioread8, interrupts=%d irq=%d\n",interrupts,chip->vendor.irq);
for (i = 3; i < 16 && chip->vendor.irq == 0; i++) {
[ 1971.644193] in pnp_init, start=fed40000 len=5000 irq=-1
[ 1971.650907] tpm_tis 00:0f: 1.2 TPM (device-id 0x1001, rev-id 2)
[ 1971.650923] in tis_init, interrupts=1 irq=-1
[ 1971.650929] tpm_tis 00:0f: Unable to request irq: -1 for use
and it loads immediately.
I thought that !chip->vendor.irq looked like a wrong test, because if the
chip says '-1' meaning "no default assigned", and conversely, if the chip
had a positive number, we should be *using* that IRQ if we can, rather than
looping from 3 to 15 looking for one. So I tried it with (chip->vendor.irc < 0),
and this happened:
[ 2254.834377] in pnp_init, start=fed40000 len=5000 irq=-1
[ 2254.840422] tpm_tis 00:0f: 1.2 TPM (device-id 0x1001, rev-id 2)
[ 2254.840438] in tis_init, interrupts=1 irq=-1
[ 2254.840443] after ioread8, interrupts=1 irq=15
[ 2254.840457] tpm0 (IRQ 15) handled a spurious interrupt
[ 2256.839077] tpm_tis 00:0f: tpm_transmit: tpm_send: error -62
[ 2376.771347] tpm_tis 00:0f: tpm_transmit: tpm_send: ...Interesting. I should have noticed that the first resources looked like
a parallel port. I've been looking at those recently because they're
also broken :-)
So, the BIOS is telling us that at least as currently configured, the
TPM can't use interrupts. /sys/devices/pnp0/00:0f/options should have
all the *possible* TPM configurations. I would guess that none of them
shows an IRQ either.
In general, if the BIOS says there's no interrupt, we should not poke
around looking for one unless we think there's a BIOS defect. I think
you said that under 2.6.22-rc6-mm1, the TPM didn't find a working
Yup, I hadn't considered the case of BIOS not telling us an interrupt
for the device. In that case, I think we should force interrupts off
as you suggest. Here's the patch I would propose:
Index: w/drivers/char/tpm/tpm_tis.c
===================================================================
--- w.orig/drivers/char/tpm/tpm_tis.c 2007-07-31 09:15:43.000000000 -0600
+++ w/drivers/char/tpm/tpm_tis.c 2007-07-31 13:58:55.000000000 -0600
@@ -433,17 +433,12 @@
MODULE_PARM_DESC(interrupts, "Enable interrupts");
static int tpm_tis_init(struct device *dev, resource_size_t start,
- resource_size_t len)
+ resource_size_t len, unsigned int irq)
{
u32 vendor, intfcaps, intmask;
int rc, i;
struct tpm_chip *chip;
- if (!start)
- start = TIS_MEM_BASE;
- if (!len)
- len = TIS_MEM_LEN;
-
if (!(chip = tpm_register_hardware(dev, &tpm_tis)))
return -ENODEV;
@@ -510,7 +505,9 @@
iowrite32(intmask,
chip->vendor.iobase +
TPM_INT_ENABLE(chip->vendor.locality));
- if (interrupts) {
+ if (interrupts)
+ chip->vendor.irq = irq;
+ if (interrupts && !chip->vendor.irq) {
chip->vendor.irq =
ioread8(chip->vendor.iobase +
TPM_INT_VECTOR(chip->vendor.locality));
@@ -595,10 +592,17 @@
const struct pnp_device_id *pnp_id)
{
resource_size_t start, len;
+ unsigned int irq = 0;
+
start = pnp_mem_start(pnp_dev, 0);
len = ...Hmm.. Oddness. Looks empty:
# cat /sys/devices/pnp0/00\:0f/options | wc
0 0 0
Patch tested, and seems to decide to initialize in polled mode on my
machine, without having to do any /etc/modprobe.conf 'interrupts=0'.
I'm able to run the tpm_demo program from libtpm-2.0, so /dev/tpm0 does
seem to be operational.
You can stick this on the patch and pass it along:
Tested-By: <valdis.kletnieks@vt.edu>
but I'd suggest running a regression test against a chipset that *does*
do IRQs before sending it upstream (if you haven't already)...
"options" is populated using the ACPI _PRS method. The spec says that method is optional and non-configurable devices will not provide it. Yes. I don't think I have a box with a TIS TPM on it, but I hope Kylene does and will comment on this approach. I notice Andrew put it in -mm already. I'll be on vacation for the next couple weeks, so I won't be able to poke at this for a while. Here's the changelog I would insert (for tpm_tis-fix-interrupt-probing.patch): [patch] tpm: pay attention to IRQ info from PNP If we discover the TIS TPM device via PNP, use the PNP IRQ information rather than probing for an IRQ. If PNP shows no IRQ, run the TPM in polling mode. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> -
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 - hardware, ...
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
-
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. -
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)
-
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;
- pud++, addr += PUD_SIZE) ...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 -
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> -
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 depends are not really easy ...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 -
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. -
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. -
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. -
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, 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 -
[ 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 -
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. -
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" <symbol> <symbol> ["if" <expr>] ...
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 -
... 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, 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 -
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)
-
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;
-
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 ...
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 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 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,
-
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! -
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;
-
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
-
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 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 void ...Acked-by: James Morris <jmorris@namei.org> -- James Morris <jmorris@namei.org> -
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] [<ffffffff8025baee>] ...
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 -
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.426531] DR0: ...
