Re: PANIC: 2.6.21-rc7-mm2, Kernel access of bad area, sig: 11
On Sat, 28 Apr 2007, William Heimbigner wrote: On Sat, 28 Apr 2007, Andrew Morton wrote: On Sat, 28 Apr 2007 21:40:19 + (GMT) William Heimbigner <[EMAIL PROTECTED]> wrote: > This bug occurs in linux-2.6.21-rc7-mm2, and does not occur in > 2.6.21-rc7 > ARCH is powerpc > > dmesg output, captured via netconsole: > [0.00] Using PowerMac machine description > [0.00] Total memory = 128MB; using 256kB for hash table (at > c7fc) > [0.00] Linux version 2.6.21-rc7-mm2 ([EMAIL PROTECTED]) (gcc version > 4.1.1 (Gentoo 4.1.1-r3)) #3 SMP PREEMPT Sat Apr 28 14:29:54 CDT 2007 > [0.00] Found UniNorth memory controller & host bridge @ > 0xf800 revision: 0xc0 > [0.00] Mapped at 0xfdfc > [0.00] Found a Pangea mac-io controller, rev: 0, mapped at > 0xfdf4 > [0.00] PowerMac motherboard: iMac "Flower Power" It ran OK on my G5. Can you send the config please? grep -v "is not set" .config: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc7-mm2 # Sat Apr 28 14:04:08 2007 # CONFIG_PPC_PM_NEEDS_RTC_LIB=y CONFIG_PPC32=y CONFIG_PPC_MERGE=y CONFIG_MMU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_IRQ_PER_CPU=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_PPC_UDBG_16550=y CONFIG_GENERIC_TBSYNC=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # # Processor support # CONFIG_CLASSIC32=y CONFIG_6xx=y CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_32=y CONFIG_SMP=y CONFIG_NR_CPUS=2 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SWAP_PREFETCH=y CONFIG_SYSVIPC=y CONFIG_IPC_NS=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_SYSFS_DEPRECATED=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y 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_PROC_SMAPS=y CONFIG_PROC_CLEAR_REFS=y CONFIG_PROC_PAGEMAP=y CONFIG_PROC_KPAGEMAP=y CONFIG_SLUB=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Block layer # CONFIG_BLOCK=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_CFQ=y CONFIG_DEFAULT_IOSCHED="cfq" # # Platform support # CONFIG_PPC_MULTIPLATFORM=y CONFIG_PPC_CHRP=y CONFIG_PPC_PMAC=y CONFIG_PPC_NATIVE=y CONFIG_MPIC=y CONFIG_PPC_I8259=y CONFIG_PPC_RTAS=y CONFIG_RTAS_PROC=y CONFIG_PPC_MPC106=y # # CPU Frequency support # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y CONFIG_CPU_FREQ_STAT=y CONFIG_CPU_FREQ_STAT_DETAILS=y CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=y CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y CONFIG_CPU_FREQ_PMAC=y CONFIG_TAU=y # # Kernel options # CONFIG_HZ_1000=y CONFIG_HZ=1000 CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_BINFMT_ELF=y CONFIG_HOTPLUG_CPU=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_KEXEC=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_ADAPTIVE_READAHEAD=y CONFIG_DEBUG_READAHEAD=y CONFIG_PROC_DEVICETREE=y CONFIG_PM=y CONFIG_PM_DEBUG=y CONFIG_PM_SYSFS_DEPRECATED=y CONFIG_SECCOMP=y CONFIG_ISA_DMA_API=y # # Bus options # CONFIG_ISA=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_PPC_INDIRECT_PCI=y CONFIG_PCI=y CONFIG_PCI_DOMAINS=y CONFIG_PCIEPORTBUS=y CONFIG_PCCARD=y CONFIG_PCMCIA=y CONFIG_PCMCIA_LOAD_CIS=y CONFIG_CARDBUS=y # # PC-card bridges # CONFIG_PCMCIA_PROBE=y # # Advanced setup # # # Default settings for advanced configuration options are used # CONFIG_HIGHMEM_START=0xfe00 CONFIG_LOWMEM_SIZE=0x3000 CONFIG_KERNEL_START=0xc000 CONFIG_TASK_SIZE=0x8000 CONFIG_BOOT_L
Re: High Resolution Timer DOS
On Sat, 28 Apr 2007, Lee Revell wrote: On 4/28/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote: Well, it is not really a DoS. The rescheduling of the process is limited by the scheduler and the available CPU time (depending on the number of runnable tasks in the system). Shouldn't an unprivileged process be rate limited somehow to avoid flooding the machine with interrupts? We restrict nonroot users from setting the RTC interrupt rate higher than 64Hz for a similar reason (granted, this limit dates back to the 486 days and should probably be increased to 1024 Hz). Isn't that what /etc/security/limits.conf is for? Just limit the CPU usage. Root and SCHED_FIFO tasks could be exempt from rate limiting, to avoid the need to introduce a new rlimit which would take years for userspace to catch up to. Lee William Heimbigner [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PANIC: 2.6.21-rc7-mm2, Kernel access of bad area, sig: 11
On Sat, 28 Apr 2007, Andrew Morton wrote: On Sat, 28 Apr 2007 21:40:19 + (GMT) William Heimbigner <[EMAIL PROTECTED]> wrote: This bug occurs in linux-2.6.21-rc7-mm2, and does not occur in 2.6.21-rc7 ARCH is powerpc dmesg output, captured via netconsole: [0.00] Using PowerMac machine description [0.00] Total memory = 128MB; using 256kB for hash table (at c7fc) [0.00] Linux version 2.6.21-rc7-mm2 ([EMAIL PROTECTED]) (gcc version 4.1.1 (Gentoo 4.1.1-r3)) #3 SMP PREEMPT Sat Apr 28 14:29:54 CDT 2007 [0.00] Found UniNorth memory controller & host bridge @ 0xf800 revision: 0xc0 [0.00] Mapped at 0xfdfc [0.00] Found a Pangea mac-io controller, rev: 0, mapped at 0xfdf4 [0.00] PowerMac motherboard: iMac "Flower Power" It ran OK on my G5. Can you send the config please? grep -v "is not set" .config: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc7-mm2 # Sat Apr 28 14:04:08 2007 # CONFIG_PPC_PM_NEEDS_RTC_LIB=y CONFIG_PPC32=y CONFIG_PPC_MERGE=y CONFIG_MMU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_IRQ_PER_CPU=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_PPC_UDBG_16550=y CONFIG_GENERIC_TBSYNC=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # # Processor support # CONFIG_CLASSIC32=y CONFIG_6xx=y CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_32=y CONFIG_SMP=y CONFIG_NR_CPUS=2 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SWAP_PREFETCH=y CONFIG_SYSVIPC=y CONFIG_IPC_NS=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_SYSFS_DEPRECATED=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y 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_PROC_SMAPS=y CONFIG_PROC_CLEAR_REFS=y CONFIG_PROC_PAGEMAP=y CONFIG_PROC_KPAGEMAP=y CONFIG_SLUB=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Block layer # CONFIG_BLOCK=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_CFQ=y CONFIG_DEFAULT_IOSCHED="cfq" # # Platform support # CONFIG_PPC_MULTIPLATFORM=y CONFIG_PPC_CHRP=y CONFIG_PPC_PMAC=y CONFIG_PPC_NATIVE=y CONFIG_MPIC=y CONFIG_PPC_I8259=y CONFIG_PPC_RTAS=y CONFIG_RTAS_PROC=y CONFIG_PPC_MPC106=y # # CPU Frequency support # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y CONFIG_CPU_FREQ_STAT=y CONFIG_CPU_FREQ_STAT_DETAILS=y CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=y CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y CONFIG_CPU_FREQ_PMAC=y CONFIG_TAU=y # # Kernel options # CONFIG_HZ_1000=y CONFIG_HZ=1000 CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_BINFMT_ELF=y CONFIG_HOTPLUG_CPU=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_KEXEC=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_ADAPTIVE_READAHEAD=y CONFIG_DEBUG_READAHEAD=y CONFIG_PROC_DEVICETREE=y CONFIG_PM=y CONFIG_PM_DEBUG=y CONFIG_PM_SYSFS_DEPRECATED=y CONFIG_SECCOMP=y CONFIG_ISA_DMA_API=y # # Bus options # CONFIG_ISA=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_PPC_INDIRECT_PCI=y CONFIG_PCI=y CONFIG_PCI_DOMAINS=y CONFIG_PCIEPORTBUS=y CONFIG_PCCARD=y CONFIG_PCMCIA=y CONFIG_PCMCIA_LOAD_CIS=y CONFIG_CARDBUS=y # # PC-card bridges # CONFIG_PCMCIA_PROBE=y # # Advanced setup # # # Default settings for advanced configuration options are used # CONFIG_HIGHMEM_START=0xfe00 CONFIG_LOWMEM_SIZE=0x3000 CONFIG_KERNEL_START=0xc000 CONFIG_TASK_SIZE=0x8000 CONFIG_BOOT_LOAD=0x0080 # # Networking # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_XFRM=y CONFIG_XFRM_USER=y CONFIG_NET_KEY=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_FIB_HASH=y C
PANIC: 2.6.21-rc7-mm2, Kernel access of bad area, sig: 11
.167892] REGS: c0583a40 TRAP: 0300 Not tainted (2.6.21-rc7-mm2) [ 156.168118] MSR: 1032 CR: 42202022 XER: [ 156.168467] DAR: , DSISR: 4200 [ 156.168617] TASK = c0550260[0] 'swapper' THREAD: c0582000 CPU: 0 [ 156.168840] GPR00: c0583af0 c0550260 0783 c059bc88 0001 c0488ec0 c059bc80 [ 156.169272] GPR08: c0460713 c0488e77 c0488b70 3da3 0023f96c c059 [ 156.169705] GPR16: c059 0023f964 c059 1032 c0583eb0 c059 [ 156.170145] GPR24: c0583b18 c0583b28 c000a1e4 c0583b2c c059bc80 [ 156.170594] NIP [c0068ce4] kallsyms_lookup+0x64/0xa4 [ 156.170806] LR [c0068cdc] kallsyms_lookup+0x5c/0xa4 [ 156.170997] Call Trace: [ 156.171093] [c0583af0] [c0068cb4] kallsyms_lookup+0x34/0xa4 (unreliable) [ 156.171384] --- Exception: c0583bb0 at 0xc0583ba0 [ 156.171578] LR = draw_byte+0x34/0x1d0 [ 156.171723] [c0583b10] [c002ebd0] xmon_show_stack+0x2b8/0x330 (unreliable) [ 156.172017] [c0583c10] [c003053c] cmds+0xa20/0x1600 [ 156.172235] [c0583ca0] [c0031448] xmon_core+0x32c/0x734 [ 156.172452] [c0583d60] [c00319fc] xmon+0x2c/0x68 [ 156.172647] [c0583e20] [c0031b40] xmon_irq+0x50/0x6c [ 156.172856] [c0583e40] [c0073828] handle_IRQ_event+0x5c/0xb0 [ 156.173090] [c0583e60] [c00755dc] handle_fasteoi_irq+0xac/0x174 [ 156.17] [c0583e80] [c0006be4] do_IRQ+0xec/0x130 [ 156.179644] [c0583ea0] [c0014fe8] ret_from_except+0x0/0x14 [ 156.185827] --- Exception: 501 at cpu_idle+0xfc/0x1dc LR = cpu_idle+0xfc/0x1dc [c0583f60] [c000a24c] cpu_idle+0x164/0x1dc (unreliable) [c0583f80] [c0003cc4] rest_init+0x74/0x88 [c0583fa0] [c050fb68] start_kernel+0x310/0x394 [c0583ff0] [37b4] 0x37b4 This occurs after pressing the programmer switch to generate an NMI. William Heimbigner [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] cpufreq: allow full selection of default governors
On Fri, 27 Apr 2007, Gautham Shenoy wrote: On 4/27/07, Dominik Brodowski <[EMAIL PROTECTED]> wrote: On Fri, Apr 27, 2007 at 02:09:57AM -0400, Dave Jones wrote: > On Thu, Apr 26, 2007 at 09:54:10PM -0400, Dominik Brodowski wrote: > > On Tue, Apr 24, 2007 at 08:03:27PM -0400, Dave Jones wrote: > > > On Tue, Apr 24, 2007 at 03:05:36PM -0700, Nish Aravamudan wrote: > > > > On 4/24/07, Dave Jones <[EMAIL PROTECTED]> wrote: > > > > > On Tue, Apr 24, 2007 at 09:03:23PM +, William Heimbigner > > > > > wrote: > > > > > > The following patches should allow selection of conservative, > > > > > > powersave, and > > > > > > ondemand in the kernel configuration. > > > > > > > > > > This has been rejected several times already. > > > > > Ondemand and conservative isn't a viable governor for all > > > > > cpufreq > > > > > implementations (ie, ones with high switching latencies). > > > > > > > > This piques my curiosity -- some governors don't work with some > > > > cpufreq implementations. Are those implementations in the kernel > > > > or in > > > > userspace? If in the kernel, then perhaps there should be some > > > > dependency expressed there in Kconfig between cpufreq > > > > implementation > > > > and the available governors > > > > > > it can't be solved that easily. powernow-k8 for example is fine to > > > use with ondemand on newer systems, where the latency is low. > > > On older models however, it isn't. > > > > > > > > Also, see the > > > > > comment in the Kconfig a few lines above where you are adding > > > > > this. > > > > > > > > Are these governors unfixable? If > > > > > > tbh, I've forgotten the original issues that caused the comment > > > to be placed there. Dominik ? > > > > Not unfixable, but: cpufreq is currently[*] built around the > > assumption that > > at least one governor is correctly initialized or can be brought to > > work > > when a CPU is registered with the cpufreq core. > > It would have to take something fairly spectacular though for > performance or > powersave to fail registration. Can you remember why we chose not to > allow those? performance _is_ allowed; powersave would be possible -- but then those who accidentally enable it on elanfreq might wait 100 times as long for the system to boot, with gx-suspmod it might even be 255 times as long -- okay, by default it's just 20 times as long, but still... I agree! Let a stable governor like performance or userspace be the default to get the cpufreq up and running during boot up, and later on have some init script switch to a preferred governor like powersave/ondemand/conservative. Changing governor is just a matter of loading the appropriate module and echoing the appropriate value into /sys/devices/*/cpufreq/scaling_governor. Hardly takes any time. William, Is there a specific reason why you would want powersave/ondemand/conservative to be activate during the system boot up? Specific reason: Powersave would be useful for preserving battery life / keeping the CPU cool. Secondary reason: Is there any reason why powersave would be any more problematic than performance? What about conservative? Would that be problematic? It's been explained that ondemand could be problematic in computers which don't support low-latency transitions, but conservative fixes that. If performance sends a command to cpufreq to use the highest frequency, and powersave sends a command to cpufreq to use the lowest frequency, can someone explain to me how performance can possibly safer than powersave? William Heimbigner [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] cpufreq: allow full selection of default governors
On Fri, 27 Apr 2007, Dominik Brodowski wrote: On Fri, Apr 27, 2007 at 02:09:57AM -0400, Dave Jones wrote: On Thu, Apr 26, 2007 at 09:54:10PM -0400, Dominik Brodowski wrote: > On Tue, Apr 24, 2007 at 08:03:27PM -0400, Dave Jones wrote: >> On Tue, Apr 24, 2007 at 03:05:36PM -0700, Nish Aravamudan wrote: >> > On 4/24/07, Dave Jones <[EMAIL PROTECTED]> wrote: >> >> On Tue, Apr 24, 2007 at 09:03:23PM +, William Heimbigner wrote: >> >> > The following patches should allow selection of conservative, powersave, and >> >> > ondemand in the kernel configuration. >> >> >> >> This has been rejected several times already. >> >> Ondemand and conservative isn't a viable governor for all cpufreq >> >> implementations (ie, ones with high switching latencies). >> > >> > This piques my curiosity -- some governors don't work with some >> > cpufreq implementations. Are those implementations in the kernel or in >> > userspace? If in the kernel, then perhaps there should be some >> > dependency expressed there in Kconfig between cpufreq implementation >> > and the available governors >> >> it can't be solved that easily. powernow-k8 for example is fine to >> use with ondemand on newer systems, where the latency is low. >> On older models however, it isn't. >> >> >> Also, see the >> >> comment in the Kconfig a few lines above where you are adding this. >> > >> > Are these governors unfixable? If >> >> tbh, I've forgotten the original issues that caused the comment >> to be placed there. Dominik ? > > Not unfixable, but: cpufreq is currently[*] built around the assumption that > at least one governor is correctly initialized or can be brought to work > when a CPU is registered with the cpufreq core. It would have to take something fairly spectacular though for performance or powersave to fail registration. Can you remember why we chose not to allow those? performance _is_ allowed; powersave would be possible -- but then those who accidentally enable it on elanfreq might wait 100 times as long for the system to boot, with gx-suspmod it might even be 255 times as long -- okay, by default it's just 20 times as long, but still... Dominik People should be smart enough to realize what "powersave" would imply... or at least read the help for it; again, we wouldn't have the "default default governor" be powersave, it would be performance, and they could choose powersave if they wanted to. Also, what of the conservative governor? I understand now some of the problems that could arise with ondemand, but conservative doesn't rely on low-latency transitions, and seems no riskier than performance or powersave. In fact, conservative would probably be the most useful default governor available for a laptop system. For now, I propose allowing a default governor of powersave; allowing conservative while being tagged experimental, and possibly, but not likely, allowing ondemand, tagged as experimental. William Heimbigner [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-2.6.21-rc7-mm2 fails to compile
Output leading up to the error: CC drivers/macintosh/macio-adb.o LD drivers/macintosh/built-in.o CC [M] drivers/macintosh/apm_emu.o CC [M] drivers/macintosh/therm_windtunnel.o drivers/macintosh/therm_windtunnel.c: In function 'therm_of_remove': drivers/macintosh/therm_windtunnel.c:462: error: void value not ignored as it ought to be drivers/macintosh/therm_windtunnel.c:463: warning: control reaches end of non-void function make[2]: *** [drivers/macintosh/therm_windtunnel.o] Error 1 make[1]: *** [drivers/macintosh] Error 2 make: *** [drivers] Error 2 This is on an iMac G3 powerpc. William Heimbigner [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Question re config_cmdline
I noticed that many of the architectures have support for CONFIG_CMDLINE (which allows for the configuration of a default kernel command lines), however, x86 doesn't. Is this intentional, and if so, why? It seems to me that a built in command line would be architecture-independent. William Heimbigner [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Null pointer dereference in fs/open.c
On Wed, 25 Apr 2007, Andrew Morton wrote:
On Wed, 25 Apr 2007 22:53:00 + (GMT) William Heimbigner <[EMAIL PROTECTED]>
wrote:
On Wed, 25 Apr 2007, Andrew Morton wrote:
OK. I am able to use the pktcdvd driver OK in mainline with a piix/sata
drive. It could be that something is going wrong at the IDE level for you.
Perhaps; I'll try an external usb cd burner, and see where that goes.
Are you able to identify the most recent kernel which actually worked?
No, because I haven't set packet writing up in Linux before - however, I do know
that I've successfully set up packet writing (using 2 of the 3 cd burners I
have) in another operating system before. I'll try 2.6.18 and see if that gets
me anywhere different, though.
OK.
A quick summary: mainline's pktcdvd isn't working for William using IDE.
It is working for me using sata.
So what has happened here is that this code, in ide-cd.c's
cdrom_decode_status() is now triggering:
} else if (blk_pc_request(rq) || rq->cmd_type == REQ_TYPE_ATA_PC) {
/* All other functions, except for READ. */
unsigned long flags;
/*
* if we have an error, pass back CHECK_CONDITION as the
* scsi status byte
*/
if (blk_pc_request(rq) && !rq->errors)
rq->errors = SAM_STAT_CHECK_CONDITION;
I suspect this is a bug introduced by
406c9b605cbc45151c03ac9a3f95e9acf050808c (in which case it'll be the third
bug so far).
Perhaps the IDE driver was previously not considering these requests to be
of type blk_pc_request(), and after
406c9b605cbc45151c03ac9a3f95e9acf050808c it _is_ treating them as
blk_pc_request() and is incorrectly reporting an error. Or something like
that.
Guys: help!
A follow-up: after looking around a bit, I have managed to get packet writing to
work properly on /dev/hdc (before, it was reporting only 1.8 MB available or so;
this was a formatting issue).
I've also gotten the external cd-rw drive to work. However, I'm still at a loss
as to why /dev/hdd won't work. I tried formatting a dvd-rw for this drive,
however, it consistently gives me:
[27342.503933] drivers/ide/ide-cd.c:729: setting error to 2
[27342.509251] [] show_trace_log_lvl+0x1a/0x30
[27342.514411] [] show_trace+0x12/0x20
[27342.518864] [] dump_stack+0x16/0x20
[27342.523317] [] cdrom_decode_status+0x1f4/0x3b0
[27342.528732] [] cdrom_newpc_intr+0x38/0x320
[27342.533791] [] ide_intr+0x96/0x200
[27342.538157] [] handle_IRQ_event+0x28/0x60
[27342.543139] [] handle_edge_irq+0xa6/0x130
[27342.548121] [] do_IRQ+0x49/0xa0
[27342.552228] [] common_interrupt+0x2e/0x34
[27342.557200] [] mwait_idle+0x12/0x20
[27342.561653] [] cpu_idle+0x4a/0x80
[27342.565934] [] rest_init+0x37/0x40
[27342.570300] [] start_kernel+0x34b/0x420
[27342.575109] [<>] 0x0
[27342.578089] ===
and doesn't work (the above output was generated by Andrew's patch to log
certain areas).
# dvd+rw-format /dev/hdd -force
* BD/DVDRW/-RAM format utility by <[EMAIL PROTECTED]>, version 7.0.
:-( failed to locate "Quick Format" descriptor.
* 4.7GB DVD-RW media in Sequential mode detected.
* formatting 0.0\:-[ READ TRACK INFORMATION failed with SK=3h/ASC=11h/ACQ=05h]:
Input/output error
I tried putting in a different dvd-rw, and this time I get:
# dvd+rw-format /dev/hdd -force
* BD/DVDRW/-RAM format utility by <[EMAIL PROTECTED]>, version 7.0.
* 4.7GB DVD-RW media in Sequential mode detected.
* formatting 0.0|:-[ FORMAT UNIT failed with SK=5h/ASC=26h/ACQ=00h]:
Input/output error
William Heimbigner
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: mm snapshot broken-out-2007-04-25-02-49.tar.gz uploaded
On Wed, 25 Apr 2007, [EMAIL PROTECTED] wrote: The mm snapshot broken-out-2007-04-25-02-49.tar.gz has been uploaded to ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-04-25-02-49.tar.gz Was support for UnionFS deliberately removed in this release? William Heimbigner [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Reasons to merge suspend2.
On Wed, 25 Apr 2007, Pavel Machek wrote: Hi! I didn't read your whole post, it's way too long, but I would like to see your patch in mainline as an option to swsusp. What would make this infeasible? For one thing, Linus said not but yesterday that he doesn't want multiple competing suspend algorithms like this in the kernel at once. (If I parsed his message correctly, he doesn't want any in the kernel, but he's putting up with it because it seems somewhat needed.) Would it be a feasible solution to have a very minimal and generic software suspend in the kernel, and then various userspace implementations could take care of this? Yes please. If you want suspend-over-nfs or whatever, just add it to the userspace; we have enough support in kernel now. Pavel That seems like a rather asinine idea to implement. I think you misread my question - there are some things that have to be done at the kernel level, such as when the entire memory has to be written, but are there portions of the existing code, or portions of Suspend2, that could be done in userspace? If so, you could have a generic suspend mechanism in the kernel, and then various other things done in userspace. William Heimbigner [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Reasons to merge suspend2.
On Wed, 25 Apr 2007, John Anthony Kazos Jr. wrote: I didn't read your whole post, it's way too long, but I would like to see your patch in mainline as an option to swsusp. What would make this infeasible? For one thing, Linus said not but yesterday that he doesn't want multiple competing suspend algorithms like this in the kernel at once. (If I parsed his message correctly, he doesn't want any in the kernel, but he's putting up with it because it seems somewhat needed.) Would it be a feasible solution to have a very minimal and generic software suspend in the kernel, and then various userspace implementations could take care of this? Or is all of the software suspend code in the kernel absolutely necessary, such that this wouldn't work? William Heimbigner [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] [PATCH] cpufreq: allow full selection of default governors
On Tue, 24 Apr 2007, Dave Jones wrote: On Tue, Apr 24, 2007 at 09:03:23PM +, William Heimbigner wrote: > The following patches should allow selection of conservative, powersave, and > ondemand in the kernel configuration. This has been rejected several times already. Ondemand and conservative isn't a viable governor for all cpufreq implementations (ie, ones with high switching latencies). Also, see the comment in the Kconfig a few lines above where you are adding this. Dave It may be wise to disable the selection of ondemand, however, conservative was designed to fix the very problem created by ondemand (the need for high switching latencies), and this also says nothing about powersave. Additionally, it seems odd that the kernel would be left in an undefined state if a governor failed to initalize - rather, shouldn't the governor fail in such a way as to not cause errors? William Heimbigner [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] [PATCH] cpufreq: allow full selection of default governors
The following patches should allow selection of conservative, powersave, and
ondemand in the kernel configuration.
William Heimbigner
[EMAIL PROTECTED]
diff -uprN -X linux-2.6.21-rc7-git6/Documentation/dontdiff
linux-2.6.21-rc7-git6/drivers/cpufreq/Kconfig
linux-2.6.21-rc7-git6-hwill/drivers/cpufreq/Kconfig
--- linux-2.6.21-rc7-git6/drivers/cpufreq/Kconfig 2007-04-25
13:03:41.0 -0500
+++ linux-2.6.21-rc7-git6-hwill/drivers/cpufreq/Kconfig 2007-04-25
13:08:13.0 -0500
@@ -75,6 +75,24 @@ config CPU_FREQ_DEFAULT_GOV_USERSPACE
program shall be able to set the CPU dynamically without having
to enable the userspace governor manually.
+config CPU_FREQ_DEFAULT_GOV_POWERSAVE
+ bool "powersave"
+ select CPU_FREQ_GOV_POWERSAVE
+ help
+ Use the CPUFreq governor 'powersave' as default.
+
+config CPU_FREQ_DEFAULT_GOV_CONSERVATIVE
+ bool "conservative"
+ select CPU_FREQ_GOV_CONSERVATIVE
+ help
+ Use the CPUFreq governor 'conservative' as the default.
+
+config CPU_FREQ_DEFAULT_GOV_ONDEMAND
+ bool "ondemand"
+ select CPU_FREQ_GOV_ONDEMAND
+ help
+ Use the CPUFreq governor 'ondemand' as the default.
+
endchoice
config CPU_FREQ_GOV_PERFORMANCE
diff -uprN -X linux-2.6.21-rc7-git6/Documentation/dontdiff
linux-2.6.21-rc7-git6/drivers/cpufreq/cpufreq_conservative.c
linux-2.6.21-rc7-git6-hwill/drivers/cpufreq/cpufreq_conservative.c
--- linux-2.6.21-rc7-git6/drivers/cpufreq/cpufreq_conservative.c
2007-04-25 13:03:41.0 -0500
+++ linux-2.6.21-rc7-git6-hwill/drivers/cpufreq/cpufreq_conservative.c
2007-04-25 09:54:58.0 -0500
@@ -551,7 +551,7 @@ static int cpufreq_governor_dbs(struct c
return 0;
}
-static struct cpufreq_governor cpufreq_gov_dbs = {
+struct cpufreq_governor cpufreq_gov_conservative = {
.name = "conservative",
.governor = cpufreq_governor_dbs,
.owner = THIS_MODULE,
@@ -559,7 +559,7 @@ static struct cpufreq_governor cpufreq_g
static int __init cpufreq_gov_dbs_init(void)
{
- return cpufreq_register_governor(&cpufreq_gov_dbs);
+ return cpufreq_register_governor(&cpufreq_gov_conservative);
}
static void __exit cpufreq_gov_dbs_exit(void)
@@ -567,7 +567,7 @@ static void __exit cpufreq_gov_dbs_exit(
/* Make sure that the scheduled work is indeed not running */
flush_scheduled_work();
- cpufreq_unregister_governor(&cpufreq_gov_dbs);
+ cpufreq_unregister_governor(&cpufreq_gov_conservative);
}
diff -uprN -X linux-2.6.21-rc7-git6/Documentation/dontdiff
linux-2.6.21-rc7-git6/drivers/cpufreq/cpufreq_ondemand.c
linux-2.6.21-rc7-git6-hwill/drivers/cpufreq/cpufreq_ondemand.c
--- linux-2.6.21-rc7-git6/drivers/cpufreq/cpufreq_ondemand.c2007-04-25
13:03:41.0 -0500
+++ linux-2.6.21-rc7-git6-hwill/drivers/cpufreq/cpufreq_ondemand.c
2007-04-25 13:17:00.0 -0500
@@ -573,7 +573,7 @@ static int cpufreq_governor_dbs(struct c
return 0;
}
-static struct cpufreq_governor cpufreq_gov_dbs = {
+struct cpufreq_governor cpufreq_gov_ondemand = {
.name = "ondemand",
.governor = cpufreq_governor_dbs,
.owner = THIS_MODULE,
@@ -586,12 +586,12 @@ static int __init cpufreq_gov_dbs_init(v
printk(KERN_ERR "Creation of kondemand failed\n");
return -EFAULT;
}
- return cpufreq_register_governor(&cpufreq_gov_dbs);
+ return cpufreq_register_governor(&cpufreq_gov_ondemand);
}
static void __exit cpufreq_gov_dbs_exit(void)
{
- cpufreq_unregister_governor(&cpufreq_gov_dbs);
+ cpufreq_unregister_governor(&cpufreq_gov_ondemand);
destroy_workqueue(kondemand_wq);
}
diff -uprN -X linux-2.6.21-rc7-git6/Documentation/dontdiff
linux-2.6.21-rc7-git6/drivers/cpufreq/cpufreq_powersave.c
linux-2.6.21-rc7-git6-hwill/drivers/cpufreq/cpufreq_powersave.c
--- linux-2.6.21-rc7-git6/drivers/cpufreq/cpufreq_powersave.c 2007-02-04
12:44:54.0 -0600
+++ linux-2.6.21-rc7-git6-hwill/drivers/cpufreq/cpufreq_powersave.c
2007-04-25 08:51:03.0 -0500
@@ -35,7 +35,7 @@ static int cpufreq_governor_powersave(st
return 0;
}
-static struct cpufreq_governor cpufreq_gov_powersave = {
+struct cpufreq_governor cpufreq_gov_powersave = {
.name = "powersave",
.governor = cpufreq_governor_powersave,
.owner = THIS_MODULE,
diff -uprN -X linux-2.6.21-rc7-git6/Documentation/dontdiff
linux-2.6.21-rc7-git6/include/linux/cpufreq.h
linux-2.6.21-rc7-git6-hwill/include/linux/cpufreq.h
--- linux-2.6.21-rc7-git6/include/linux/cpufreq.h 2007-04-25
13:04:00.0 -0500
+++ linux-2.6.21-rc7-git6-hwill/include/linux/cpufreq.h 2007-04-25
13:10:26.0 -0500
@@ -286,6 +286,15 @@ extern struct cp
Re: cpufreq default governor
On Tue, 24 Apr 2007, Michal Piotrowski wrote: On 24/04/07, William Heimbigner <[EMAIL PROTECTED]> wrote: On Tue, 24 Apr 2007, Michal Piotrowski wrote: > On 24/04/07, William Heimbigner <[EMAIL PROTECTED]> wrote: > > On Tue, 24 Apr 2007, Michal Piotrowski wrote: > > > > > Hi William, > > > > > > On 24/04/07, William Heimbigner <[EMAIL PROTECTED]> wrote: > > > >Question: is there some reason that kconfig does not allow for > > > >default > > > >governors of conservative/ondemand/powersave? > > > > > > Performance? > > > > > > >I'm not aware of any reason why one of those governors could not > > > >be > > > >used > > > >as default. > > > > > > My hardware doesn't work properly with ondemand governor. I hear > > > strange noises when frequency is changed. > > > > > > > That doesn't mean it isn't working, though. > > I didn't say that cpufreq ondemand is broken. It's a hardware problem. > > > I here weird noises if the cpu > > is clocked anywhere from 333MHz to 1GHz (sounds like an RD-D2 beeping > > noises in ultra high pitch?) > > Yes, something like that. Is it actually "not working" though, even at the hardware level? It works, but for me this sounds are very weird ;) To my knowledge those noises are normal, and aren't even signs of a harware problem. I believe it is the natural result of changing frequencies at any time. If you change frequencies, especially in the low end of available frequencies, you should hear a very brief noise. A governor such as ondemand, which is rapidly switching the frequency from say, 333 MHz to 2.66 GHz, is likely to make this much more noticable. Ok, it might be normal behavior. I might be wrong, but IMO users prefer speed and no strange sounds as default setting. I agree! My suggestion, however, is that if they do want a different scheduler as the default, they can choose one. There are some cases in which this could be very useful. A couple examples would be the processor with poor cooling that overheats easily, or a laptop with a poor battery. However, on second thought with regards to Kconfig, would it be feasible to have performance always be the default, unless a "cpufreqgov=conservative" arguement was specified on the command line? This would be less susceptible to users complaining that their cpu is chirping all of a sudden. William Heimbigner [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq default governor
On Tue, 24 Apr 2007, Michal Piotrowski wrote: On 24/04/07, William Heimbigner <[EMAIL PROTECTED]> wrote: On Tue, 24 Apr 2007, Michal Piotrowski wrote: > Hi William, > > On 24/04/07, William Heimbigner <[EMAIL PROTECTED]> wrote: > > Question: is there some reason that kconfig does not allow for > > default > > governors of conservative/ondemand/powersave? > > Performance? > > > I'm not aware of any reason why one of those governors could not be > > used > > as default. > > My hardware doesn't work properly with ondemand governor. I hear > strange noises when frequency is changed. > That doesn't mean it isn't working, though. I didn't say that cpufreq ondemand is broken. It's a hardware problem. I here weird noises if the cpu is clocked anywhere from 333MHz to 1GHz (sounds like an RD-D2 beeping noises in ultra high pitch?) Yes, something like that. Is it actually "not working" though, even at the hardware level? To my knowledge those noises are normal, and aren't even signs of a harware problem. I believe it is the natural result of changing frequencies at any time. If you change frequencies, especially in the low end of available frequencies, you should hear a very brief noise. A governor such as ondemand, which is rapidly switching the frequency from say, 333 MHz to 2.66 GHz, is likely to make this much more noticable. William Heimbigner [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq default governor
On Tue, 24 Apr 2007, Michal Piotrowski wrote: Hi William, On 24/04/07, William Heimbigner <[EMAIL PROTECTED]> wrote: Question: is there some reason that kconfig does not allow for default governors of conservative/ondemand/powersave? Performance? I'm not aware of any reason why one of those governors could not be used as default. My hardware doesn't work properly with ondemand governor. I hear strange noises when frequency is changed. That doesn't mean it isn't working, though. I here weird noises if the cpu is clocked anywhere from 333MHz to 1GHz (sounds like an RD-D2 beeping noises in ultra high pitch?) William Heimbigner [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
cpufreq default governor
Question: is there some reason that kconfig does not allow for default governors of conservative/ondemand/powersave? I'm not aware of any reason why one of those governors could not be used as default. William Heimbigner [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NonExecutable Bit in 32Bit
On Tue, 24 Apr 2007, Cestonaro, Thilo (external) wrote: Hey, is it right, that the NX Bit is not used under i386-Arch but under x86_64-Arch? When yes, is there a special argument for it not to be used? Ciao Thilo I don't think so - some i386 cpus definitely have support for the NX bit. Would having this be supported in i386 help debugging (and security) significantly? William Heimbigner [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Null pointer dereference in fs/open.c
On Mon, 23 Apr 2007, Andrew Morton wrote:
On Tue, 24 Apr 2007 05:10:04 + (GMT) William Heimbigner <[EMAIL PROTECTED]>
wrote:
--- a/drivers/block/pktcdvd.c~packet-fix-error-handling
+++ a/drivers/block/pktcdvd.c
@@ -777,7 +777,8 @@ static int pkt_generic_packet(struct pkt
rq->cmd_flags |= REQ_QUIET;
blk_execute_rq(rq->q, pd->bdev->bd_disk, rq, 0);
- ret = rq->errors;
+ if (rq->errors)
+ ret = -EIO;
out:
blk_put_request(rq);
return ret;
_
This patch fixes (or conceals?) the oops.
Fixes. But does the packet driver actually work OK for you? Writes
files and stuff like that?
Short answer, no.
Long answer:
# pktsetup 0 /dev/hdc
[11508.006818] =
[11508.028248] [ INFO: possible recursive locking detected ]
[11508.044413] 2.6.21-rc7-git5 #23
[11508.053818] -
[11508.069989] vol_id/4315 is trying to acquire lock:
[11508.084332] (&bdev->bd_mutex){--..}, at: []
do_open+0x4f/0x2c0
[11508.104867]
[11508.104868] but task is already holding lock:
[11508.122359] (&bdev->bd_mutex){--..}, at: []
do_open+0x4f/0x2c0
[11508.142862]
[11508.142863] other info that might help us debug this:
[11508.162460] 2 locks held by vol_id/4315:
[11508.174212] #0: (&bdev->bd_mutex){--..}, at: []
do_open+0x4f/0x2c0
[11508.196066] #1: (&ctl_mutex#2){--..}, at: []
mutex_lock+0x1c/0x20
[11508.217720]
[11508.217721] stack backtrace:
[11508.230821] [] show_trace_log_lvl+0x1a/0x30
[11508.246255] [] show_trace+0x12/0x20
[11508.259619] [] dump_stack+0x16/0x20
[11508.272974] [] __lock_acquire+0xbc0/0x1040
[11508.288157] [] lock_acquire+0x70/0x90
[11508.302035] [] mutex_lock_nested+0x7e/0x2e0
[11508.317475] [] do_open+0x4f/0x2c0
[11508.330314] [] __blkdev_get+0x79/0x90
[11508.344189] [] blkdev_get+0x15/0x20
[11508.357554] [] pkt_open+0xb7/0xd80
[11508.370651] [] do_open+0x85/0x2c0
[11508.383491] [] blkdev_open+0x33/0x70
[11508.397107] [] __dentry_open+0xf4/0x220
[11508.411509] [] nameidata_to_filp+0x35/0x40
[11508.426684] [] do_filp_open+0x49/0x50
[11508.440567] [] do_sys_open+0x47/0xd0
[11508.454188] [] sys_open+0x1c/0x20
[11508.467023] [] sysenter_past_esp+0x5f/0x99
[11508.482202] ===
[11508.520800] pktcdvd: pkt_get_last_written failed
# mkudffs /dev/pktcdvd/0
[11539.953560] pktcdvd: pkt_get_last_written failed
trying to change type of multiple extents
I get the same error with /dev/hdd as well (hdc and hdd are both dvd
burners, hdd has a cd-rw and hdc had a dvd-rw)
William Heimbigner
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Null pointer dereference in fs/open.c
On Mon, 23 Apr 2007, Andrew Morton wrote:
On Tue, 24 Apr 2007 04:09:18 + (GMT) William Heimbigner <[EMAIL PROTECTED]>
wrote:
This bug occurs in linux-2.6.20 and 2.6.21-rc7-git5, and does not occur in
linux-2.6.19-git22.
After running "pktsetup 0 /dev/hdd", I get (timestamps removed):
pktcdvd: pkt_get_last_written failed
BUG: unable to handle kernel NULL pointer dereference at virtual address
000e
printing eip:
c0173f69
*pde =
Oops: [#1]
PREEMPT
Modules linked in: snd_ca0106 snd_ac97_codec ac97_bus 8139cp 8139too iTCO_wdt
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010203 (2.6.21-rc7-git5 #22)
EIP is at do_sys_open+0x59/0xd0
eax: 0002 ebx: 4020 ecx: 0001 edx: 0002
esi: df1e3000 edi: 0003 ebp: de17bfa4 esp: de17bf84
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process vol_id (pid: 4273, ti=de17b000 task=df4143f0 task.ti=de17b000)
Stack: c013d2a5 ff9c 0002 c059cea3 bfb6bf64 8000 b7f60ff4
de17bfb0 c017401c de17b000 c01041c6 bfb6bf64 8000
8000 b7f60ff4 bfb6a798 0005 007b 007b 0005
Call Trace:
[] show_trace_log_lvl+0x1a/0x30
[] show_stack_log_lvl+0xa9/0xd0
[] show_registers+0x21c/0x3a0
[] die+0x104/0x260
[] do_page_fault+0x277/0x610
[] error_code+0x74/0x7c
[] sys_open+0x1c/0x20
[] sysenter_past_esp+0x5f/0x99
===
Code: ff 85 c0 89 c7 78 77 8b 45 08 89 d9 89 f2 89 04 24 8b 45 e8 e8 69 ff
ff ff 3d 00 f0 ff ff 89 45 ec 77 71 8b 55 ec bb 20 00 00 40 <8b> 42 0c 8b
48 30 89 4d f0 0f b7 51 66 81 e2 00 f0 00 00 81 fa
EIP: [] do_sys_open+0x59/0xd0 SS:ESP 0068:de17bf84
Try this:
--- a/drivers/block/pktcdvd.c~packet-fix-error-handling
+++ a/drivers/block/pktcdvd.c
@@ -777,7 +777,8 @@ static int pkt_generic_packet(struct pkt
rq->cmd_flags |= REQ_QUIET;
blk_execute_rq(rq->q, pd->bdev->bd_disk, rq, 0);
- ret = rq->errors;
+ if (rq->errors)
+ ret = -EIO;
out:
blk_put_request(rq);
return ret;
_
This patch fixes (or conceals?) the oops.
The packet driver was assuming that request.errors is an errno, but it
isn't - it's some sort of diagnostic bitfield thing. Now why would the
packet driver have though that? Let's go read the comments:
unsigned short nr_hw_segments;
unsigned short ioprio;
void *special;
char *buffer;
int tag;
int errors;
int ref_count;
Well there's your root cause right there.
I don't know why this wasn't oopsing in eariler kernels. Perhaps something
else is broken. Please test this urgently.
There's a locking problem in there too. `pktsetup 0 /dev/scd0' gives me
[ 77.72] pktcdvd: writer pktcdvd0 mapped to sr0
[ 77.86]
[ 77.86] =
[ 77.86] [ INFO: possible recursive locking detected ]
[ 77.86] 2.6.21-rc7 #19
[ 77.86] -
[ 77.86] vol_id/2508 is trying to acquire lock:
[ 77.86] (&bdev->bd_mutex){--..}, at: [] do_open+0x5a/0x267
[ 77.86]
[ 77.86] but task is already holding lock:
[ 77.86] (&bdev->bd_mutex){--..}, at: [] do_open+0x5a/0x267
[ 77.86]
[ 77.86] other info that might help us debug this:
[ 77.86] 2 locks held by vol_id/2508:
[ 77.86] #0: (&bdev->bd_mutex){--..}, at: []
do_open+0x5a/0x267
[ 77.86] #1: (&ctl_mutex#2){--..}, at: [] pkt_open+0x1a/0xcbc
[pktcdvd]
[ 77.86]
[ 77.86] stack backtrace:
[ 77.86] [] __lock_acquire+0x11e/0xb3b
[ 77.86] [] __mutex_unlock_slowpath+0x109/0x113
[ 77.86] [] trace_hardirqs_on+0x11e/0x141
[ 77.86] [] lock_acquire+0x56/0x6e
[ 77.86] [] do_open+0x5a/0x267
[ 77.86] [] mutex_lock_nested+0xf4/0x24f
[ 77.86] [] do_open+0x5a/0x267
[ 77.86] [] kobj_lookup+0xda/0x104
[ 77.86] [] do_open+0x5a/0x267
[ 77.86] [] __blkdev_get+0x5b/0x66
[ 77.86] [] blkdev_get+0x12/0x14
[ 77.86] [] pkt_open+0x8d/0xcbc [pktcdvd]
[ 77.86] [] __d_lookup+0x66/0xed
[ 77.86] [] __d_lookup+0x66/0xed
[ 77.86] [] _atomic_dec_and_lock+0xd/0x2c
[ 77.86] [] _atomic_dec_and_lock+0xd/0x2c
[ 77.86] [] _atomic_dec_and_lock+0xd/0x2c
[ 77.86] [] cache_alloc_refill+0x4a/0x444
[ 77.86] [] kobj_lookup+0x33/0x104
[ 77.86] [] trace_hardirqs_on+0x11e/0x141
[ 77.86] [] do_open+0x5a/0x267
[ 77.86] [] __mutex_lock_slowpath+0x222/0x235
[ 77.86] [] mutex_lock_nested+0x23c/0x24f
[ 77.86] [] mark_held_locks+0x46/0x62
[ 77.86] [] mutex_lock_nested+0x23c/0x24f
[ 77.86] [] mutex_lock_nested+0x23c/0x24f
[ 77.86] [] trace_hardirqs_on+0x11e/0x141
[ 77.86] [] do_open+0x5a/0x267
[ 77.86] [] mute
Re: BUG: Null pointer dereference in fs/open.c
This bug occurs in linux-2.6.20 and 2.6.21-rc7-git5, and does not occur in
linux-2.6.19-git22.
After running "pktsetup 0 /dev/hdd", I get (timestamps removed):
pktcdvd: pkt_get_last_written failed
BUG: unable to handle kernel NULL pointer dereference at virtual address
000e
printing eip:
c0173f69
*pde =
Oops: [#1]
PREEMPT
Modules linked in: snd_ca0106 snd_ac97_codec ac97_bus 8139cp 8139too iTCO_wdt
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010203 (2.6.21-rc7-git5 #22)
EIP is at do_sys_open+0x59/0xd0
eax: 0002 ebx: 4020 ecx: 0001 edx: 0002
esi: df1e3000 edi: 0003 ebp: de17bfa4 esp: de17bf84
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process vol_id (pid: 4273, ti=de17b000 task=df4143f0 task.ti=de17b000)
Stack: c013d2a5 ff9c 0002 c059cea3 bfb6bf64 8000 b7f60ff4
de17bfb0 c017401c de17b000 c01041c6 bfb6bf64 8000
8000 b7f60ff4 bfb6a798 0005 007b 007b 0005
Call Trace:
[] show_trace_log_lvl+0x1a/0x30
[] show_stack_log_lvl+0xa9/0xd0
[] show_registers+0x21c/0x3a0
[] die+0x104/0x260
[] do_page_fault+0x277/0x610
[] error_code+0x74/0x7c
[] sys_open+0x1c/0x20
[] sysenter_past_esp+0x5f/0x99
===
Code: ff 85 c0 89 c7 78 77 8b 45 08 89 d9 89 f2 89 04 24 8b 45 e8 e8 69 ff
ff ff 3d 00 f0 ff ff 89 45 ec 77 71 8b 55 ec bb 20 00 00 40 <8b> 42 0c 8b
48 30 89 4d f0 0f b7 51 66 81 e2 00 f0 00 00 81 fa
EIP: [] do_sys_open+0x59/0xd0 SS:ESP 0068:de17bf84
from fs/open.c, comments added:
// do_sys_open is consistently called with dfd=0xff9c,
// filename="/dev/.tmp-254-0", flags=0x8000, mode=0)
long do_sys_open(int dfd, const char __user *filename, int flags, int mode)
{
char *tmp = getname(filename);
int fd = PTR_ERR(tmp);
if (!IS_ERR(tmp)) {
fd = get_unused_fd();
if (fd >= 0) {
// do_filp_open consistently returns 2, in this case
struct file *f = do_filp_open(dfd, tmp, flags, mode);
// IS_ERR always returns 0 for this command
if (IS_ERR(f)) {
put_unused_fd(fd);
fd = PTR_ERR(f);
} else {
// null pointer dereference occurs here
fsnotify_open(f->f_path.dentry);
fd_install(fd, f);
}
}
putname(tmp);
}
return fd;
}
I was able to workaround this, by testing if do_filp_open was returning
2 or not, but obviously this is a very temporal solution to a very
specific circumstance.
If there is any more information I can provide, let me know.
William Heimbigner
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Null pointer dereference (2.6.21-rc7)
On Mon, 23 Apr 2007, William Heimbigner wrote: On Mon, 23 Apr 2007, Andrew Morton wrote: It certainly is. Are you able to identify an earlier kernel in which this didn't happen? 2.6.20? An earlier 2.6.21-rcX? I'll try .18 and .20 and see where that gets me - this is my first time trying to set up packet writing. Ok, on 2.6.18, I still get the warning about a recursive lock, but no dump regarding a null pointer dereference. The command still fails, however, with pkt_get_last_written_failed. On 2.6.20, I get an error similar to the one I orignally posted (first the recursive lock warning, seconds later, null pointer dereference). Not sure about the recursive lock, but something between .18 and .20 happened such that the packet writing driver didn't fail gracefully. On a side (offtopic) note, I noticed that ACPI support changed for the better in very recent kernels - on both .18 and .20, there were severe and early errors unless I specified acpi=off I'll see if I can figure out exactly where from 2.6.18 to .20 things went wrong, William Heimbigner [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Null pointer dereference (2.6.21-rc7)
On Mon, 23 Apr 2007, Andrew Morton wrote: It certainly is. Are you able to identify an earlier kernel in which this didn't happen? 2.6.20? An earlier 2.6.21-rcX? I'll try .18 and .20 and see where that gets me - this is my first time trying to set up packet writing. William Heimbigner [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about Reiser4
On Mon, 23 Apr 2007, Rik van Riel wrote: William Heimbigner wrote: If there was 1) a maintainer and 2) code that didn't break "coding standards", would it be included in the kernel? While I cannot speak for Linus and Andrew, code that fulfills these criteria (and is useful to have - reiser4 seems to have enough user interest) usually gets accepted. http://kernelnewbies.org/UpstreamMerge has some hints. So in conclusion / to answer Eric's question, 1) reiser4 needs a maintainer 2) reiser4 needs the code quality cleaned up 3) Until those two things happen, it's extremely unlikely that it will be included in the kernel. Correct? William Heimbigner [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about Reiser4
On Mon, 23 Apr 2007, Rik van Riel wrote: William Heimbigner wrote: However, is the code really in such a shape that the community doesn't want to maintain it? Obviously there's a significant number of people interested in reiser4 - if there weren't, questions like this wouldn't keep getting asked. There are people interested in using it, yes. However, nobody appears to have stepped up to maintain the code. If somebody really wanted to maintain the code, there would be a new maintainer already. On that note, what exactly is wanted for (assuming there was a maintainer) reiser4 to be suitable for inclusion in the kernel? To my knowledge (and I'll admit, I haven't looked in to it very far) the primary reason for rejection was that it broke coding standards. If there was 1) a maintainer and 2) code that didn't break "coding standards", would it be included in the kernel? William Heimbigner [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about Reiser4
William Heimbigner wrote: > Eric Hopper wrote: > > I know that this whole effort has been put in disarray by the > > prosecution of Hans Reiser, but I'm curious as to its status. > > It was in disarray well before. Many of the reiser4 features, > like filesystem plugins, make more technical sense in the Linux > VFS, but made more business sense for Namesys as a reiserfs 4 > thing. That lead to a stalemate. > Shouldn't it be a matter of stability though? A lot of other things matter. Things like a willingness to maintain the code after it gets merged, or at least turning the code into something the community is willing to maintain if the original developers stop maintaining it. Benchmarks suggest that reiser4 is a good file system; reiser4 is the successor to the already-accepted reiserfs; we've got experimental ext4 support but no reiser4 support, etc. Namesys kind of abandoned reiserfs after work on reiser4 started. Taking in a new code base on such a track record is not a good idea when the code is not in a shape where the community wants to maintain it. I don't see why something like plugins should matter. If it works enough to be marked as experimental, why shouldn't reiser4 support be included? It's a pain for me personally to have to patch any kernel with reiser4 support so I can use the reiser4 fs. You basically have three options: 1) keep patching every time you upgrade the kernel 2) use another filesystem 3) become the new reiser4 maintainer and turn the code into something that Linus is willing to accept I suppose. I have a feeling there's an underlying issue behind "code standards" (and even then, I think that code standards is ultimately an excuse for not integrating reiser4 support into the kernel, but that's just my opinion). However, is the code really in such a shape that the community doesn't want to maintain it? Obviously there's a significant number of people interested in reiser4 - if there weren't, questions like this wouldn't keep getting asked. William Heimbigner [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about Reiser4
Eric Hopper wrote: I know that this whole effort has been put in disarray by the prosecution of Hans Reiser, but I'm curious as to its status. It was in disarray well before. Many of the reiser4 features, like filesystem plugins, make more technical sense in the Linux VFS, but made more business sense for Namesys as a reiserfs 4 thing. That lead to a stalemate. Shouldn't it be a matter of stability though? Benchmarks suggest that reiser4 is a good file system; reiser4 is the successor to the already-accepted reiserfs; we've got experimental ext4 support but no reiser4 support, etc. I don't see why something like plugins should matter. If it works enough to be marked as experimental, why shouldn't reiser4 support be included? It's a pain for me personally to have to patch any kernel with reiser4 support so I can use the reiser4 fs. William Heimbigner [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
BUG: Null pointer dereference (2.6.21-rc7)
On running "pktsetup 0 /dev/hdd", I get the following:
[ 3970.461403] =
[ 3970.482051] [ INFO: possible recursive locking detected ]
[ 3970.498210] 2.6.21-rc7 #2
[ 3970.506062] -
[ 3970.58] vol_id/8686 is trying to acquire lock:
[ 3970.536576] (&bdev->bd_mutex){--..}, at: [] do_open+0x65/0x285
[ 3970.557104]
[ 3970.557109] but task is already holding lock:
[ 3970.574627] (&bdev->bd_mutex){--..}, at: [] do_open+0x65/0x285
[ 3970.595160]
[ 3970.595161] other info that might help us debug this:
[ 3970.614757] 2 locks held by vol_id/8686:
[ 3970.626505] #0: (&bdev->bd_mutex){--..}, at: []
do_open+0x65/0x285
[ 3970.648388] #1: (&ctl_mutex#2){--..}, at: [] mutex_lock+0x1c/0x1f
[ 3970.670065]
[ 3970.670070] stack backtrace:
[ 3970.683165] [] show_trace_log_lvl+0x1a/0x2f
[ 3970.698604] [] show_trace+0x12/0x14
[ 3970.711964] [] dump_stack+0x16/0x18
[ 3970.725322] [] __lock_acquire+0x12e/0xb93
[ 3970.740243] [] lock_acquire+0x68/0x82
[ 3970.754122] [] mutex_lock_nested+0xef/0x275
[ 3970.769560] [] do_open+0x65/0x285
[ 3970.782397] [] __blkdev_get+0x73/0x7e
[ 3970.796279] [] blkdev_get+0x15/0x17
[ 3970.809638] [] pkt_open+0x95/0xc4e
[ 3970.822737] [] do_open+0x94/0x285
[ 3970.835578] [] blkdev_open+0x28/0x51
[ 3970.849196] [] __dentry_open+0xff/0x1b1
[ 3970.863594] [] nameidata_to_filp+0x27/0x37
[ 3970.878770] [] do_filp_open+0x33/0x3b
[ 3970.892654] [] do_sys_open+0x43/0xc2
[ 3970.906274] [] sys_open+0x1c/0x1e
[ 3970.919113] [] sysenter_past_esp+0x5d/0x99
[ 3970.934292] ===
[ 3971.630710] pktcdvd: pkt_get_last_written failed
[ 3971.645027] BUG: unable to handle kernel NULL pointer dereference at virtual
address 000e
[ 3971.670652] printing eip:
[ 3971.678786] c0161aef
[ 3971.685361] *pde =
[ 3971.693761] Oops: [#1]
[ 3971.702120] PREEMPT
[ 3971.708722] Modules linked in: udf snd_intel8x0 snd_ac97_codec ac97_bus
i810_audio ac97_codec 8139cp 8139too iTCO_wdt
[ 3971.741005] CPU:0
[ 3971.741006] EIP:0060:[]Not tainted VLI
[ 3971.741008] EFLAGS: 00010203 (2.6.21-rc7 #2)
[ 3971.777034] EIP is at do_sys_open+0x59/0xc2
[ 3971.789555] eax: 0002 ebx: 8000 ecx: c0182a6b edx: dc8df650
[ 3971.809878] esi: ff9c edi: 0002 ebp: de336fa4 esp: de336f88
[ 3971.830200] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
[ 3971.847674] Process vol_id (pid: 8686, ti=de336000 task=d0b90de0
task.ti=de336000)
[ 3971.869812] Stack: cef97000 0003 bf9d7f65 8000
b7facff4 de336fb0
[ 3971.895286]c0161b90 de336000 c0103e24 bf9d7f65 8000
8000
[ 3971.920755]b7facff4 bf9d5e08 0005 007b 007b
0005 e410
[ 3971.946228] Call Trace:
[ 3971.954126] [] show_trace_log_lvl+0x1a/0x2f
[ 3971.969563] [] show_stack_log_lvl+0x9d/0xa5
[ 3971.985004] [] show_registers+0x1fb/0x33c
[ 3971.24] [] die+0x107/0x21f
[ 3972.011984] [] do_page_fault+0x448/0x520
[ 3972.026644] [] error_code+0x74/0x7c
[ 3972.040003] [] sys_open+0x1c/0x1e
[ 3972.052841] [] sysenter_past_esp+0x5d/0x99
[ 3972.068022] ===
[ 3972.078728] Code: f0 78 7e 8b 45 08 89 d9 8b 55 ec 89 04 24 89 f0 e8 82 ff ff ff
3d 00 f0 ff ff 89 c7 76 0d 8b 45 f0 e8 dc fb ff ff 89 7d f0 eb 56 <8b> 40 0c bb
20 00 00 40 8b 70 30 0f b7 56 66 81 e2 00 f0 00 00
[ 3972.138557] EIP: [] do_sys_open+0x59/0xc2 SS:ESP 0068:de336f88
Is this a bug?
If any more information is necessary, I'd be happy to provide it.
William Heimbigner
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.20-rc5
On Sun, 14 Jan 2007, Robert P. J. Day wrote: On Sun, 14 Jan 2007, [EMAIL PROTECTED] wrote: In compiling: CC [M] net/ipv4/netfilter/ipt_TTL.o LD [M] drivers/usb/storage/usb-storage.o CC [M] drivers/usb/gadget/net2280.o CC [M] net/ipv4/netfilter/arp_tables.o drivers/usb/gadget/net2280.c: In function 'net2280_probe': drivers/usb/gadget/net2280.c:2969: warning: ignoring return value of 'pci_set_mwi', declared with attribute warn_unused_result -- CC [M] net/netfilter/xt_tcpmss.o CC [M] net/netfilter/xt_hashlimit.o LD [M] net/netfilter/nf_conntrack.o Building modules, stage 2. MODPOST 239 modules WARNING: "__ucmpdi2" [drivers/media/video/v4l2-common.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 If a .config is needed or any other information, I'd be happy to provide it. is this for a powerpc? there's a thread you might want to read: http://uwsg.iu.edu/hypermail/linux/kernel/0612.1/2162.html rday That ended up causing another undefined issue in a different place, but I did find http://uwsg.iu.edu/hypermail/linux/kernel/0612.2/0223.html Seems like we may want to have this patched, until the compiler gets fixed to properly handle it. William Heimbigner [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
