Re: [GIT PULL] kdbus for 4.1-rc1
On Mon, 27 Apr 2015 15:14:49 -0700, Linus Torvalds wrote: > On Mon, Apr 27, 2015 at 3:00 PM, Linus Torvalds > wrote: >> >> IOW, all the people who say that it's about avoiding context switches >> are probably just full of shit. It's not about context switches, it's >> about bad user-level code. > > Just to make sure, I did a system-wide profile (so that you can actually > see the overhead of context switching better), and that didn't change > the picture. > > The scheduler overhead *might* be 1% or so. > > So really. The people who talk about how kdbus improves performance are > just full of sh*t. Yes, it improves things, but the improvement seems to > be 100% "incidental", in that it avoids a few trips down the user-space > problems. > > The real problems seem to be in dbus memory management (suggestion: keep > a small per-thread cache of those message allocations) and to a smaller > degree in the crazy utf8 validation (why the f*ck does it do that > anyway?), with some locking problems thrown in for good measure. In case someone actually still reads this, I guess the global rw_lock in gobject/gtype.c is one of the culprits. Every GType instance allocation/ deallocation is serialized using this lock, which pretty much disqualifies GObject from being used for anything scalable to multiple threads. GStreamer used to have serious performance issues due to that, which AFAIK have been solved by removing GType from GStreamer core in the 1.0 release. Regards, -- Jindrich Makovicka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] kdbus for 4.1-rc1
On Mon, 27 Apr 2015 15:14:49 -0700, Linus Torvalds wrote: On Mon, Apr 27, 2015 at 3:00 PM, Linus Torvalds torva...@linux-foundation.org wrote: IOW, all the people who say that it's about avoiding context switches are probably just full of shit. It's not about context switches, it's about bad user-level code. Just to make sure, I did a system-wide profile (so that you can actually see the overhead of context switching better), and that didn't change the picture. The scheduler overhead *might* be 1% or so. So really. The people who talk about how kdbus improves performance are just full of sh*t. Yes, it improves things, but the improvement seems to be 100% incidental, in that it avoids a few trips down the user-space problems. The real problems seem to be in dbus memory management (suggestion: keep a small per-thread cache of those message allocations) and to a smaller degree in the crazy utf8 validation (why the f*ck does it do that anyway?), with some locking problems thrown in for good measure. In case someone actually still reads this, I guess the global rw_lock in gobject/gtype.c is one of the culprits. Every GType instance allocation/ deallocation is serialized using this lock, which pretty much disqualifies GObject from being used for anything scalable to multiple threads. GStreamer used to have serious performance issues due to that, which AFAIK have been solved by removing GType from GStreamer core in the 1.0 release. Regards, -- Jindrich Makovicka -- To unsubscribe from this list: send the line unsubscribe linux-kernel in Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.17 000/122] 3.17.5-stable review
Hi, On Fri, 05 Dec 2014 14:42:54 -0800, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.17.5 release. > There are 122 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. I had to revert "netfilter: conntrack: fix race in __nf_conntrack_confirm against get_next_corpse" to be able to boot, getting a kernel panic otherwise: http://goo.gl/q86SWy It happens in various stages, but seems to be pretty consistently reproducible. This is a desktop running shorewall, with some nfqueue- based IP filtering added. Regards, -- Jindrich Makovicka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.17 000/122] 3.17.5-stable review
Hi, On Fri, 05 Dec 2014 14:42:54 -0800, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.17.5 release. There are 122 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. I had to revert netfilter: conntrack: fix race in __nf_conntrack_confirm against get_next_corpse to be able to boot, getting a kernel panic otherwise: http://goo.gl/q86SWy It happens in various stages, but seems to be pretty consistently reproducible. This is a desktop running shorewall, with some nfqueue- based IP filtering added. Regards, -- Jindrich Makovicka -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Enabling power states for Core 2 Duo
On Tue, 22 May 2007 17:14:45 + "Paa Paa" <[EMAIL PROTECTED]> wrote: > >>But are you saying that with most desktop mobos one doesn't usually > >>have the > >>different power states available at all? So basically the only > >>means to conserve power is to scale the frequency? > >> > > > >Please update your BIOS and try. > > I updated my Asus P5B Deluxe BIOS with no luck (this latest BIOS is > about 1 month old). Still no power states. I would be nice to know if > _any_ desktop C2D mobos have these C-states? (In x86_64 system). > > I think I never mentioned: > > I'm using 2.6.21.1 (actually gentoo-sources-2.6.21-r1) > My CPU is E6400. I observe the same problem with Gigabyte 965P-DS4, and there are at least two causes - 1) MP supported flag in FADT is missing (so CPU_HOTPLUG would be necessary), and 2) C2 latency is set to 101, while the maximum allowed in the kernel is 100. However, from the power consumption and the CPU temperature it seems that the power saving works anyway, so I'll live with it. -- Jindrich Makovicka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Enabling power states for Core 2 Duo
On Tue, 22 May 2007 17:14:45 + Paa Paa [EMAIL PROTECTED] wrote: But are you saying that with most desktop mobos one doesn't usually have the different power states available at all? So basically the only means to conserve power is to scale the frequency? Please update your BIOS and try. I updated my Asus P5B Deluxe BIOS with no luck (this latest BIOS is about 1 month old). Still no power states. I would be nice to know if _any_ desktop C2D mobos have these C-states? (In x86_64 system). I think I never mentioned: I'm using 2.6.21.1 (actually gentoo-sources-2.6.21-r1) My CPU is E6400. I observe the same problem with Gigabyte 965P-DS4, and there are at least two causes - 1) MP supported flag in FADT is missing (so CPU_HOTPLUG would be necessary), and 2) C2 latency is set to 101, while the maximum allowed in the kernel is 100. However, from the power consumption and the CPU temperature it seems that the power saving works anyway, so I'll live with it. -- Jindrich Makovicka - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add LZO1X compression support to the kernel
On Fri, 11 May 2007 22:48:15 +0200 [EMAIL PROTECTED] wrote: > >Why is this needed? What code plans to use it? > > it`s pretty useful because it`s and a damn fast and damn cpu friendly > compression alorithm. > > afaik, there is already a least one linux kernel-feature (under > development) which is using lzo compression: see compressed caching > project at http://linux-mm.org/CompressedCaching & > http://linuxcompressed.sourceforge.net/ Reiser4.1 (still in development) uses LZO compression too and it brings a significant boost on dual core machines. -- Jindrich Makovicka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add LZO1X compression support to the kernel
On Fri, 11 May 2007 22:48:15 +0200 [EMAIL PROTECTED] wrote: Why is this needed? What code plans to use it? it`s pretty useful because it`s and a damn fast and damn cpu friendly compression alorithm. afaik, there is already a least one linux kernel-feature (under development) which is using lzo compression: see compressed caching project at http://linux-mm.org/CompressedCaching http://linuxcompressed.sourceforge.net/ Reiser4.1 (still in development) uses LZO compression too and it brings a significant boost on dual core machines. -- Jindrich Makovicka - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add LZO1X compression support to the kernel
On Sat, 12 May 2007 12:41:03 +0200 [EMAIL PROTECTED] wrote: > oh - and think of linux software suspend. > take a notebook with 2 GB of ram - that takes a while to write that > to disk and read that back again. using lzo compression for this may > probably halve the time for suspend/resume There were already some attempts on merging of the lzf algorithm: http://lkml.org/lkml/2006/6/26/215 Also, ffmpeg/libavcodec contains a much cleaner implementation of LZO decompressor, with comparable performance (but no compressor yet I am afraid). -- Jindrich Makovicka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add LZO1X compression support to the kernel
On Sat, 12 May 2007 12:41:03 +0200 [EMAIL PROTECTED] wrote: oh - and think of linux software suspend. take a notebook with 2 GB of ram - that takes a while to write that to disk and read that back again. using lzo compression for this may probably halve the time for suspend/resume There were already some attempts on merging of the lzf algorithm: http://lkml.org/lkml/2006/6/26/215 Also, ffmpeg/libavcodec contains a much cleaner implementation of LZO decompressor, with comparable performance (but no compressor yet I am afraid). -- Jindrich Makovicka - 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.19
Needed the VIA PATA patch to be able to boot: http://lkml.org/lkml/2006/6/18/165 Also, atakbd.c produced lots of "Spurious ACK" messages on kernel panic when I misspecified the root fs, which made the real problem a little more difficult to find. -- Jindrich Makovicka - 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.19
Needed the VIA PATA patch to be able to boot: http://lkml.org/lkml/2006/6/18/165 Also, atakbd.c produced lots of Spurious ACK messages on kernel panic when I misspecified the root fs, which made the real problem a little more difficult to find. -- Jindrich Makovicka - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm1: horribly drivers/scsi/qla2xxx/Makefile
Andrew Vasquez wrote: > Yes, quite. How about the following to correct the intention. > > > > Add correct Kconfig option for ISP24xx support. > > Signed-off-by: Andrew Vasquez <[EMAIL PROTECTED]> > --- > > diff --git a/drivers/scsi/qla2xxx/Kconfig b/drivers/scsi/qla2xxx/Kconfig > --- a/drivers/scsi/qla2xxx/Kconfig > +++ b/drivers/scsi/qla2xxx/Kconfig > @@ -39,3 +39,11 @@ config SCSI_QLA6312 > ---help--- > This driver supports the QLogic 63xx (ISP6312 and ISP6322) host > adapter family. > + > +config SCSI_QLA24XX > + tristate "QLogic ISP24xx host adapter family support" > + depends on SCSI_QLA2XXX > +select SCSI_FC_ATTRS there should be also "select FW_LOADER", as it uses request_firmware & release_firmware > + ---help--- > + This driver supports the QLogic 24xx (ISP2422 and ISP2432) host > + adapter family. -- Jindrich Makovicka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13-rc3-mm1: horribly drivers/scsi/qla2xxx/Makefile
Andrew Vasquez wrote: Yes, quite. How about the following to correct the intention. Add correct Kconfig option for ISP24xx support. Signed-off-by: Andrew Vasquez [EMAIL PROTECTED] --- diff --git a/drivers/scsi/qla2xxx/Kconfig b/drivers/scsi/qla2xxx/Kconfig --- a/drivers/scsi/qla2xxx/Kconfig +++ b/drivers/scsi/qla2xxx/Kconfig @@ -39,3 +39,11 @@ config SCSI_QLA6312 ---help--- This driver supports the QLogic 63xx (ISP6312 and ISP6322) host adapter family. + +config SCSI_QLA24XX + tristate QLogic ISP24xx host adapter family support + depends on SCSI_QLA2XXX +select SCSI_FC_ATTRS there should be also select FW_LOADER, as it uses request_firmware release_firmware + ---help--- + This driver supports the QLogic 24xx (ISP2422 and ISP2432) host + adapter family. -- Jindrich Makovicka - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc2-mm3
Andrew Morton wrote: > Jindrich Makovicka <[EMAIL PROTECTED]> wrote: > >>Andrew Morton wrote: >> >>>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/ >> >>MPlayer randomly crashes in various pthread_* calls when using binary >>codecs. 2.6.12-rc2-mm2 was ok. I tried to reverse >>fix-crash-in-entrys-restore_all.patch, but it didn't help. >> > > > hm, could be anything. > > Does 2.6.12-rc2 also fail? looks like it's sched-unlocked-context-switches.patch. after reversing it works fine. -- Jindrich Makovicka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc2-mm3
Andrew Morton wrote: Jindrich Makovicka [EMAIL PROTECTED] wrote: Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/ MPlayer randomly crashes in various pthread_* calls when using binary codecs. 2.6.12-rc2-mm2 was ok. I tried to reverse fix-crash-in-entrys-restore_all.patch, but it didn't help. hm, could be anything. Does 2.6.12-rc2 also fail? looks like it's sched-unlocked-context-switches.patch. after reversing it works fine. -- Jindrich Makovicka - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc2-mm3
Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/ MPlayer randomly crashes in various pthread_* calls when using binary codecs. 2.6.12-rc2-mm2 was ok. I tried to reverse fix-crash-in-entrys-restore_all.patch, but it didn't help. .config attached. -- Jindrich Makovicka # # Automatically generated make config: don't edit # Linux kernel version: 2.6.12-rc2-mm3 # Mon Apr 11 20:58:23 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_USE_3DNOW=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_SMP is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y # CONFIG_X86_MCE_P4THERMAL is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set CONFIG_MICROCODE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y CONFIG_FLATMEM=y # CONFIG_DISCONTIGMEM is not set # CONFIG_HIGHPTE is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_HAVE_DEC_LOCK=y # CONFIG_REGPARM is not set CONFIG_SECCOMP=y # # Performance-monitoring counters support # # CONFIG_PERFCTR is not set CONFIG_PHYSICAL_START=0x10 # CONFIG_KEXEC is not set # # Power management options (ACPI, APM) # CONFIG_PM=y # CONFIG_PM_DEBUG is not set CONFIG_SOFTWARE_SUSPEND=y CONFIG_PM_STD_PARTITION="" # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y CONFIG_ACPI_AC=y CONFIG_ACPI_BATTERY=y CONFIG_ACPI_BUTTON=y CONFIG_ACPI_VIDEO=y CONFIG_ACPI_HOTKEY=y CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_IBM is not set # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y # CONFIG_X86_PM_TIMER is not set # CONFIG_ACPI_CONTAINER is not set # # APM (Advanced Power Management) BIOS Support # CONFIG_APM=y # CONFIG_APM_IGNORE_USER_SUSPEND is not set # CONFIG_APM_DO_ENABLE is not set CONFIG_APM_CPU_IDLE=y # CONFIG_APM_DISPLAY_BLANK is not set CONFIG_APM_RTC_IS_GMT=y # CONFIG_APM_ALLOW_INTS is not set # CONFIG_APM_REAL_MODE_POWER_OFF is not set # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y # CONFIG_CPU_FREQ_DEBUG is not set CONFIG_CPU_FREQ_STAT=y CONFIG_
Re: 2.6.12-rc2-mm3
Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/ MPlayer randomly crashes in various pthread_* calls when using binary codecs. 2.6.12-rc2-mm2 was ok. I tried to reverse fix-crash-in-entrys-restore_all.patch, but it didn't help. .config attached. -- Jindrich Makovicka # # Automatically generated make config: don't edit # Linux kernel version: 2.6.12-rc2-mm3 # Mon Apr 11 20:58:23 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_USE_3DNOW=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_SMP is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y # CONFIG_X86_MCE_P4THERMAL is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set CONFIG_MICROCODE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y CONFIG_FLATMEM=y # CONFIG_DISCONTIGMEM is not set # CONFIG_HIGHPTE is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_HAVE_DEC_LOCK=y # CONFIG_REGPARM is not set CONFIG_SECCOMP=y # # Performance-monitoring counters support # # CONFIG_PERFCTR is not set CONFIG_PHYSICAL_START=0x10 # CONFIG_KEXEC is not set # # Power management options (ACPI, APM) # CONFIG_PM=y # CONFIG_PM_DEBUG is not set CONFIG_SOFTWARE_SUSPEND=y CONFIG_PM_STD_PARTITION= # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y CONFIG_ACPI_AC=y CONFIG_ACPI_BATTERY=y CONFIG_ACPI_BUTTON=y CONFIG_ACPI_VIDEO=y CONFIG_ACPI_HOTKEY=y CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_IBM is not set # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y # CONFIG_X86_PM_TIMER is not set # CONFIG_ACPI_CONTAINER is not set # # APM (Advanced Power Management) BIOS Support # CONFIG_APM=y # CONFIG_APM_IGNORE_USER_SUSPEND is not set # CONFIG_APM_DO_ENABLE is not set CONFIG_APM_CPU_IDLE=y # CONFIG_APM_DISPLAY_BLANK is not set CONFIG_APM_RTC_IS_GMT=y # CONFIG_APM_ALLOW_INTS is not set # CONFIG_APM_REAL_MODE_POWER_OFF is not set # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y # CONFIG_CPU_FREQ_DEBUG is not set CONFIG_CPU_FREQ_STAT=y CONFIG_CPU_FREQ_STAT_DETAILS=y
Re: 2.6.12-rc2-mm1
Andrew Morton wrote: [...] Does not compile on AthlonXP. For mmx_clear_page, only the prototype was changed, but the implementation is still the same. I guess that part of the patch slipped out somehow. -extern void mmx_clear_page(void *page); +extern void mmx_clear_page(void *page, int order); -- Jindrich Makovicka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc2-mm1
Andrew Morton wrote: [...] Does not compile on AthlonXP. For mmx_clear_page, only the prototype was changed, but the implementation is still the same. I guess that part of the patch slipped out somehow. -extern void mmx_clear_page(void *page); +extern void mmx_clear_page(void *page, int order); -- Jindrich Makovicka - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc4-mm1: something is wrong with swsusp powerdown
Andrew Morton wrote: (Please do reply-to-all) Jindrich Makovicka <[EMAIL PROTECTED]> wrote: Pavel Machek wrote: Hi! In `subj` kernel, machine no longer powers down at the end of swsusp. 2.6.11-rc5-pavel works ok, as does 2.6.11-bk. For me, power down stopped working since the introduction of softlockup detection. After disabling CONFIG_DETECT_SOFTLOCKUP, powerdown works fine. Could you send the output which CONFIG_DETECT_SOFTLOCKUP generates? I had one CONFIG_DETECT_SOFTLOCKUP failure with suspend, on SMP. The machine was stuck somewhere under mce_work_fn(). Perhaps in the smp_call_function(). It only happened the once. Strange enough, softlockup produces no additional output. Kernel just prints "acpi_power_off called" and freezes. Without softlockup detection compiled in it turns off normally. First I was under impression that this is caused by acpi_power_off-bug-fix.patch mentioned above, but unfortunately removing it didn't actually solve the problem. Later I found I missed that softlockup detection sneaked in turned on by default, and disabling it made power off work again. Power down via APM produced some softlockup output, but I am not sure if APM actually worked on my machine before - I just tried APM if it works when ACPI doesn't, and didn't bother taking a snapshot. I can recompile an APM kernel with softlockup enabled and disabled and test it, if it could help. -- Jindrich Makovicka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc4-mm1: something is wrong with swsusp powerdown
Andrew Morton wrote: (Please do reply-to-all) Jindrich Makovicka [EMAIL PROTECTED] wrote: Pavel Machek wrote: Hi! In `subj` kernel, machine no longer powers down at the end of swsusp. 2.6.11-rc5-pavel works ok, as does 2.6.11-bk. For me, power down stopped working since the introduction of softlockup detection. After disabling CONFIG_DETECT_SOFTLOCKUP, powerdown works fine. Could you send the output which CONFIG_DETECT_SOFTLOCKUP generates? I had one CONFIG_DETECT_SOFTLOCKUP failure with suspend, on SMP. The machine was stuck somewhere under mce_work_fn(). Perhaps in the smp_call_function(). It only happened the once. Strange enough, softlockup produces no additional output. Kernel just prints acpi_power_off called and freezes. Without softlockup detection compiled in it turns off normally. First I was under impression that this is caused by acpi_power_off-bug-fix.patch mentioned above, but unfortunately removing it didn't actually solve the problem. Later I found I missed that softlockup detection sneaked in turned on by default, and disabling it made power off work again. Power down via APM produced some softlockup output, but I am not sure if APM actually worked on my machine before - I just tried APM if it works when ACPI doesn't, and didn't bother taking a snapshot. I can recompile an APM kernel with softlockup enabled and disabled and test it, if it could help. -- Jindrich Makovicka - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc4-mm1: something is wrong with swsusp powerdown
Pavel Machek wrote: Hi! In `subj` kernel, machine no longer powers down at the end of swsusp. 2.6.11-rc5-pavel works ok, as does 2.6.11-bk. For me, power down stopped working since the introduction of softlockup detection. After disabling CONFIG_DETECT_SOFTLOCKUP, powerdown works fine. -- Jindrich Makovicka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc4-mm1: something is wrong with swsusp powerdown
Pavel Machek wrote: Hi! In `subj` kernel, machine no longer powers down at the end of swsusp. 2.6.11-rc5-pavel works ok, as does 2.6.11-bk. For me, power down stopped working since the introduction of softlockup detection. After disabling CONFIG_DETECT_SOFTLOCKUP, powerdown works fine. -- Jindrich Makovicka - 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: bttv: tuner: i2c i/o error: rc == -121 (should be 4)
Margus Eha wrote: Tv card works but i can't change channel. Something goes wrong in tuner.c when tvtime program tries to change frequency. In /var/log/messages i can find tuner: i2c i/o error: rc == -121 (should be 4). Las working version i tried was 2.6.11-rc2 Both 2.6.11-rc3-mm1 and Both 2.6.11-rc3-mm2 are not working. If kernel conf is needed i can send. http://bugme.osdl.org/show_bug.cgi?id=4171 -- JM - 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: bttv: tuner: i2c i/o error: rc == -121 (should be 4)
Margus Eha wrote: Tv card works but i can't change channel. Something goes wrong in tuner.c when tvtime program tries to change frequency. In /var/log/messages i can find tuner: i2c i/o error: rc == -121 (should be 4). Las working version i tried was 2.6.11-rc2 Both 2.6.11-rc3-mm1 and Both 2.6.11-rc3-mm2 are not working. If kernel conf is needed i can send. http://bugme.osdl.org/show_bug.cgi?id=4171 -- JM - 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/
