* linux-next: Tree for June 13 @ 2008-06-13 13:22 Stephen Rothwell 2008-06-13 17:13 ` linux-next: Tree for June 13 (XEN) Randy Dunlap ` (3 more replies) 0 siblings, 4 replies; 90+ messages in thread From: Stephen Rothwell @ 2008-06-13 13:22 UTC (permalink / raw) To: linux-next; +Cc: LKML [-- Attachment #1: Type: text/plain, Size: 9339 bytes --] Hi all, Changes since next-20080612: New tree: kgdb Dropped trees (temporary): ldp (it is unfetchable - probably something to do with the new Staging tree) Restored trees: block The x86 tree gained a conflict with Linus' tree. The acpi tree gained a conflict with the pci tree. The mtd tree gained a trivial conflict with the avr32 tree. The rr tree lost its conflict with the net-current tree. The block tree gained several conflict with various other trees. It also required a build fix patch. The firmware tree lost its build fix patch. The patches for known build problems are no longer needed. ---------------------------------------------------------------------------- I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups, it is also built with powerpc allnoconfig, 44x_defconfig and allyesconfig and i386, sparc and sparc64 defconfig. Below is a summary of the state of the merge. We are up to 92 trees (counting Linus' and 13 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Jan Dittmer for adding the linux-next tree to his build tests at http://l4x.org/k/ , the guys at http://test.kernel.org/ and Randy Dunlap for doing many randconfig builds. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master Merging powerpc-merge/merge Merging scsi-rc-fixes/master Merging net-current/master Merging sparc-current/master Merging sound-current/for-linus Merging arm-current/master Merging pci-current/for-linus Merging wireless-current/master Merging kbuild-current/master Merging quilt/driver-core.current Merging quilt/usb.current Merging cpufreq-current/fixes Merging input-current/for-linus Merging quilt/driver-core Merging quilt/usb Merging tip-core/auto-core-next Merging cpus4096/auto-cpus4096-next Merging ftrace/auto-ftrace-next Merging genirq/auto-genirq-next Merging safe-poison-pointers/auto-safe-poison-pointers-next Merging sched/auto-sched-next CONFLICT (content): Merge conflict in kernel/Makefile Applying ftrace: fix rculist split fallout Merging stackprotector/auto-stackprotector-next Merging timers/auto-timers-next Merging x86/auto-x86-next CONFLICT (content): Merge conflict in arch/x86/kernel/io_apic_32.c CONFLICT (delete/modify): arch/x86/kernel/nmi_32.c deleted in x86/auto-x86-next and modified in HEAD. Version HEAD of arch/x86/kernel/nmi_32.c left in tree. CONFLICT (content): Merge conflict in arch/x86/kernel/process_32.c CONFLICT (content): Merge conflict in arch/x86/kernel/process_64.c Merging pci/linux-next CONFLICT (content): Merge conflict in arch/x86/pci/irq.c CONFLICT (content): Merge conflict in include/linux/device.h Merging quilt/device-mapper Merging hid/mm Merging quilt/i2c CONFLICT (content): Merge conflict in drivers/i2c/i2c-core.c Merging quilt/kernel-doc Merging avr32/avr32-arch Merging v4l-dvb/stable Merging s390/features CONFLICT (content): Merge conflict in drivers/s390/block/dasd.c CONFLICT (content): Merge conflict in drivers/s390/block/dasd_eckd.c CONFLICT (content): Merge conflict in drivers/s390/block/dasd_fba.c CONFLICT (content): Merge conflict in drivers/s390/char/tape_core.c CONFLICT (content): Merge conflict in drivers/s390/cio/device_fsm.c CONFLICT (content): Merge conflict in drivers/s390/net/claw.c CONFLICT (content): Merge conflict in drivers/s390/net/ctcm_main.c CONFLICT (content): Merge conflict in drivers/s390/net/lcs.c Merging sh/master Merging jfs/next Merging kbuild/master Merging quilt/ide Merging libata/NEXT Merging nfs/linux-next Merging xfs/master Merging infiniband/for-next Merging acpi/test CONFLICT (content): Merge conflict in drivers/acpi/processor_throttling.c CONFLICT (content): Merge conflict in drivers/acpi/sleep/main.c Merging blackfin/for-linus Merging nfsd/nfsd-next CONFLICT (content): Merge conflict in net/sunrpc/svc.c Merging ieee1394/for-next Merging hwmon/testing Merging ubi/master Merging kvm/master Merging dlm/next Merging scsi/master Applying scsi: fix fallout from the class_find_device API change Applying scsi: fix fallout from KOBJ_NAME_LEN removal Merging ia64/test Merging tests/master CONFLICT (content): Merge conflict in lib/Kconfig.debug Merging ocfs2/linux-next Merging selinux/for-akpm Merging quilt/m68k Merging powerpc/powerpc-next Merging lblnet/master Merging ext4/next Merging 4xx/next Merging async_tx/next Merging udf/for_next Merging security-testing/next Merging net/master CONFLICT (content): Merge conflict in Documentation/powerpc/booting-without-of.txt Merging sparc/master Merging galak/powerpc-next CONFLICT (content): Merge conflict in Documentation/powerpc/booting-without-of.txt Merging mtd/master Merging wireless/master Merging crypto/master Merging vfs/vfs-2.6.25 Merging sound/master Merging arm/devel CONFLICT (content): Merge conflict in arch/arm/mach-at91/board-yl-9200.c CONFLICT (content): Merge conflict in arch/arm/mach-pxa/tosa.c Merging cpufreq/next CONFLICT (content): Merge conflict in drivers/cpufreq/cpufreq.c Merging v9fs/for-next Merging quilt/rr Merging cifs/master Merging mmc/next Merging gfs2/master Merging input/next Merging semaphore/semaphore Merging semaphore-removal/semaphore-removal CONFLICT (content): Merge conflict in drivers/net/ps3_gelic_wireless.c CONFLICT (content): Merge conflict in drivers/scsi/qla2xxx/qla_attr.c CONFLICT (content): Merge conflict in drivers/scsi/qla2xxx/qla_def.h CONFLICT (content): Merge conflict in drivers/scsi/qla2xxx/qla_mbx.c CONFLICT (content): Merge conflict in drivers/scsi/qla2xxx/qla_mid.c CONFLICT (content): Merge conflict in drivers/scsi/qla2xxx/qla_os.c Merging bkl-removal/bkl-removal Merging trivial/next Merging ubifs/for_andrew Merging lsm/for-next Merging block/for-next CONFLICT (content): Merge conflict in arch/powerpc/Kconfig CONFLICT (content): Merge conflict in arch/x86/kernel/apic_32.c CONFLICT (delete/modify): arch/x86/kernel/i8259_64.c deleted in HEAD and modified in block/for-next. Version block/for-next of arch/x86/kernel/i8259_64.c left in tree. CONFLICT (content): Merge conflict in arch/x86/xen/smp.c CONFLICT (delete/modify): include/asm-x86/hw_irq_32.h deleted in HEAD and modified in block/for-next. Version block/for-next of include/asm-x86/hw_irq_32.h left in tree. CONFLICT (delete/modify): include/asm-x86/hw_irq_64.h deleted in HEAD and modified in block/for-next. Version block/for-next of include/asm-x86/hw_irq_64.h left in tree. CONFLICT (delete/modify): include/asm-x86/mach-default/irq_vectors.h deleted in HEAD and modified in block/for-next. Version block/for-next of include/asm-x86/mach-default/irq_vectors.h left in tree. CONFLICT (delete/modify): include/asm-x86/mach-voyager/irq_vectors.h deleted in HEAD and modified in block/for-next. Version block/for-next of include/asm-x86/mach-voyager/irq_vectors.h left in tree. CONFLICT (content): Merge conflict in kernel/Makefile Applying block: fix up rculist split fallout Merging embedded/master Merging firmware/master CONFLICT (content): Merge conflict in drivers/char/ip2/ip2main.c CONFLICT (content): Merge conflict in drivers/usb/misc/isight_firmware.c CONFLICT (content): Merge conflict in drivers/usb/serial/Kconfig CONFLICT (delete/modify): drivers/usb/serial/ti_fw_3410.h deleted in firmware/master and modified in HEAD. Version HEAD of drivers/usb/serial/ti_fw_3410.h left in tree. CONFLICT (delete/modify): drivers/usb/serial/ti_fw_5052.h deleted in firmware/master and modified in HEAD. Version HEAD of drivers/usb/serial/ti_fw_5052.h left in tree. CONFLICT (content): Merge conflict in drivers/usb/serial/ti_usb_3410_5052.c CONFLICT (content): Merge conflict in sound/pci/Kconfig CONFLICT (content): Merge conflict in sound/pci/maestro3.c CONFLICT (content): Merge conflict in sound/pci/ymfpci/ymfpci_main.c Merging pcmcia/master Merging battery/master Merging leds/for-mm Merging backlight/for-mm CONFLICT (content): Merge conflict in drivers/video/backlight/Kconfig CONFLICT (content): Merge conflict in drivers/video/backlight/Makefile Merging kgdb/kgdb-next [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13 (XEN) 2008-06-13 13:22 linux-next: Tree for June 13 Stephen Rothwell @ 2008-06-13 17:13 ` Randy Dunlap 2008-06-13 22:16 ` Jeremy Fitzhardinge 2008-06-13 22:58 ` linux-next: Tree for June 13 (x86_64: panic) Randy Dunlap ` (2 subsequent siblings) 3 siblings, 1 reply; 90+ messages in thread From: Randy Dunlap @ 2008-06-13 17:13 UTC (permalink / raw) To: Stephen Rothwell; +Cc: linux-next, LKML, jeremy, chrisw, virtualization next-20080613 on x86_32 has lots of xen build errors like this: linux-next-20080613/arch/x86/xen/mmu.c: In function 'drop_mm_ref': linux-next-20080613/arch/x86/xen/mmu.c:759: error: implicit declaration of function 'xen_smp_call_function_mask' make[2]: *** [arch/x86/xen/mmu.o] Error 1 --- ~Randy '"Daemon' is an old piece of jargon from the UNIX operating system, where it referred to a piece of low-level utility software, a fundamental part of the operating system." ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13 (XEN) 2008-06-13 17:13 ` linux-next: Tree for June 13 (XEN) Randy Dunlap @ 2008-06-13 22:16 ` Jeremy Fitzhardinge 2008-06-14 20:31 ` Jens Axboe 0 siblings, 1 reply; 90+ messages in thread From: Jeremy Fitzhardinge @ 2008-06-13 22:16 UTC (permalink / raw) To: Randy Dunlap Cc: Stephen Rothwell, chrisw, virtualization, linux-next, LKML, Jens Axboe Randy Dunlap wrote: > next-20080613 on x86_32 has lots of xen build errors like this: > > linux-next-20080613/arch/x86/xen/mmu.c: In function 'drop_mm_ref': > linux-next-20080613/arch/x86/xen/mmu.c:759: error: implicit declaration of function 'xen_smp_call_function_mask' > make[2]: *** [arch/x86/xen/mmu.o] Error 1 > > Ooh, first time I've seen that. Sounds like Jens' patches are missing the appropriate update there (though it's certainly had it in the past). J ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13 (XEN) 2008-06-13 22:16 ` Jeremy Fitzhardinge @ 2008-06-14 20:31 ` Jens Axboe 2008-06-14 23:13 ` Randy Dunlap 2008-06-15 6:11 ` Jeremy Fitzhardinge 0 siblings, 2 replies; 90+ messages in thread From: Jens Axboe @ 2008-06-14 20:31 UTC (permalink / raw) To: Jeremy Fitzhardinge Cc: Randy Dunlap, Stephen Rothwell, chrisw, virtualization, linux-next, LKML On Fri, Jun 13 2008, Jeremy Fitzhardinge wrote: > Randy Dunlap wrote: > >next-20080613 on x86_32 has lots of xen build errors like this: > > > >linux-next-20080613/arch/x86/xen/mmu.c: In function 'drop_mm_ref': > >linux-next-20080613/arch/x86/xen/mmu.c:759: error: implicit declaration of > >function 'xen_smp_call_function_mask' > >make[2]: *** [arch/x86/xen/mmu.o] Error 1 > > > > > > Ooh, first time I've seen that. Sounds like Jens' patches are missing > the appropriate update there (though it's certainly had it in the past). Hmm, will this work or do we need to force xen smp_ops for this one? I wonder if this is new code and was missed, or what happened in this case. diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c index 3525ef5..8baef77 100644 --- a/arch/x86/xen/mmu.c +++ b/arch/x86/xen/mmu.c @@ -569,7 +569,7 @@ static void drop_mm_ref(struct mm_struct *mm) } if (!cpus_empty(mask)) - xen_smp_call_function_mask(mask, drop_other_mm_ref, mm, 1); + smp_call_function_mask(mask, drop_other_mm_ref, mm, 1); } #else static void drop_mm_ref(struct mm_struct *mm) -- Jens Axboe ^ permalink raw reply related [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13 (XEN) 2008-06-14 20:31 ` Jens Axboe @ 2008-06-14 23:13 ` Randy Dunlap 2008-06-15 6:11 ` Jeremy Fitzhardinge 1 sibling, 0 replies; 90+ messages in thread From: Randy Dunlap @ 2008-06-14 23:13 UTC (permalink / raw) To: Jens Axboe Cc: Jeremy Fitzhardinge, Stephen Rothwell, chrisw, virtualization, linux-next, LKML On Sat, 14 Jun 2008 22:31:10 +0200 Jens Axboe wrote: > On Fri, Jun 13 2008, Jeremy Fitzhardinge wrote: > > Randy Dunlap wrote: > > >next-20080613 on x86_32 has lots of xen build errors like this: > > > > > >linux-next-20080613/arch/x86/xen/mmu.c: In function 'drop_mm_ref': > > >linux-next-20080613/arch/x86/xen/mmu.c:759: error: implicit declaration of > > >function 'xen_smp_call_function_mask' > > >make[2]: *** [arch/x86/xen/mmu.o] Error 1 > > > > > > > > > > Ooh, first time I've seen that. Sounds like Jens' patches are missing > > the appropriate update there (though it's certainly had it in the past). > > Hmm, will this work or do we need to force xen smp_ops for this one? I > wonder if this is new code and was missed, or what happened in this > case. Builds cleanly. Thanks. > diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c > index 3525ef5..8baef77 100644 > --- a/arch/x86/xen/mmu.c > +++ b/arch/x86/xen/mmu.c > @@ -569,7 +569,7 @@ static void drop_mm_ref(struct mm_struct *mm) > } > > if (!cpus_empty(mask)) > - xen_smp_call_function_mask(mask, drop_other_mm_ref, mm, 1); > + smp_call_function_mask(mask, drop_other_mm_ref, mm, 1); > } > #else > static void drop_mm_ref(struct mm_struct *mm) --- ~Randy '"Daemon' is an old piece of jargon from the UNIX operating system, where it referred to a piece of low-level utility software, a fundamental part of the operating system." ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13 (XEN) 2008-06-14 20:31 ` Jens Axboe 2008-06-14 23:13 ` Randy Dunlap @ 2008-06-15 6:11 ` Jeremy Fitzhardinge 2008-06-16 19:30 ` Jens Axboe 1 sibling, 1 reply; 90+ messages in thread From: Jeremy Fitzhardinge @ 2008-06-15 6:11 UTC (permalink / raw) To: Jens Axboe Cc: Randy Dunlap, Stephen Rothwell, chrisw, virtualization, linux-next, LKML Jens Axboe wrote: > On Fri, Jun 13 2008, Jeremy Fitzhardinge wrote: > >> Randy Dunlap wrote: >> >>> next-20080613 on x86_32 has lots of xen build errors like this: >>> >>> linux-next-20080613/arch/x86/xen/mmu.c: In function 'drop_mm_ref': >>> linux-next-20080613/arch/x86/xen/mmu.c:759: error: implicit declaration of >>> function 'xen_smp_call_function_mask' >>> make[2]: *** [arch/x86/xen/mmu.o] Error 1 >>> >>> >>> >> Ooh, first time I've seen that. Sounds like Jens' patches are missing >> the appropriate update there (though it's certainly had it in the past). >> > > Hmm, will this work or do we need to force xen smp_ops for this one? I > wonder if this is new code and was missed, or what happened in this > case. > Yes, using smp_call_function_mask is perfectly OK. The old code was just a micro-optimisation. I'm pretty sure this chunk was in one of your patchsets (or perhaps I sent it to you at some point). > diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c > index 3525ef5..8baef77 100644 > --- a/arch/x86/xen/mmu.c > +++ b/arch/x86/xen/mmu.c > @@ -569,7 +569,7 @@ static void drop_mm_ref(struct mm_struct *mm) > } > > if (!cpus_empty(mask)) > - xen_smp_call_function_mask(mask, drop_other_mm_ref, mm, 1); > + smp_call_function_mask(mask, drop_other_mm_ref, mm, 1); > } > #else > static void drop_mm_ref(struct mm_struct *mm) > > Acked-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> J ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13 (XEN) 2008-06-15 6:11 ` Jeremy Fitzhardinge @ 2008-06-16 19:30 ` Jens Axboe 2008-06-16 20:40 ` Jeremy Fitzhardinge 0 siblings, 1 reply; 90+ messages in thread From: Jens Axboe @ 2008-06-16 19:30 UTC (permalink / raw) To: Jeremy Fitzhardinge Cc: Randy Dunlap, Stephen Rothwell, chrisw, virtualization, linux-next, LKML On Sun, Jun 15 2008, Jeremy Fitzhardinge wrote: > Jens Axboe wrote: > >On Fri, Jun 13 2008, Jeremy Fitzhardinge wrote: > > > >>Randy Dunlap wrote: > >> > >>>next-20080613 on x86_32 has lots of xen build errors like this: > >>> > >>>linux-next-20080613/arch/x86/xen/mmu.c: In function 'drop_mm_ref': > >>>linux-next-20080613/arch/x86/xen/mmu.c:759: error: implicit declaration > >>>of function 'xen_smp_call_function_mask' > >>>make[2]: *** [arch/x86/xen/mmu.o] Error 1 > >>> > >>> > >>> > >>Ooh, first time I've seen that. Sounds like Jens' patches are missing > >>the appropriate update there (though it's certainly had it in the past). > >> > > > >Hmm, will this work or do we need to force xen smp_ops for this one? I > >wonder if this is new code and was missed, or what happened in this > >case. > > > > Yes, using smp_call_function_mask is perfectly OK. The old code was > just a micro-optimisation. I'm pretty sure this chunk was in one of > your patchsets (or perhaps I sent it to you at some point). Hmm yes, not sure myself to be honest, but I think you are right. > >diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c > >index 3525ef5..8baef77 100644 > >--- a/arch/x86/xen/mmu.c > >+++ b/arch/x86/xen/mmu.c > >@@ -569,7 +569,7 @@ static void drop_mm_ref(struct mm_struct *mm) > > } > > > > if (!cpus_empty(mask)) > >- xen_smp_call_function_mask(mask, drop_other_mm_ref, mm, 1); > >+ smp_call_function_mask(mask, drop_other_mm_ref, mm, 1); > > } > > #else > > static void drop_mm_ref(struct mm_struct *mm) > > > > > > Acked-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Thanks, I just folded it in with the existing patch to avoid breakage. That one doesn't have an ack from you though, so if you have done a full review of the x86 bits, I'd appreciate an ack on those from you :-) -- Jens Axboe ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13 (XEN) 2008-06-16 19:30 ` Jens Axboe @ 2008-06-16 20:40 ` Jeremy Fitzhardinge 0 siblings, 0 replies; 90+ messages in thread From: Jeremy Fitzhardinge @ 2008-06-16 20:40 UTC (permalink / raw) To: Jens Axboe Cc: Randy Dunlap, Stephen Rothwell, chrisw, virtualization, linux-next, LKML Jens Axboe wrote: > Thanks, I just folded it in with the existing patch to avoid breakage. > That one doesn't have an ack from you though, so if you have done a full > review of the x86 bits, I'd appreciate an ack on those from you :-) > I've been testing it without problems, at least under Xen. Acked-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> J ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13 (x86_64: panic) 2008-06-13 13:22 linux-next: Tree for June 13 Stephen Rothwell 2008-06-13 17:13 ` linux-next: Tree for June 13 (XEN) Randy Dunlap @ 2008-06-13 22:58 ` Randy Dunlap 2008-06-14 8:16 ` Stephen Rothwell 2008-06-15 16:33 ` linux-next: Tree for June 13 (soft lockup) Randy Dunlap 2008-06-15 18:31 ` linux-next: Tree for June 13 Rafael J. Wysocki 3 siblings, 1 reply; 90+ messages in thread From: Randy Dunlap @ 2008-06-13 22:58 UTC (permalink / raw) To: Stephen Rothwell; +Cc: linux-next, LKML [-- Attachment #1: Type: text/plain, Size: 1334 bytes --] When booting linux-next-20080613, I'm seeing a panic (on x86_64): Freeing unused kernel memory: 380k freed Write protecting the kernel read-only data: 4616k uhci_hcd: version magic '2.6.26-rc6 SMP mod_unload ' should be '2.6.26-rc6-next-20080613 SMP mod_unload ' ohci_hcd: version magic '2.6.26-rc6 SMP mod_unload ' should be '2.6.26-rc6-next-20080613 SMP mod_unload ' ehci_hcd: version magic '2.6.26-rc6 SMP mod_unload ' should be '2.6.26-rc6-next-20080613 SMP mod_unload ' cciss: version magic '2.6.26-rc6 SMP mod_unload ' should be '2.6.26-rc6-next-20080613 SMP mod_unload ' Kernel panic - not syncing: Attempted to kill init! Pid: 1, comm: init Not tainted 2.6.26-rc6-next-20080613 #1 Call Trace: [<ffffffff80233c56>] panic+0xa0/0x160 [<ffffffff80280119>] ? handle_mm_fault+0x687/0x6e1 [<ffffffff8024908e>] ? blocking_notifier_call_chain+0xf/0x11 [<ffffffff80236d87>] do_exit+0x78/0x720 [<ffffffff8054fcc1>] ? do_page_fault+0x490/0x816 [<ffffffff802374a1>] do_group_exit+0x72/0xa2 [<ffffffff802374e3>] sys_exit_group+0x12/0x14 [<ffffffff8020be8b>] system_call_after_swapgs+0x7b/0x80 .config attached. Full boot log also available. --- ~Randy '"Daemon' is an old piece of jargon from the UNIX operating system, where it referred to a piece of low-level utility software, a fundamental part of the operating system." [-- Attachment #2: kconfig.next.panic --] [-- Type: application/octet-stream, Size: 46759 bytes --] # # Automatically generated make config: don't edit # Linux kernel version: 2.6.26-rc6 # Fri Jun 13 14:52:42 2008 # CONFIG_64BIT=y # CONFIG_X86_32 is not set CONFIG_X86_64=y CONFIG_X86=y CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" # CONFIG_GENERIC_LOCKBREAK is not set CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y # CONFIG_GENERIC_GPIO is not set CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_RWSEM_XCHGADD_ALGORITHM is not set # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_HAVE_CPUMASK_OF_CPU_MAP=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ZONE_DMA32=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_AOUT=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_X86_SMP=y CONFIG_X86_64_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y # CONFIG_KTIME_SCALAR is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_TREE=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=18 # CONFIG_CGROUPS is not set CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y # CONFIG_GROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_RELAY=y # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_SYSCTL_SYSCALL_CHECK=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_COMPAT_BRK=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_PROFILING=y # CONFIG_MARKERS is not set CONFIG_OPROFILE=m CONFIG_HAVE_OPROFILE=y CONFIG_KPROBES=y CONFIG_KRETPROBES=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y # CONFIG_HAVE_DMA_ATTRS is not set CONFIG_USE_GENERIC_SMP_HELPERS=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_BLK_DEV_IO_TRACE=y CONFIG_BLK_DEV_BSG=y CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" CONFIG_CLASSIC_RCU=y # # Processor type and features # # CONFIG_TICK_ONESHOT is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_RDC321X is not set # CONFIG_X86_VSMP is not set # CONFIG_PARAVIRT_GUEST is not set CONFIG_MEMTEST=y # 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 is not set # 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_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set CONFIG_GENERIC_CPU=y CONFIG_X86_CPU=y CONFIG_X86_L1_CACHE_BYTES=128 CONFIG_X86_INTERNODE_CACHE_BYTES=128 CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_GOOD_APIC=y CONFIG_X86_TSC=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=64 CONFIG_X86_DEBUGCTLMSR=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_DMI=y CONFIG_GART_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_SWIOTLB=y CONFIG_IOMMU_HELPER=y # CONFIG_MAXSMP is not set CONFIG_NR_CPUS=8 # CONFIG_SCHED_SMT is not set CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_INTEL=y CONFIG_X86_MCE_AMD=y # CONFIG_I8K is not set CONFIG_MICROCODE=y CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_NUMA=y CONFIG_K8_NUMA=y CONFIG_X86_64_ACPI_NUMA=y CONFIG_NODES_SPAN_OTHER_NODES=y # CONFIG_NUMA_EMU is not set CONFIG_NODES_SHIFT=6 CONFIG_ARCH_SPARSEMEM_DEFAULT=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_ILLEGAL_POINTER_VALUE=0xffffc10000000000 CONFIG_SELECT_MEMORY_MODEL=y # CONFIG_FLATMEM_MANUAL is not set # CONFIG_DISCONTIGMEM_MANUAL is not set CONFIG_SPARSEMEM_MANUAL=y CONFIG_SPARSEMEM=y CONFIG_NEED_MULTIPLE_NODES=y CONFIG_HAVE_MEMORY_PRESENT=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPARSEMEM_EXTREME=y CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y CONFIG_SPARSEMEM_VMEMMAP=y # # Memory hotplug is currently incompatible with Software Suspend # CONFIG_PAGEFLAGS_EXTENDED=y CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_MIGRATION=y CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_VIRT_TO_BUS=y CONFIG_MTRR=y CONFIG_MTRR_SANITIZER=y CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0 CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1 # CONFIG_X86_PAT is not set # CONFIG_EFI is not set # CONFIG_SECCOMP is not set # CONFIG_CC_STACKPROTECTOR is not set # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250 # CONFIG_SCHED_HRTICK is not set CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y CONFIG_PHYSICAL_START=0x200000 # CONFIG_RELOCATABLE is not set CONFIG_PHYSICAL_ALIGN=0x200000 CONFIG_HOTPLUG_CPU=y CONFIG_COMPAT_VDSO=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID=y # # Power management options # CONFIG_ARCH_HIBERNATION_HEADER=y CONFIG_PM=y # CONFIG_PM_DEBUG is not set CONFIG_PM_SLEEP_SMP=y CONFIG_PM_SLEEP=y CONFIG_SUSPEND=y CONFIG_SUSPEND_FREEZER=y CONFIG_HIBERNATION=y CONFIG_PM_STD_PARTITION="" CONFIG_ACPI=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_PROCFS=y CONFIG_ACPI_PROCFS_POWER=y CONFIG_ACPI_SYSFS_POWER=y CONFIG_ACPI_PROC_EVENT=y CONFIG_ACPI_AC=y # CONFIG_ACPI_BATTERY is not set CONFIG_ACPI_BUTTON=y CONFIG_ACPI_FAN=y # CONFIG_ACPI_DOCK is not set CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_HOTPLUG_CPU=y CONFIG_ACPI_THERMAL=y CONFIG_ACPI_NUMA=y # CONFIG_ACPI_WMI is not set # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_TOSHIBA is not set # CONFIG_ACPI_CUSTOM_DSDT is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_EC=y # CONFIG_ACPI_PCI_SLOT is not set CONFIG_ACPI_POWER=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y CONFIG_ACPI_CONTAINER=y # CONFIG_ACPI_SBS is not set # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y CONFIG_CPU_FREQ_DEBUG=y CONFIG_CPU_FREQ_STAT=y CONFIG_CPU_FREQ_STAT_DETAILS=y # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set 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 # # CPUFreq processor drivers # CONFIG_X86_ACPI_CPUFREQ=y CONFIG_X86_POWERNOW_K8=y CONFIG_X86_POWERNOW_K8_ACPI=y CONFIG_X86_SPEEDSTEP_CENTRINO=y CONFIG_X86_P4_CLOCKMOD=y # # shared options # CONFIG_X86_ACPI_CPUFREQ_PROC_INTF=y CONFIG_X86_SPEEDSTEP_LIB=y CONFIG_CPU_IDLE=y CONFIG_CPU_IDLE_GOV_LADDER=y # # Bus options (PCI etc.) # CONFIG_PCI=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_DOMAINS=y # CONFIG_DMAR is not set CONFIG_PCIEPORTBUS=y # CONFIG_PCIEAER is not set # CONFIG_PCIEASPM is not set CONFIG_ARCH_SUPPORTS_MSI=y CONFIG_PCI_MSI=y CONFIG_PCI_LEGACY=y # CONFIG_PCI_DEBUG is not set CONFIG_HT_IRQ=y CONFIG_ISA_DMA_API=y CONFIG_K8_NB=y # CONFIG_PCCARD is not set # CONFIG_HOTPLUG_PCI is not set # # Executable file formats / Emulations # CONFIG_BINFMT_ELF=y CONFIG_COMPAT_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_IA32_EMULATION=y CONFIG_IA32_AOUT=y CONFIG_COMPAT=y CONFIG_COMPAT_FOR_U64_ALIGNMENT=y CONFIG_SYSVIPC_COMPAT=y # # Networking # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_XFRM=y CONFIG_XFRM_USER=y # CONFIG_XFRM_SUB_POLICY is not set # CONFIG_XFRM_MIGRATE is not set # CONFIG_XFRM_STATISTICS is not set CONFIG_NET_KEY=y # CONFIG_NET_KEY_MIGRATE is not set CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_ASK_IP_FIB_HASH=y # CONFIG_IP_FIB_TRIE is not set CONFIG_IP_FIB_HASH=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_VERBOSE=y # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=y CONFIG_NET_IPGRE=y CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y # CONFIG_ARPD is not set CONFIG_SYN_COOKIES=y CONFIG_INET_AH=y CONFIG_INET_ESP=y CONFIG_INET_IPCOMP=y CONFIG_INET_XFRM_TUNNEL=y CONFIG_INET_TUNNEL=y CONFIG_INET_XFRM_MODE_TRANSPORT=y CONFIG_INET_XFRM_MODE_TUNNEL=y CONFIG_INET_XFRM_MODE_BEET=y # CONFIG_INET_LRO is not set CONFIG_INET_DIAG=y CONFIG_INET_TCP_DIAG=y CONFIG_TCP_CONG_ADVANCED=y CONFIG_TCP_CONG_BIC=y CONFIG_TCP_CONG_CUBIC=m CONFIG_TCP_CONG_WESTWOOD=m CONFIG_TCP_CONG_HTCP=m CONFIG_TCP_CONG_HSTCP=m CONFIG_TCP_CONG_HYBLA=m CONFIG_TCP_CONG_VEGAS=m CONFIG_TCP_CONG_SCALABLE=m CONFIG_TCP_CONG_LP=m CONFIG_TCP_CONG_VENO=m CONFIG_TCP_CONG_YEAH=m CONFIG_TCP_CONG_ILLINOIS=m CONFIG_DEFAULT_BIC=y # CONFIG_DEFAULT_CUBIC is not set # CONFIG_DEFAULT_HTCP is not set # CONFIG_DEFAULT_VEGAS is not set # CONFIG_DEFAULT_WESTWOOD is not set # CONFIG_DEFAULT_RENO is not set CONFIG_DEFAULT_TCP_CONG="bic" # CONFIG_TCP_MD5SIG is not set # CONFIG_IPV6 is not set # CONFIG_NETWORK_SECMARK is not set # CONFIG_NETFILTER is not set # CONFIG_IP_DCCP is not set # CONFIG_IP_SCTP is not set # CONFIG_TIPC is not set # CONFIG_ATM is not set # CONFIG_BRIDGE is not set # CONFIG_VLAN_8021Q is not set # CONFIG_DECNET is not set # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_SCHED is not set # # Network testing # # CONFIG_NET_PKTGEN is not set # CONFIG_NET_TCPPROBE is not set # CONFIG_HAMRADIO is not set # CONFIG_CAN is not set # CONFIG_IRDA is not set # CONFIG_BT is not set # CONFIG_AF_RXRPC is not set CONFIG_FIB_RULES=y # # Wireless # # CONFIG_CFG80211 is not set # CONFIG_WIRELESS_EXT is not set # CONFIG_MAC80211 is not set # CONFIG_IEEE80211 is not set # CONFIG_RFKILL is not set # CONFIG_NET_9P is not set # # Device Drivers # # # Generic Driver Options # CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y CONFIG_BUILTIN_FIRMWARE="" # CONFIG_DEBUG_DRIVER is not set # CONFIG_DEBUG_DEVRES is not set # CONFIG_SYS_HYPERVISOR is not set CONFIG_CONNECTOR=y CONFIG_PROC_EVENTS=y # CONFIG_MTD is not set CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_SERIAL=m # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_GSC is not set # CONFIG_PARPORT_AX88796 is not set CONFIG_PARPORT_1284=y CONFIG_PNP=y # CONFIG_PNP_DEBUG is not set # # Protocols # CONFIG_PNPACPI=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_FD=y # CONFIG_PARIDE is not set CONFIG_BLK_CPQ_DA=m CONFIG_BLK_CPQ_CISS_DA=m # CONFIG_CISS_SCSI_TAPE is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_CRYPTOLOOP=m # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_SX8 is not set # CONFIG_BLK_DEV_UB is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=16384 # CONFIG_BLK_DEV_XIP is not set CONFIG_CDROM_PKTCDVD=m CONFIG_CDROM_PKTCDVD_BUFFERS=8 # CONFIG_CDROM_PKTCDVD_WCACHE is not set # CONFIG_ATA_OVER_ETH is not set # CONFIG_MISC_DEVICES is not set CONFIG_HAVE_IDE=y # CONFIG_IDE is not set # # SCSI device support # CONFIG_RAID_ATTRS=y CONFIG_SCSI=y CONFIG_SCSI_DMA=y CONFIG_SCSI_TGT=y CONFIG_SCSI_NETLINK=y CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=m CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=y CONFIG_CHR_DEV_SCH=m # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y # CONFIG_SCSI_SCAN_ASYNC is not set CONFIG_SCSI_WAIT_SCAN=m # # SCSI Transports # CONFIG_SCSI_SPI_ATTRS=y CONFIG_SCSI_FC_ATTRS=y # CONFIG_SCSI_FC_TGT_ATTRS is not set CONFIG_SCSI_ISCSI_ATTRS=y CONFIG_SCSI_SAS_ATTRS=y CONFIG_SCSI_SAS_LIBSAS=y CONFIG_SCSI_SAS_HOST_SMP=y # CONFIG_SCSI_SAS_LIBSAS_DEBUG is not set # CONFIG_SCSI_SRP_ATTRS is not set CONFIG_SCSI_LOWLEVEL=y # CONFIG_ISCSI_TCP is not set # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_3W_9XXX is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AACRAID is not set CONFIG_SCSI_AIC7XXX=m CONFIG_AIC7XXX_CMDS_PER_DEVICE=4 CONFIG_AIC7XXX_RESET_DELAY_MS=15000 # CONFIG_AIC7XXX_DEBUG_ENABLE is not set CONFIG_AIC7XXX_DEBUG_MASK=0 # CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set CONFIG_SCSI_AIC7XXX_OLD=m CONFIG_SCSI_AIC79XX=m CONFIG_AIC79XX_CMDS_PER_DEVICE=4 CONFIG_AIC79XX_RESET_DELAY_MS=15000 # CONFIG_AIC79XX_DEBUG_ENABLE is not set CONFIG_AIC79XX_DEBUG_MASK=0 # CONFIG_AIC79XX_REG_PRETTY_PRINT is not set CONFIG_SCSI_AIC94XX=m # CONFIG_AIC94XX_DEBUG is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_ADVANSYS is not set CONFIG_SCSI_ARCMSR=m # CONFIG_MEGARAID_NEWGEN is not set # CONFIG_MEGARAID_LEGACY is not set # CONFIG_MEGARAID_SAS is not set # CONFIG_SCSI_HPTIOP is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set CONFIG_SCSI_PPA=m CONFIG_SCSI_IMM=m # CONFIG_SCSI_IZIP_EPP16 is not set # CONFIG_SCSI_IZIP_SLOW_CTR is not set # CONFIG_SCSI_MVSAS is not set # CONFIG_SCSI_STEX is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_QLOGIC_1280 is not set # CONFIG_SCSI_QLA_FC is not set # CONFIG_SCSI_QLA_ISCSI is not set # CONFIG_SCSI_LPFC is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_DEBUG is not set CONFIG_SCSI_SRP=y # CONFIG_SCSI_DH is not set # CONFIG_ATA is not set # CONFIG_MD is not set # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support # # CONFIG_FIREWIRE is not set CONFIG_IEEE1394=m # # Subsystem Options # CONFIG_IEEE1394_VERBOSEDEBUG=y # # Controllers # CONFIG_IEEE1394_PCILYNX=m CONFIG_IEEE1394_OHCI1394=m # # Protocols # CONFIG_IEEE1394_VIDEO1394=m CONFIG_IEEE1394_SBP2=m # CONFIG_IEEE1394_SBP2_PHYS_DMA is not set CONFIG_IEEE1394_ETH1394_ROM_ENTRY=y CONFIG_IEEE1394_ETH1394=m CONFIG_IEEE1394_DV1394=m CONFIG_IEEE1394_RAWIO=m # CONFIG_I2O is not set # CONFIG_MACINTOSH_DRIVERS is not set CONFIG_NETDEVICES=y # CONFIG_NETDEVICES_MULTIQUEUE is not set CONFIG_DUMMY=m # CONFIG_BONDING is not set # CONFIG_MACVLAN is not set # CONFIG_EQUALIZER is not set CONFIG_TUN=y # CONFIG_VETH is not set # CONFIG_NET_SB1000 is not set # CONFIG_ARCNET is not set CONFIG_PHYLIB=y # # MII PHY device drivers # CONFIG_MARVELL_PHY=m CONFIG_DAVICOM_PHY=m CONFIG_QSEMI_PHY=m CONFIG_LXT_PHY=m CONFIG_CICADA_PHY=m CONFIG_VITESSE_PHY=m CONFIG_SMSC_PHY=m # CONFIG_BROADCOM_PHY is not set # CONFIG_ICPLUS_PHY is not set # CONFIG_REALTEK_PHY is not set # CONFIG_FIXED_PHY is not set # CONFIG_MDIO_BITBANG is not set CONFIG_NET_ETHERNET=y CONFIG_MII=y # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set # CONFIG_CASSINI is not set # CONFIG_NET_VENDOR_3COM is not set # CONFIG_NET_TULIP is not set # CONFIG_HP100 is not set # CONFIG_IBM_NEW_EMAC_ZMII is not set # CONFIG_IBM_NEW_EMAC_RGMII is not set # CONFIG_IBM_NEW_EMAC_TAH is not set # CONFIG_IBM_NEW_EMAC_EMAC4 is not set CONFIG_NET_PCI=y CONFIG_PCNET32=m CONFIG_AMD8111_ETH=m CONFIG_AMD8111E_NAPI=y # CONFIG_ADAPTEC_STARFIRE is not set CONFIG_B44=y CONFIG_B44_PCI_AUTOSELECT=y CONFIG_B44_PCICORE_AUTOSELECT=y CONFIG_B44_PCI=y CONFIG_FORCEDETH=m CONFIG_FORCEDETH_NAPI=y # CONFIG_EEPRO100 is not set CONFIG_E100=m # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_8139CP is not set # CONFIG_8139TOO is not set # CONFIG_R6040 is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set CONFIG_VIA_RHINE=m CONFIG_VIA_RHINE_MMIO=y CONFIG_VIA_RHINE_NAPI=y # CONFIG_SC92031 is not set # CONFIG_NET_POCKET is not set CONFIG_NETDEV_1000=y # CONFIG_ACENIC is not set # CONFIG_DL2K is not set CONFIG_E1000=m CONFIG_E1000_NAPI=y CONFIG_E1000_DISABLE_PACKET_SPLIT=y # CONFIG_E1000E is not set # CONFIG_E1000E_ENABLED is not set # CONFIG_IP1000 is not set # CONFIG_IGB is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set # CONFIG_SIS190 is not set # CONFIG_SKGE is not set # CONFIG_SKY2 is not set CONFIG_VIA_VELOCITY=m CONFIG_TIGON3=m CONFIG_BNX2=y # CONFIG_QLA3XXX is not set # CONFIG_ATL1 is not set # CONFIG_NETDEV_10000 is not set # CONFIG_TR is not set # # Wireless LAN # # CONFIG_WLAN_PRE80211 is not set # CONFIG_WLAN_80211 is not set # CONFIG_IWLWIFI_LEDS is not set # # USB Network Adapters # # CONFIG_USB_CATC is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_USBNET is not set # CONFIG_WAN is not set CONFIG_FDDI=y # CONFIG_DEFXX is not set # CONFIG_SKFP is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set CONFIG_NET_FC=y CONFIG_NETCONSOLE=y # CONFIG_NETCONSOLE_DYNAMIC is not set CONFIG_NETPOLL=y CONFIG_NETPOLL_TRAP=y CONFIG_NET_POLL_CONTROLLER=y # CONFIG_ISDN is not set # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y CONFIG_INPUT_FF_MEMLESS=y CONFIG_INPUT_POLLDEV=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y # CONFIG_INPUT_MOUSEDEV_PSAUX is not set CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set CONFIG_INPUT_EVDEV=y # CONFIG_INPUT_EVBUG is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set # CONFIG_KEYBOARD_STOWAWAY is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y CONFIG_MOUSE_PS2_ALPS=y CONFIG_MOUSE_PS2_LOGIPS2PP=y CONFIG_MOUSE_PS2_SYNAPTICS=y CONFIG_MOUSE_PS2_LIFEBOOK=y CONFIG_MOUSE_PS2_TRACKPOINT=y # CONFIG_MOUSE_PS2_TOUCHKIT is not set # CONFIG_MOUSE_SERIAL is not set # CONFIG_MOUSE_APPLETOUCH is not set # CONFIG_MOUSE_VSXXXAA is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TABLET is not set # CONFIG_INPUT_TOUCHSCREEN is not set CONFIG_INPUT_MISC=y CONFIG_INPUT_PCSPKR=y # CONFIG_INPUT_ATLAS_BTNS is not set # CONFIG_INPUT_ATI_REMOTE is not set # CONFIG_INPUT_ATI_REMOTE2 is not set # CONFIG_INPUT_KEYSPAN_REMOTE is not set # CONFIG_INPUT_POWERMATE is not set # CONFIG_INPUT_YEALINK is not set CONFIG_INPUT_UINPUT=y # # Hardware I/O ports # CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=y # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PARKBD is not set # CONFIG_SERIO_PCIPS2 is not set CONFIG_SERIO_LIBPS2=y CONFIG_SERIO_RAW=y # CONFIG_GAMEPORT is not set # # Character devices # CONFIG_VT=y CONFIG_CONSOLE_TRANSLATIONS=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y CONFIG_VT_HW_CONSOLE_BINDING=y CONFIG_DEVKMEM=y # CONFIG_SERIAL_NONSTANDARD is not set # CONFIG_NOZOMI is not set # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_SERIAL_8250_PCI=y CONFIG_SERIAL_8250_PNP=y CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 # CONFIG_SERIAL_8250_EXTENDED is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y # CONFIG_SERIAL_JSM is not set CONFIG_UNIX98_PTYS=y # CONFIG_LEGACY_PTYS is not set CONFIG_PRINTER=m CONFIG_LP_CONSOLE=y CONFIG_PPDEV=m CONFIG_IPMI_HANDLER=y CONFIG_IPMI_PANIC_EVENT=y CONFIG_IPMI_PANIC_STRING=y CONFIG_IPMI_DEVICE_INTERFACE=y CONFIG_IPMI_SI=y CONFIG_IPMI_WATCHDOG=y CONFIG_IPMI_POWEROFF=y CONFIG_HW_RANDOM=y CONFIG_HW_RANDOM_INTEL=y CONFIG_HW_RANDOM_AMD=y CONFIG_NVRAM=y # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_MWAVE is not set # CONFIG_PC8736x_GPIO is not set CONFIG_RAW_DRIVER=y CONFIG_MAX_RAW_DEVS=8192 CONFIG_HPET=y # CONFIG_HPET_RTC_IRQ is not set # CONFIG_HPET_MMAP is not set CONFIG_HANGCHECK_TIMER=y # CONFIG_TCG_TPM is not set # CONFIG_TELCLOCK is not set CONFIG_DEVPORT=y CONFIG_I2C=y CONFIG_I2C_BOARDINFO=y CONFIG_I2C_CHARDEV=y CONFIG_I2C_ALGOBIT=y # # I2C Hardware Bus support # # # PC SMBus host controller drivers # # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI1563 is not set # CONFIG_I2C_ALI15X3 is not set CONFIG_I2C_AMD756=y # CONFIG_I2C_AMD756_S4882 is not set CONFIG_I2C_AMD8111=y CONFIG_I2C_I801=y CONFIG_I2C_PIIX4=y CONFIG_I2C_NFORCE2=y # CONFIG_I2C_NFORCE2_S4985 is not set # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_SIS630 is not set # CONFIG_I2C_SIS96X is not set CONFIG_I2C_VIA=y CONFIG_I2C_VIAPRO=y # # Graphics adapter I2C/DDC channel drivers # # CONFIG_I2C_VOODOO3 is not set # # External I2C/SMBus adapter drivers # # CONFIG_I2C_PARPORT is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_TAOS_EVM is not set # CONFIG_I2C_TINY_USB is not set # # Other I2C/SMBus bus drivers # # CONFIG_I2C_ISCH is not set # CONFIG_I2C_OCORES is not set # CONFIG_I2C_SIMTEC is not set # CONFIG_I2C_STUB is not set # CONFIG_I2C_PCA_PLATFORM is not set # # Miscellaneous I2C Chip support # # CONFIG_DS1682 is not set # CONFIG_SENSORS_EEPROM is not set # CONFIG_SENSORS_PCF8574 is not set # CONFIG_PCF8575 is not set # CONFIG_SENSORS_PCF8591 is not set # CONFIG_SENSORS_MAX6875 is not set # CONFIG_SENSORS_TSL2550 is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_I2C_DEBUG_CHIP is not set # CONFIG_SPI is not set # CONFIG_W1 is not set CONFIG_POWER_SUPPLY=y # CONFIG_POWER_SUPPLY_DEBUG is not set # CONFIG_PDA_POWER is not set # CONFIG_BATTERY_DS2760 is not set CONFIG_HWMON=y CONFIG_HWMON_VID=y # CONFIG_SENSORS_ABITUGURU is not set # CONFIG_SENSORS_ABITUGURU3 is not set # CONFIG_SENSORS_AD7418 is not set # CONFIG_SENSORS_ADM1021 is not set # CONFIG_SENSORS_ADM1025 is not set # CONFIG_SENSORS_ADM1026 is not set # CONFIG_SENSORS_ADM1029 is not set # CONFIG_SENSORS_ADM1031 is not set # CONFIG_SENSORS_ADM9240 is not set # CONFIG_SENSORS_ADT7470 is not set # CONFIG_SENSORS_ADT7473 is not set CONFIG_SENSORS_K8TEMP=y # CONFIG_SENSORS_ASB100 is not set # CONFIG_SENSORS_ATXP1 is not set # CONFIG_SENSORS_DS1621 is not set # CONFIG_SENSORS_I5K_AMB is not set # CONFIG_SENSORS_F71805F is not set # CONFIG_SENSORS_F71882FG is not set # CONFIG_SENSORS_F75375S is not set # CONFIG_SENSORS_FSCHER is not set # CONFIG_SENSORS_FSCPOS is not set # CONFIG_SENSORS_FSCHMD is not set # CONFIG_SENSORS_GL518SM is not set # CONFIG_SENSORS_GL520SM is not set CONFIG_SENSORS_CORETEMP=y # CONFIG_SENSORS_IBMAEM is not set # CONFIG_SENSORS_IBMPEX is not set # CONFIG_SENSORS_IT87 is not set # CONFIG_SENSORS_LM63 is not set # CONFIG_SENSORS_LM75 is not set # CONFIG_SENSORS_LM77 is not set # CONFIG_SENSORS_LM78 is not set # CONFIG_SENSORS_LM80 is not set # CONFIG_SENSORS_LM83 is not set # CONFIG_SENSORS_LM85 is not set # CONFIG_SENSORS_LM87 is not set # CONFIG_SENSORS_LM90 is not set # CONFIG_SENSORS_LM92 is not set # CONFIG_SENSORS_LM93 is not set # CONFIG_SENSORS_MAX1619 is not set # CONFIG_SENSORS_MAX6650 is not set # CONFIG_SENSORS_PC87360 is not set # CONFIG_SENSORS_PC87427 is not set # CONFIG_SENSORS_SIS5595 is not set # CONFIG_SENSORS_DME1737 is not set # CONFIG_SENSORS_SMSC47M1 is not set # CONFIG_SENSORS_SMSC47M192 is not set # CONFIG_SENSORS_SMSC47B397 is not set # CONFIG_SENSORS_ADS7828 is not set # CONFIG_SENSORS_THMC50 is not set CONFIG_SENSORS_VIA686A=y CONFIG_SENSORS_VT1211=y CONFIG_SENSORS_VT8231=y # CONFIG_SENSORS_W83781D is not set # CONFIG_SENSORS_W83791D is not set # CONFIG_SENSORS_W83792D is not set # CONFIG_SENSORS_W83793 is not set # CONFIG_SENSORS_W83L785TS is not set # CONFIG_SENSORS_W83L786NG is not set # CONFIG_SENSORS_W83627HF is not set # CONFIG_SENSORS_W83627EHF is not set # CONFIG_SENSORS_HDAPS is not set # CONFIG_SENSORS_APPLESMC is not set # CONFIG_HWMON_DEBUG_CHIP is not set CONFIG_THERMAL=y CONFIG_WATCHDOG=y # CONFIG_WATCHDOG_NOWAYOUT is not set # # Watchdog Device Drivers # CONFIG_SOFT_WATCHDOG=y # CONFIG_ACQUIRE_WDT is not set # CONFIG_ADVANTECH_WDT is not set # CONFIG_ALIM1535_WDT is not set # CONFIG_ALIM7101_WDT is not set # CONFIG_SC520_WDT is not set # CONFIG_EUROTECH_WDT is not set # CONFIG_IB700_WDT is not set # CONFIG_IBMASR is not set # CONFIG_WAFER_WDT is not set # CONFIG_I6300ESB_WDT is not set # CONFIG_ITCO_WDT is not set # CONFIG_IT8712F_WDT is not set # CONFIG_HP_WATCHDOG is not set # CONFIG_SC1200_WDT is not set # CONFIG_PC87413_WDT is not set # CONFIG_60XX_WDT is not set # CONFIG_SBC8360_WDT is not set # CONFIG_CPU5_WDT is not set # CONFIG_SMSC37B787_WDT is not set # CONFIG_W83627HF_WDT is not set # CONFIG_W83697HF_WDT is not set # CONFIG_W83877F_WDT is not set # CONFIG_W83977F_WDT is not set # CONFIG_MACHZ_WDT is not set # CONFIG_SBC_EPX_C3_WATCHDOG is not set # # PCI-based Watchdog Cards # # CONFIG_PCIPCWATCHDOG is not set # CONFIG_WDTPCI is not set # # USB-based Watchdog Cards # # CONFIG_USBPCWATCHDOG is not set # # Sonics Silicon Backplane # CONFIG_SSB_POSSIBLE=y CONFIG_SSB=y CONFIG_SSB_SPROM=y CONFIG_SSB_PCIHOST_POSSIBLE=y CONFIG_SSB_PCIHOST=y # CONFIG_SSB_B43_PCI_BRIDGE is not set # CONFIG_SSB_SILENT is not set # CONFIG_SSB_DEBUG is not set CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y CONFIG_SSB_DRIVER_PCICORE=y # # Multifunction device drivers # # CONFIG_MFD_SM501 is not set # CONFIG_HTC_PASIC3 is not set # # Multimedia devices # # # Multimedia core support # # CONFIG_VIDEO_DEV is not set # CONFIG_DVB_CORE is not set # CONFIG_VIDEO_MEDIA is not set # # Multimedia drivers # # CONFIG_DAB is not set # # Graphics support # CONFIG_AGP=y CONFIG_AGP_AMD64=y CONFIG_AGP_INTEL=y # CONFIG_AGP_SIS is not set CONFIG_AGP_VIA=y CONFIG_DRM=y # CONFIG_DRM_TDFX is not set CONFIG_DRM_R128=y CONFIG_DRM_RADEON=y # CONFIG_DRM_I810 is not set # CONFIG_DRM_I830 is not set # CONFIG_DRM_I915 is not set # CONFIG_DRM_MGA is not set # CONFIG_DRM_SIS is not set CONFIG_DRM_VIA=y # CONFIG_DRM_SAVAGE is not set CONFIG_VGASTATE=y # CONFIG_VIDEO_OUTPUT_CONTROL is not set CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_DDC=y CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y # CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set # CONFIG_FB_SYS_FILLRECT is not set # CONFIG_FB_SYS_COPYAREA is not set # CONFIG_FB_SYS_IMAGEBLIT is not set # CONFIG_FB_FOREIGN_ENDIAN is not set # CONFIG_FB_SYS_FOPS is not set CONFIG_FB_SVGALIB=y # CONFIG_FB_MACMODES is not set CONFIG_FB_BACKLIGHT=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y # # Frame buffer hardware drivers # # CONFIG_FB_CIRRUS is not set # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_ARC is not set # CONFIG_FB_ASILIANT is not set # CONFIG_FB_IMSTT is not set # CONFIG_FB_VGA16 is not set # CONFIG_FB_UVESA is not set CONFIG_FB_VESA=y # CONFIG_FB_EFI is not set # CONFIG_FB_N411 is not set # CONFIG_FB_HGA is not set # CONFIG_FB_S1D13XXX is not set CONFIG_FB_NVIDIA=y CONFIG_FB_NVIDIA_I2C=y # CONFIG_FB_NVIDIA_DEBUG is not set # CONFIG_FB_NVIDIA_BACKLIGHT is not set CONFIG_FB_RIVA=y # CONFIG_FB_RIVA_I2C is not set # CONFIG_FB_RIVA_DEBUG is not set CONFIG_FB_RIVA_BACKLIGHT=y # CONFIG_FB_LE80578 is not set # CONFIG_FB_INTEL is not set # CONFIG_FB_MATROX is not set # CONFIG_FB_RADEON is not set # CONFIG_FB_ATY128 is not set # CONFIG_FB_ATY is not set # CONFIG_FB_S3 is not set # CONFIG_FB_SAVAGE is not set # CONFIG_FB_SIS is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_KYRO is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set CONFIG_FB_VT8623=y # CONFIG_FB_TRIDENT is not set # CONFIG_FB_ARK is not set # CONFIG_FB_PM3 is not set # CONFIG_FB_GEODE is not set # CONFIG_FB_VIRTUAL is not set CONFIG_BACKLIGHT_LCD_SUPPORT=y # CONFIG_LCD_CLASS_DEVICE is not set CONFIG_BACKLIGHT_CLASS_DEVICE=y # CONFIG_BACKLIGHT_CORGI is not set # CONFIG_BACKLIGHT_PROGEAR is not set # CONFIG_BACKLIGHT_MBP_NVIDIA is not set # # Display device support # # CONFIG_DISPLAY_SUPPORT is not set # # Console display driver support # CONFIG_VGA_CONSOLE=y CONFIG_VGACON_SOFT_SCROLLBACK=y CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64 CONFIG_VIDEO_SELECT=y CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y # CONFIG_FONTS is not set CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y # CONFIG_LOGO is not set # CONFIG_SOUND is not set CONFIG_HID_SUPPORT=y CONFIG_HID=y CONFIG_HID_DEBUG=y # CONFIG_HIDRAW is not set # # USB Input Devices # CONFIG_USB_HID=y # CONFIG_USB_HIDINPUT_POWERBOOK is not set # CONFIG_HID_FF is not set CONFIG_USB_HIDDEV=y CONFIG_USB_SUPPORT=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB_ARCH_HAS_EHCI=y CONFIG_USB=y # CONFIG_USB_DEBUG is not set # CONFIG_USB_ANNOUNCE_NEW_DEVICES is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y CONFIG_USB_DEVICE_CLASS=y # CONFIG_USB_DYNAMIC_MINORS is not set # CONFIG_USB_SUSPEND is not set # CONFIG_USB_OTG is not set # CONFIG_USB_OTG_WHITELIST is not set # CONFIG_USB_OTG_BLACKLIST_HUB is not set # CONFIG_USB_WUSB is not set # # USB Host Controller Drivers # # CONFIG_USB_C67X00_HCD is not set CONFIG_USB_EHCI_HCD=m CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_USB_EHCI_TT_NEWSCHED=y # CONFIG_USB_ISP116X_HCD is not set # CONFIG_USB_ISP1760_HCD is not set CONFIG_USB_OHCI_HCD=m # CONFIG_USB_OHCI_HCD_SSB is not set # CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set # CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set CONFIG_USB_OHCI_LITTLE_ENDIAN=y CONFIG_USB_UHCI_HCD=m # CONFIG_USB_SL811_HCD is not set # CONFIG_USB_R8A66597_HCD is not set # CONFIG_USB_WHCI_HCD is not set # CONFIG_USB_HWA_HCD is not set # # USB Device Class drivers # # CONFIG_USB_ACM is not set CONFIG_USB_PRINTER=m # CONFIG_USB_WDM is not set # # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' # # # may also be needed; see USB_STORAGE Help for more information # CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_DPCM is not set # CONFIG_USB_STORAGE_USBAT is not set # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # CONFIG_USB_STORAGE_ALAUDA is not set # CONFIG_USB_STORAGE_ONETOUCH is not set # CONFIG_USB_STORAGE_KARMA is not set # CONFIG_USB_STORAGE_CYPRESS_ATACB is not set # CONFIG_USB_LIBUSUAL is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # CONFIG_USB_MICROTEK is not set CONFIG_USB_MON=y # # USB port drivers # # CONFIG_USB_USS720 is not set CONFIG_USB_SERIAL=m # CONFIG_USB_EZUSB is not set CONFIG_USB_SERIAL_GENERIC=y # CONFIG_USB_SERIAL_AIRCABLE is not set # CONFIG_USB_SERIAL_AIRPRIME is not set # CONFIG_USB_SERIAL_ARK3116 is not set CONFIG_USB_SERIAL_BELKIN=m # CONFIG_USB_SERIAL_CH341 is not set # CONFIG_USB_SERIAL_WHITEHEAT is not set # CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set # CONFIG_USB_SERIAL_CP2101 is not set # CONFIG_USB_SERIAL_CYPRESS_M8 is not set # CONFIG_USB_SERIAL_EMPEG is not set # CONFIG_USB_SERIAL_FTDI_SIO is not set # CONFIG_USB_SERIAL_FUNSOFT is not set # CONFIG_USB_SERIAL_VISOR is not set # CONFIG_USB_SERIAL_IPAQ is not set # CONFIG_USB_SERIAL_IR is not set # CONFIG_USB_SERIAL_EDGEPORT is not set # CONFIG_USB_SERIAL_EDGEPORT_TI is not set # CONFIG_USB_SERIAL_GARMIN is not set # CONFIG_USB_SERIAL_IPW is not set # CONFIG_USB_SERIAL_IUU is not set # CONFIG_USB_SERIAL_KEYSPAN_PDA is not set # CONFIG_USB_SERIAL_KEYSPAN_PDA_FIRMWARE is not set # CONFIG_USB_SERIAL_KEYSPAN is not set # CONFIG_USB_SERIAL_KLSI is not set # CONFIG_USB_SERIAL_KOBIL_SCT is not set # CONFIG_USB_SERIAL_MCT_U232 is not set # CONFIG_USB_SERIAL_MOS7720 is not set # CONFIG_USB_SERIAL_MOS7840 is not set # CONFIG_USB_SERIAL_MOTOROLA is not set # CONFIG_USB_SERIAL_NAVMAN is not set # CONFIG_USB_SERIAL_PL2303 is not set # CONFIG_USB_SERIAL_OTI6858 is not set # CONFIG_USB_SERIAL_SPCP8X5 is not set # CONFIG_USB_SERIAL_HP4X is not set # CONFIG_USB_SERIAL_SAFE is not set # CONFIG_USB_SERIAL_SIERRAWIRELESS is not set # CONFIG_USB_SERIAL_TI is not set # CONFIG_USB_SERIAL_CYBERJACK is not set # CONFIG_USB_SERIAL_XIRCOM is not set # CONFIG_USB_SERIAL_XIRCOM_FIRMWARE is not set # CONFIG_USB_SERIAL_OPTION is not set # CONFIG_USB_SERIAL_OMNINET is not set # CONFIG_USB_SERIAL_DEBUG is not set # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_ADUTUX is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_BERRY_CHARGE is not set # CONFIG_USB_LED is not set # CONFIG_USB_CYPRESS_CY7C63 is not set # CONFIG_USB_CYTHERM is not set # CONFIG_USB_PHIDGET is not set # CONFIG_USB_IDMOUSE is not set # CONFIG_USB_FTDI_ELAN is not set # CONFIG_USB_APPLEDISPLAY is not set # CONFIG_USB_SISUSBVGA is not set # CONFIG_USB_LD is not set # CONFIG_USB_TRANCEVIBRATOR is not set # CONFIG_USB_IOWARRIOR is not set # CONFIG_USB_TEST is not set # CONFIG_USB_ISIGHTFW is not set # CONFIG_USB_GOTEMP is not set # CONFIG_USB_GADGET is not set # CONFIG_UWB is not set # CONFIG_MMC is not set # CONFIG_MEMSTICK is not set # CONFIG_NEW_LEDS is not set # CONFIG_ACCESSIBILITY is not set # CONFIG_INFINIBAND is not set CONFIG_EDAC=y # # Reporting subsystems # # CONFIG_EDAC_DEBUG is not set CONFIG_EDAC_MM_EDAC=y CONFIG_EDAC_E752X=y CONFIG_EDAC_I82975X=y # CONFIG_EDAC_I3000 is not set CONFIG_EDAC_I5000=y CONFIG_RTC_LIB=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_HCTOSYS_DEVICE="rtc0" # CONFIG_RTC_DEBUG is not set # # RTC interfaces # CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_PROC=y CONFIG_RTC_INTF_DEV=y # CONFIG_RTC_INTF_DEV_UIE_EMUL is not set # CONFIG_RTC_DRV_TEST is not set # # I2C RTC drivers # # CONFIG_RTC_DRV_DS1307 is not set # CONFIG_RTC_DRV_DS1374 is not set # CONFIG_RTC_DRV_DS1672 is not set # CONFIG_RTC_DRV_MAX6900 is not set # CONFIG_RTC_DRV_RS5C372 is not set # CONFIG_RTC_DRV_ISL1208 is not set # CONFIG_RTC_DRV_X1205 is not set # CONFIG_RTC_DRV_PCF8563 is not set # CONFIG_RTC_DRV_PCF8583 is not set # CONFIG_RTC_DRV_M41T80 is not set # CONFIG_RTC_DRV_S35390A is not set # # SPI RTC drivers # # # Platform RTC drivers # CONFIG_RTC_DRV_CMOS=y # CONFIG_RTC_DRV_DS1511 is not set # CONFIG_RTC_DRV_DS1553 is not set # CONFIG_RTC_DRV_DS1742 is not set # CONFIG_RTC_DRV_STK17TA8 is not set # CONFIG_RTC_DRV_M48T86 is not set # CONFIG_RTC_DRV_M48T59 is not set # CONFIG_RTC_DRV_V3020 is not set # # on-CPU RTC drivers # # CONFIG_DMADEVICES is not set # CONFIG_AUXDISPLAY is not set # CONFIG_UIO is not set # # Firmware Drivers # CONFIG_EDD=y # CONFIG_EDD_OFF is not set # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set CONFIG_DMIID=y # CONFIG_ISCSI_IBFT_FIND is not set # # File systems # CONFIG_EXT2_FS=y CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y CONFIG_EXT2_FS_XIP=y CONFIG_FS_XIP=y CONFIG_EXT3_FS=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y # CONFIG_EXT4DEV_FS is not set CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set CONFIG_FS_MBCACHE=y CONFIG_REISERFS_FS=m # CONFIG_REISERFS_CHECK is not set # CONFIG_REISERFS_PROC_INFO is not set # CONFIG_REISERFS_FS_XATTR is not set CONFIG_JFS_FS=m # CONFIG_JFS_POSIX_ACL is not set # CONFIG_JFS_SECURITY is not set # CONFIG_JFS_DEBUG is not set CONFIG_JFS_STATISTICS=y CONFIG_FS_POSIX_ACL=y CONFIG_XFS_FS=m # CONFIG_XFS_QUOTA is not set # CONFIG_XFS_POSIX_ACL is not set # CONFIG_XFS_RT is not set # CONFIG_XFS_DEBUG is not set # CONFIG_GFS2_FS is not set CONFIG_OCFS2_FS=m CONFIG_OCFS2_FS_O2CB=m CONFIG_OCFS2_FS_STATS=y CONFIG_OCFS2_DEBUG_MASKLOG=y # CONFIG_OCFS2_DEBUG_FS is not set CONFIG_DNOTIFY=y CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y # CONFIG_QUOTA is not set # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # CONFIG_FUSE_FS is not set # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_UDF_FS=m CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="ascii" CONFIG_NTFS_FS=m # CONFIG_NTFS_DEBUG is not set # CONFIG_NTFS_RW is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_VMCORE=y CONFIG_PROC_SYSCTL=y CONFIG_SYSFS=y CONFIG_TMPFS=y # CONFIG_TMPFS_POSIX_ACL is not set CONFIG_HUGETLBFS=y CONFIG_HUGETLB_PAGE=y CONFIG_CONFIGFS_FS=y # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set CONFIG_CRAMFS=m # CONFIG_VXFS_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_ROMFS_FS is not set CONFIG_SYSV_FS=m CONFIG_UFS_FS=m # CONFIG_UFS_FS_WRITE is not set # CONFIG_UFS_DEBUG is not set CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=y CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y # CONFIG_NFS_V4 is not set CONFIG_NFSD=y CONFIG_NFSD_V2_ACL=y CONFIG_NFSD_V3=y CONFIG_NFSD_V3_ACL=y # CONFIG_NFSD_V4 is not set CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=y CONFIG_NFS_ACL_SUPPORT=y CONFIG_NFS_COMMON=y CONFIG_SUNRPC=y CONFIG_SUNRPC_GSS=y CONFIG_SUNRPC_BIND34=y CONFIG_RPCSEC_GSS_KRB5=y CONFIG_RPCSEC_GSS_SPKM3=y # CONFIG_SMB_FS is not set # CONFIG_CIFS is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set # CONFIG_OSF_PARTITION is not set # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set # CONFIG_MAC_PARTITION is not set CONFIG_MSDOS_PARTITION=y # CONFIG_BSD_DISKLABEL is not set # CONFIG_MINIX_SUBPARTITION is not set # CONFIG_SOLARIS_X86_PARTITION is not set # CONFIG_UNIXWARE_DISKLABEL is not set # CONFIG_LDM_PARTITION is not set # CONFIG_SGI_PARTITION is not set # CONFIG_ULTRIX_PARTITION is not set # CONFIG_SUN_PARTITION is not set # CONFIG_KARMA_PARTITION is not set CONFIG_EFI_PARTITION=y # CONFIG_SYSV68_PARTITION is not set CONFIG_NLS=y CONFIG_NLS_DEFAULT="utf8" CONFIG_NLS_CODEPAGE_437=y # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set CONFIG_NLS_CODEPAGE_850=y # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set CONFIG_NLS_ISO8859_15=y # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_UTF8=y # CONFIG_DLM is not set # # Kernel hacking # CONFIG_TRACE_IRQFLAGS_SUPPORT=y # CONFIG_PRINTK_TIME is not set CONFIG_ENABLE_WARN_DEPRECATED=y CONFIG_ENABLE_MUST_CHECK=y CONFIG_FRAME_WARN=2048 CONFIG_MAGIC_SYSRQ=y # CONFIG_UNUSED_SYMBOLS is not set CONFIG_DEBUG_FS=y # CONFIG_HEADERS_CHECK is not set CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_SHIRQ is not set CONFIG_DETECT_SOFTLOCKUP=y # CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0 # CONFIG_SCHED_DEBUG is not set CONFIG_SCHEDSTATS=y CONFIG_TIMER_STATS=y # CONFIG_DEBUG_OBJECTS is not set # CONFIG_SLUB_DEBUG_ON is not set # CONFIG_SLUB_STATS is not set # CONFIG_DEBUG_RT_MUTEXES is not set # CONFIG_DEBUG_SPINLOCK is not set CONFIG_DEBUG_MUTEXES=y # CONFIG_DEBUG_LOCK_ALLOC is not set # CONFIG_PROVE_LOCKING is not set # CONFIG_LOCK_STAT is not set CONFIG_DEBUG_SPINLOCK_SLEEP=y CONFIG_STACKTRACE=y # CONFIG_DEBUG_KOBJECT is not set CONFIG_DEBUG_BUGVERBOSE=y CONFIG_DEBUG_INFO=y # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_WRITECOUNT is not set CONFIG_DEBUG_LIST=y # CONFIG_DEBUG_SG is not set CONFIG_FRAME_POINTER=y # CONFIG_BOOT_PRINTK_DELAY is not set # CONFIG_FAULT_INJECTION is not set # CONFIG_LATENCYTOP is not set CONFIG_HAVE_FTRACE=y CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_TRACING=y # CONFIG_FTRACE is not set # CONFIG_IRQSOFF_TRACER is not set # CONFIG_SYSPROF_TRACER is not set # CONFIG_SCHED_TRACER is not set # CONFIG_CONTEXT_SWITCH_TRACER is not set # CONFIG_FTRACE_STARTUP_TEST is not set # CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set # CONFIG_SAMPLES is not set CONFIG_HAVE_ARCH_KGDB=y # CONFIG_KGDB is not set # CONFIG_KERNEL_TESTS is not set # CONFIG_NONPROMISC_DEVMEM is not set CONFIG_EARLY_PRINTK=y CONFIG_DEBUG_STACKOVERFLOW=y CONFIG_DEBUG_STACK_USAGE=y # CONFIG_DEBUG_PAGEALLOC is not set # CONFIG_DEBUG_PER_CPU_MAPS is not set # CONFIG_X86_PTDUMP is not set CONFIG_DEBUG_RODATA=y # CONFIG_DIRECT_GBPAGES is not set CONFIG_DEBUG_RODATA_TEST=y # CONFIG_DEBUG_NX_TEST is not set CONFIG_X86_MPPARSE=y # CONFIG_IOMMU_DEBUG is not set CONFIG_MMIOTRACE_HOOKS=y CONFIG_MMIOTRACE=y # CONFIG_MMIOTRACE_TEST is not set CONFIG_IO_DELAY_TYPE_0X80=0 CONFIG_IO_DELAY_TYPE_0XED=1 CONFIG_IO_DELAY_TYPE_UDELAY=2 CONFIG_IO_DELAY_TYPE_NONE=3 CONFIG_IO_DELAY_0X80=y # CONFIG_IO_DELAY_0XED is not set # CONFIG_IO_DELAY_UDELAY is not set # CONFIG_IO_DELAY_NONE is not set CONFIG_DEFAULT_IO_DELAY_TYPE=0 # CONFIG_DEBUG_BOOT_PARAMS is not set # CONFIG_CPA_DEBUG is not set # # Security options # # CONFIG_KEYS is not set # CONFIG_SECURITY is not set # CONFIG_SECURITY_FILE_CAPABILITIES is not set CONFIG_CRYPTO=y # # Crypto core or helper # CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_AEAD=y CONFIG_CRYPTO_BLKCIPHER=y CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_MANAGER=y # CONFIG_CRYPTO_GF128MUL is not set # CONFIG_CRYPTO_NULL is not set # CONFIG_CRYPTO_CRYPTD is not set CONFIG_CRYPTO_AUTHENC=y # CONFIG_CRYPTO_TEST is not set # # Authenticated Encryption with Associated Data # # CONFIG_CRYPTO_CCM is not set # CONFIG_CRYPTO_GCM is not set # CONFIG_CRYPTO_SEQIV is not set # # Block modes # CONFIG_CRYPTO_CBC=y # CONFIG_CRYPTO_CTR is not set # CONFIG_CRYPTO_CTS is not set # CONFIG_CRYPTO_ECB is not set # CONFIG_CRYPTO_LRW is not set # CONFIG_CRYPTO_PCBC is not set # CONFIG_CRYPTO_XTS is not set # # Hash modes # CONFIG_CRYPTO_HMAC=y # CONFIG_CRYPTO_XCBC is not set # # Digest # CONFIG_CRYPTO_CRC32C=y # CONFIG_CRYPTO_MD4 is not set CONFIG_CRYPTO_MD5=y # CONFIG_CRYPTO_MICHAEL_MIC is not set # CONFIG_CRYPTO_RMD128 is not set # CONFIG_CRYPTO_RMD160 is not set # CONFIG_CRYPTO_RMD256 is not set # CONFIG_CRYPTO_RMD320 is not set CONFIG_CRYPTO_SHA1=y # CONFIG_CRYPTO_SHA256 is not set # CONFIG_CRYPTO_SHA512 is not set # CONFIG_CRYPTO_TGR192 is not set # CONFIG_CRYPTO_WP512 is not set # # Ciphers # # CONFIG_CRYPTO_AES is not set # CONFIG_CRYPTO_AES_X86_64 is not set # CONFIG_CRYPTO_ANUBIS is not set # CONFIG_CRYPTO_ARC4 is not set # CONFIG_CRYPTO_BLOWFISH is not set # CONFIG_CRYPTO_CAMELLIA is not set CONFIG_CRYPTO_CAST5=y # CONFIG_CRYPTO_CAST6 is not set CONFIG_CRYPTO_DES=y # CONFIG_CRYPTO_FCRYPT is not set # CONFIG_CRYPTO_KHAZAD is not set # CONFIG_CRYPTO_SALSA20 is not set # CONFIG_CRYPTO_SALSA20_X86_64 is not set # CONFIG_CRYPTO_SEED is not set # CONFIG_CRYPTO_SERPENT is not set # CONFIG_CRYPTO_TEA is not set # CONFIG_CRYPTO_TWOFISH is not set # CONFIG_CRYPTO_TWOFISH_X86_64 is not set # # Compression # CONFIG_CRYPTO_DEFLATE=y # CONFIG_CRYPTO_LZO is not set CONFIG_CRYPTO_HW=y # CONFIG_CRYPTO_DEV_HIFN_795X is not set CONFIG_HAVE_KVM=y # CONFIG_VIRTUALIZATION is not set # # Library routines # CONFIG_BITREVERSE=y CONFIG_GENERIC_FIND_FIRST_BIT=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_CRC_CCITT=y CONFIG_CRC16=y CONFIG_CRC_ITU_T=y CONFIG_CRC32=y CONFIG_CRC7=y CONFIG_LIBCRC32C=y CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13 (x86_64: panic) 2008-06-13 22:58 ` linux-next: Tree for June 13 (x86_64: panic) Randy Dunlap @ 2008-06-14 8:16 ` Stephen Rothwell 2008-06-14 23:15 ` Randy Dunlap 0 siblings, 1 reply; 90+ messages in thread From: Stephen Rothwell @ 2008-06-14 8:16 UTC (permalink / raw) To: Randy Dunlap; +Cc: linux-next, LKML [-- Attachment #1: Type: text/plain, Size: 934 bytes --] Hi Randy, On Fri, 13 Jun 2008 15:58:09 -0700 Randy Dunlap <randy.dunlap@oracle.com> wrote: > > When booting linux-next-20080613, I'm seeing a panic (on x86_64): > > > Freeing unused kernel memory: 380k freed > Write protecting the kernel read-only data: 4616k > uhci_hcd: version magic '2.6.26-rc6 SMP mod_unload ' should be '2.6.26-rc6-next-20080613 SMP mod_unload ' > ohci_hcd: version magic '2.6.26-rc6 SMP mod_unload ' should be '2.6.26-rc6-next-20080613 SMP mod_unload ' > ehci_hcd: version magic '2.6.26-rc6 SMP mod_unload ' should be '2.6.26-rc6-next-20080613 SMP mod_unload ' > cciss: version magic '2.6.26-rc6 SMP mod_unload ' should be '2.6.26-rc6-next-20080613 SMP mod_unload ' These look strange. Are you sure you rebuilt and installed all your modules and removed any old ones lying around? -- Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13 (x86_64: panic) 2008-06-14 8:16 ` Stephen Rothwell @ 2008-06-14 23:15 ` Randy Dunlap 0 siblings, 0 replies; 90+ messages in thread From: Randy Dunlap @ 2008-06-14 23:15 UTC (permalink / raw) To: Stephen Rothwell; +Cc: linux-next, LKML On Sat, 14 Jun 2008 18:16:46 +1000 Stephen Rothwell wrote: > Hi Randy, > > On Fri, 13 Jun 2008 15:58:09 -0700 Randy Dunlap <randy.dunlap@oracle.com> wrote: > > > > When booting linux-next-20080613, I'm seeing a panic (on x86_64): > > > > > > Freeing unused kernel memory: 380k freed > > Write protecting the kernel read-only data: 4616k > > uhci_hcd: version magic '2.6.26-rc6 SMP mod_unload ' should be '2.6.26-rc6-next-20080613 SMP mod_unload ' > > ohci_hcd: version magic '2.6.26-rc6 SMP mod_unload ' should be '2.6.26-rc6-next-20080613 SMP mod_unload ' > > ehci_hcd: version magic '2.6.26-rc6 SMP mod_unload ' should be '2.6.26-rc6-next-20080613 SMP mod_unload ' > > cciss: version magic '2.6.26-rc6 SMP mod_unload ' should be '2.6.26-rc6-next-20080613 SMP mod_unload ' > > These look strange. Are you sure you rebuilt and installed all your > modules and removed any old ones lying around? It's possibly (yet another) script problem. I'll check it out. Thanks. --- ~Randy '"Daemon' is an old piece of jargon from the UNIX operating system, where it referred to a piece of low-level utility software, a fundamental part of the operating system." ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13 (soft lockup) 2008-06-13 13:22 linux-next: Tree for June 13 Stephen Rothwell 2008-06-13 17:13 ` linux-next: Tree for June 13 (XEN) Randy Dunlap 2008-06-13 22:58 ` linux-next: Tree for June 13 (x86_64: panic) Randy Dunlap @ 2008-06-15 16:33 ` Randy Dunlap 2008-06-15 18:31 ` linux-next: Tree for June 13 Rafael J. Wysocki 3 siblings, 0 replies; 90+ messages in thread From: Randy Dunlap @ 2008-06-15 16:33 UTC (permalink / raw) To: Stephen Rothwell; +Cc: linux-next, LKML, shaggy BUG: soft lockup - CPU#2 stuck for 61s! [udevd:30563] CPU 2: Modules linked in: jfs(-) parport_pc lp parport tg3 cciss ehci_hcd ohci_hcd uhci_hcd [last unloaded: jfs] Pid: 30563, comm: udevd Not tainted 2.6.26-rc6-next-20080613 #1 RIP: 0010:[<ffffffff8021d43a>] [<ffffffff8021d43a>] native_flush_tlb_others+0x6c/0x92 RSP: 0018:ffff810170127c38 EFLAGS: 00000202 RAX: 00000000000008f2 RBX: ffff810170127c68 RCX: 00007fff0fffffff RDX: 00000000000008f2 RSI: 00000000000000f2 RDI: 0000000000000001 RBP: 00007fff10000000 R08: ffff81017fc02eac R09: ffff810170127c48 R10: 00000000636148a1 R11: 00000000af8ad1dc R12: ffffffff80224b1c R13: ffff810170127bb8 R14: ffff8100010338c0 R15: 0000000000000282 FS: 00007fd407f48710(0000) GS:ffff81017fc02c80(0000) knlGS:00000000f7fb76c0 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007fd40765e090 CR3: 0000000172983000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: [<ffffffff8021d436>] ? native_flush_tlb_others+0x68/0x92 [<ffffffff8021d67f>] ? flush_tlb_mm+0x63/0x6c [<ffffffff80281e19>] ? exit_mmap+0xac/0xef [<ffffffff80231961>] ? mmput+0x42/0x98 [<ffffffff8029f6d2>] ? flush_old_exec+0x4b2/0x7d0 [<ffffffff802cd20d>] ? load_elf_binary+0x36c/0x1736 [<ffffffff8029e4f3>] ? put_arg_page+0x9/0xb [<ffffffff8029e84b>] ? copy_strings+0x1cc/0x1dd [<ffffffff8029e94d>] ? search_binary_handler+0xa9/0x1fe [<ffffffff8029fcd9>] ? do_execve+0x14d/0x1da [<ffffffff8020a474>] ? sys_execve+0x3e/0x58 [<ffffffff8020c24a>] ? stub_execve+0x6a/0xc0 This is on x86_64, 4 procs, 8 GB RAM. Test running was fsx_linux on JFS. fsx_linux terminated. Looks like jfs module was being unloaded. --- ~Randy '"Daemon' is an old piece of jargon from the UNIX operating system, where it referred to a piece of low-level utility software, a fundamental part of the operating system." ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13 2008-06-13 13:22 linux-next: Tree for June 13 Stephen Rothwell ` (2 preceding siblings ...) 2008-06-15 16:33 ` linux-next: Tree for June 13 (soft lockup) Randy Dunlap @ 2008-06-15 18:31 ` Rafael J. Wysocki [not found] ` <200806160314.49489.rjw@sisk.pl> 3 siblings, 1 reply; 90+ messages in thread From: Rafael J. Wysocki @ 2008-06-15 18:31 UTC (permalink / raw) To: Stephen Rothwell; +Cc: linux-next, LKML On Friday, 13 of June 2008, Stephen Rothwell wrote: > Hi all, > > Changes since next-20080612: > > New tree: kgdb > Dropped trees (temporary): ldp (it is unfetchable - probably something to > do with the new Staging tree) > Restored trees: block > > The x86 tree gained a conflict with Linus' tree. > > The acpi tree gained a conflict with the pci tree. > > The mtd tree gained a trivial conflict with the avr32 tree. > > The rr tree lost its conflict with the net-current tree. > > The block tree gained several conflict with various other trees. It also > required a build fix patch. > > The firmware tree lost its build fix patch. > > The patches for known build problems are no longer needed. 20080613 doesn't boot on my HP nx6325. Bisecting ... Thanks, Rafael ^ permalink raw reply [flat|nested] 90+ messages in thread
[parent not found: <200806160314.49489.rjw@sisk.pl>]
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 [not found] ` <200806160314.49489.rjw@sisk.pl> @ 2008-06-16 2:45 ` Maciej W. Rozycki 2008-06-16 13:39 ` Rafael J. Wysocki 0 siblings, 1 reply; 90+ messages in thread From: Maciej W. Rozycki @ 2008-06-16 2:45 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Stephen Rothwell, linux-next, LKML, Ingo Molnar, Thomas Gleixner On Mon, 16 Jun 2008, Rafael J. Wysocki wrote: > On Sunday, 15 of June 2008, Rafael J. Wysocki wrote: > > On Friday, 13 of June 2008, Stephen Rothwell wrote: > > > Hi all, > > > > > > Changes since next-20080612: > > > > > > New tree: kgdb > > > Dropped trees (temporary): ldp (it is unfetchable - probably something to > > > do with the new Staging tree) > > > Restored trees: block > > > > > > The x86 tree gained a conflict with Linus' tree. > > > > > > The acpi tree gained a conflict with the pci tree. > > > > > > The mtd tree gained a trivial conflict with the avr32 tree. > > > > > > The rr tree lost its conflict with the net-current tree. > > > > > > The block tree gained several conflict with various other trees. It also > > > required a build fix patch. > > > > > > The firmware tree lost its build fix patch. > > > > > > The patches for known build problems are no longer needed. > > > > 20080613 doesn't boot on my HP nx6325. Bisecting ... > > Okay, with the following commit reverted, the kernel boots normally on this > box: > > commit 7e3530cd98a0c6ab38f5898e855a5beffab26561 > Author: Maciej W. Rozycki <macro@linux-mips.org> > Date: Tue May 27 21:19:51 2008 +0100 > > x86: I/O APIC: timer through 8259A second-chance > > Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> > Signed-off-by: Ingo Molnar <mingo@elte.hu> Can I have .config used and a full bootstrap log from that system with the patch still applied? Maciej ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-16 2:45 ` linux-next: Tree for June 13: IO APIC breakage on HP nx6325 Maciej W. Rozycki @ 2008-06-16 13:39 ` Rafael J. Wysocki 2008-06-16 15:39 ` Maciej W. Rozycki 2008-06-17 0:08 ` Len Brown 0 siblings, 2 replies; 90+ messages in thread From: Rafael J. Wysocki @ 2008-06-16 13:39 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Stephen Rothwell, linux-next, LKML, Ingo Molnar, Thomas Gleixner On Monday, 16 of June 2008, Maciej W. Rozycki wrote: > On Mon, 16 Jun 2008, Rafael J. Wysocki wrote: > > > On Sunday, 15 of June 2008, Rafael J. Wysocki wrote: > > > On Friday, 13 of June 2008, Stephen Rothwell wrote: > > > > Hi all, > > > > > > > > Changes since next-20080612: > > > > > > > > New tree: kgdb > > > > Dropped trees (temporary): ldp (it is unfetchable - probably something to > > > > do with the new Staging tree) > > > > Restored trees: block > > > > > > > > The x86 tree gained a conflict with Linus' tree. > > > > > > > > The acpi tree gained a conflict with the pci tree. > > > > > > > > The mtd tree gained a trivial conflict with the avr32 tree. > > > > > > > > The rr tree lost its conflict with the net-current tree. > > > > > > > > The block tree gained several conflict with various other trees. It also > > > > required a build fix patch. > > > > > > > > The firmware tree lost its build fix patch. > > > > > > > > The patches for known build problems are no longer needed. > > > > > > 20080613 doesn't boot on my HP nx6325. Bisecting ... > > > > Okay, with the following commit reverted, the kernel boots normally on this > > box: > > > > commit 7e3530cd98a0c6ab38f5898e855a5beffab26561 > > Author: Maciej W. Rozycki <macro@linux-mips.org> > > Date: Tue May 27 21:19:51 2008 +0100 > > > > x86: I/O APIC: timer through 8259A second-chance > > > > Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> > > Signed-off-by: Ingo Molnar <mingo@elte.hu> > > Can I have .config used and a full bootstrap log from that system with > the patch still applied? That may be difficult, because with the patch applied the box either doesn't boot at all, or works unreliably when booted (depending on the set of patches applied on top of it). I'll try to get one later today. Thanks, Rafael ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-16 13:39 ` Rafael J. Wysocki @ 2008-06-16 15:39 ` Maciej W. Rozycki 2008-06-16 22:38 ` Rafael J. Wysocki 2008-06-17 0:08 ` Len Brown 1 sibling, 1 reply; 90+ messages in thread From: Maciej W. Rozycki @ 2008-06-16 15:39 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Stephen Rothwell, linux-next, LKML, Ingo Molnar, Thomas Gleixner On Mon, 16 Jun 2008, Rafael J. Wysocki wrote: > > > commit 7e3530cd98a0c6ab38f5898e855a5beffab26561 > > > Author: Maciej W. Rozycki <macro@linux-mips.org> > > > Date: Tue May 27 21:19:51 2008 +0100 > > > > > > x86: I/O APIC: timer through 8259A second-chance > > > > > > Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> > > > Signed-off-by: Ingo Molnar <mingo@elte.hu> > > > > Can I have .config used and a full bootstrap log from that system with > > the patch still applied? > > That may be difficult, because with the patch applied the box either doesn't > boot at all, or works unreliably when booted (depending on the set of patches > applied on top of it). Serial console? I'm most interested in one from a configuration that does not boot at all as that's easier to reproduce, determine the cause and verify whether a change fixes the problem or not. Other configurations may then be tested with the fix in place. > I'll try to get one later today. Thanks. Maciej ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-16 15:39 ` Maciej W. Rozycki @ 2008-06-16 22:38 ` Rafael J. Wysocki 2008-06-16 23:05 ` Rafael J. Wysocki 2008-06-17 20:59 ` Rafael J. Wysocki 0 siblings, 2 replies; 90+ messages in thread From: Rafael J. Wysocki @ 2008-06-16 22:38 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Stephen Rothwell, linux-next, LKML, Ingo Molnar, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Monday, 16 of June 2008, Maciej W. Rozycki wrote: > On Mon, 16 Jun 2008, Rafael J. Wysocki wrote: > > > > > commit 7e3530cd98a0c6ab38f5898e855a5beffab26561 > > > > Author: Maciej W. Rozycki <macro@linux-mips.org> > > > > Date: Tue May 27 21:19:51 2008 +0100 > > > > > > > > x86: I/O APIC: timer through 8259A second-chance > > > > > > > > Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> > > > > Signed-off-by: Ingo Molnar <mingo@elte.hu> > > > > > > Can I have .config used and a full bootstrap log from that system with > > > the patch still applied? > > > > That may be difficult, because with the patch applied the box either doesn't > > boot at all, or works unreliably when booted (depending on the set of patches > > applied on top of it). > > Serial console? No, this box doesn't have any serial ports. It has a FireWire one, but I don't have a matching cable ... > I'm most interested in one from a configuration that > does not boot at all as that's easier to reproduce, determine the cause > and verify whether a change fixes the problem or not. Other > configurations may then be tested with the fix in place. With the -next from today (20080616) I get a different picture. Without any patches on top it boots, but the fan is turned 100% on as soon as the ACPI modules get loaded, regardless of the temperature (normally it does that above 75^o C, which is impossible to get normally, because there are 3 temperature trip points below that level; generally the hardware only does that when overheating). After that, things start to go _very_ slow, like 10x slower than usually in X and somewhat slower in the fb console, but I was able to get a dmesg output. This is reproducible 100% of the time. With commit 7e3530cd98a0c6ab38f5898e855a5beffab26561 reverted the box seems to work normally. However, while I was writing this message, ACPI decided it was overheating and emergency shut down the box, although that was completely wrong. Next time I'll try with the C1E patches reverted. The .config is at: http://www.sisk.pl/kernel/debug/20080616/next-config dmesg output without any patches is at http://www.sisk.pl/kernel/debug/20080616/dmesg-1.log dmesg output with commit 7e3530cd98a0c6ab38f5898e855a5beffab26561 reverted is at: http://www.sisk.pl/kernel/debug/20080616/dmesg-2.log (they look pretty similar to my untrained eye, but well). Thanks, Rafael ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-16 22:38 ` Rafael J. Wysocki @ 2008-06-16 23:05 ` Rafael J. Wysocki 2008-06-17 7:12 ` Thomas Gleixner 2008-06-17 20:59 ` Rafael J. Wysocki 1 sibling, 1 reply; 90+ messages in thread From: Rafael J. Wysocki @ 2008-06-16 23:05 UTC (permalink / raw) To: Maciej W. Rozycki, Thomas Gleixner Cc: Stephen Rothwell, linux-next, LKML, Ingo Molnar, ACPI Devel Maling List, Len Brown On Tuesday, 17 of June 2008, Rafael J. Wysocki wrote: > On Monday, 16 of June 2008, Maciej W. Rozycki wrote: > > On Mon, 16 Jun 2008, Rafael J. Wysocki wrote: > > > > > > > commit 7e3530cd98a0c6ab38f5898e855a5beffab26561 > > > > > Author: Maciej W. Rozycki <macro@linux-mips.org> > > > > > Date: Tue May 27 21:19:51 2008 +0100 > > > > > > > > > > x86: I/O APIC: timer through 8259A second-chance > > > > > > > > > > Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> > > > > > Signed-off-by: Ingo Molnar <mingo@elte.hu> > > > > > > > > Can I have .config used and a full bootstrap log from that system with > > > > the patch still applied? > > > > > > That may be difficult, because with the patch applied the box either doesn't > > > boot at all, or works unreliably when booted (depending on the set of patches > > > applied on top of it). > > > > Serial console? > > No, this box doesn't have any serial ports. It has a FireWire one, but I don't > have a matching cable ... > > > I'm most interested in one from a configuration that > > does not boot at all as that's easier to reproduce, determine the cause > > and verify whether a change fixes the problem or not. Other > > configurations may then be tested with the fix in place. > > With the -next from today (20080616) I get a different picture. > > Without any patches on top it boots, but the fan is turned 100% on as soon as > the ACPI modules get loaded, regardless of the temperature (normally it does > that above 75^o C, which is impossible to get normally, because there are 3 > temperature trip points below that level; generally the hardware only does that > when overheating). After that, things start to go _very_ slow, like 10x slower > than usually in X and somewhat slower in the fb console, but I was able to get > a dmesg output. This is reproducible 100% of the time. > > With commit 7e3530cd98a0c6ab38f5898e855a5beffab26561 reverted the box seems to > work normally. However, while I was writing this message, ACPI decided it was > overheating and emergency shut down the box, although that was completely > wrong. Next time I'll try with the C1E patches reverted. > > The .config is at: http://www.sisk.pl/kernel/debug/20080616/next-config > > dmesg output without any patches is at > http://www.sisk.pl/kernel/debug/20080616/dmesg-1.log > > dmesg output with commit 7e3530cd98a0c6ab38f5898e855a5beffab26561 reverted is > at: http://www.sisk.pl/kernel/debug/20080616/dmesg-2.log > > (they look pretty similar to my untrained eye, but well). BTW, with the C1E patches reverted I don't get the WARNING: at /home/rafael/src/linux-next/kernel/smp.c:215 smp_call_function_single+0x3d/0xa2 in the log. Thomas? dmesg with commit 7e3530cd98a0c6ab38f5898e855a5beffab26561 and with the C1E commits (the ones between 8750bf598db6a0ea3475d1cf8da922b325941e12 and aa83f3f2cfc74d66d01b1d2eb1485ea1103a0f4e inclusive) reverted is at: http://www.sisk.pl/kernel/debug/20080616/dmesg-3.log Thanks, Rafael ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-16 23:05 ` Rafael J. Wysocki @ 2008-06-17 7:12 ` Thomas Gleixner 2008-06-17 20:44 ` Rafael J. Wysocki 0 siblings, 1 reply; 90+ messages in thread From: Thomas Gleixner @ 2008-06-17 7:12 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Maciej W. Rozycki, Stephen Rothwell, linux-next, LKML, Ingo Molnar, ACPI Devel Maling List, Len Brown On Tue, 17 Jun 2008, Rafael J. Wysocki wrote: > > BTW, with the C1E patches reverted I don't get the > WARNING: at /home/rafael/src/linux-next/kernel/smp.c:215 smp_call_function_single+0x3d/0xa2 > in the log. Thomas? Yeah, my bad. Fix below. Thanks, tglx -------------------> Subject: x86: c1e_idle, run BROADCAST_FORCE notify with irqs enabled From: Thomas Gleixner <tglx@linutronix.de> Date: Tue, 17 Jun 2008 09:07:53 +0200 The BROADCAST_FORCE notification uses smp_function_call and therefor must be run with interrupts enabled. While at it, add a comment for the BROADCAST_EXIT notifier as well. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> --- diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c index 57fa86d..1450e0f 100644 --- a/arch/x86/kernel/process.c +++ b/arch/x86/kernel/process.c @@ -267,17 +267,29 @@ static void c1e_idle(void) if (!cpu_isset(cpu, c1e_mask)) { cpu_set(cpu, c1e_mask); - /* Force broadcast so ACPI can not interfere */ + /* + * Force broadcast so ACPI can not interfere. Needs + * to run with interrupts enabled as it uses + * smp_function_call. + */ + local_irq_enable(); clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_FORCE, &cpu); printk(KERN_INFO "Switch to broadcast mode on CPU%d\n", cpu); + local_irq_disable(); } clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu); + default_idle(); - local_irq_disable(); - clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu); - local_irq_enable(); + + /* + * The switch back from broadcast mode needs to be + * called with interrupts disabled. + */ + local_irq_disable(); + clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu); + local_irq_enable(); } else default_idle(); } ^ permalink raw reply related [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-17 7:12 ` Thomas Gleixner @ 2008-06-17 20:44 ` Rafael J. Wysocki 2008-06-17 22:19 ` Rafael J. Wysocki 0 siblings, 1 reply; 90+ messages in thread From: Rafael J. Wysocki @ 2008-06-17 20:44 UTC (permalink / raw) To: Thomas Gleixner Cc: Maciej W. Rozycki, Stephen Rothwell, linux-next, LKML, Ingo Molnar, ACPI Devel Maling List, Len Brown On Tuesday, 17 of June 2008, Thomas Gleixner wrote: > On Tue, 17 Jun 2008, Rafael J. Wysocki wrote: > > > > BTW, with the C1E patches reverted I don't get the > > WARNING: at /home/rafael/src/linux-next/kernel/smp.c:215 smp_call_function_single+0x3d/0xa2 > > in the log. Thomas? > > Yeah, my bad. Fix below. Thanks, it eliminates the WARNING, but still the box doesn't work with the "x86: add C1E aware idle function" patch applied, even with 'highres=off'. The main symptom is that CPU loads are computed incorrectly (I got X using 126% of CPU time from 'top', for example). Apart from this, some processes (like gkrellm) seem to be 'frozen' and only change their state in 'jumps', as though they only got CPU from time to time at random. Reverting the above-mentioned patch fixes those problems. Thanks, Rafael ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-17 20:44 ` Rafael J. Wysocki @ 2008-06-17 22:19 ` Rafael J. Wysocki 2008-06-17 22:25 ` Rafael J. Wysocki 2008-06-18 13:14 ` Ingo Molnar 0 siblings, 2 replies; 90+ messages in thread From: Rafael J. Wysocki @ 2008-06-17 22:19 UTC (permalink / raw) To: Thomas Gleixner Cc: Maciej W. Rozycki, Stephen Rothwell, linux-next, LKML, Ingo Molnar, ACPI Devel Maling List, Len Brown On Tuesday, 17 of June 2008, Rafael J. Wysocki wrote: > On Tuesday, 17 of June 2008, Thomas Gleixner wrote: > > On Tue, 17 Jun 2008, Rafael J. Wysocki wrote: > > > > > > BTW, with the C1E patches reverted I don't get the > > > WARNING: at /home/rafael/src/linux-next/kernel/smp.c:215 smp_call_function_single+0x3d/0xa2 > > > in the log. Thomas? > > > > Yeah, my bad. Fix below. > > Thanks, it eliminates the WARNING, but still the box doesn't work with > the "x86: add C1E aware idle function" patch applied, even with 'highres=off'. > > The main symptom is that CPU loads are computed incorrectly (I got X using 126% > of CPU time from 'top', for example). Apart from this, some processes (like > gkrellm) seem to be 'frozen' and only change their state in 'jumps', as though > they only got CPU from time to time at random. > > Reverting the above-mentioned patch fixes those problems. Ah. If your fix is replaced with the appended one, the system happily works with C1E and highres. Thanks, Rafael --- arch/x86/kernel/process.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) Index: linux-next/arch/x86/kernel/process.c =================================================================== --- linux-next.orig/arch/x86/kernel/process.c +++ linux-next/arch/x86/kernel/process.c @@ -265,16 +265,30 @@ static void c1e_idle(void) if (c1e_detected) { int cpu = smp_processor_id(); + local_irq_enable(); + if (!cpu_isset(cpu, c1e_mask)) { cpu_set(cpu, c1e_mask); - /* Force broadcast so ACPI can not interfere */ + /* + * Force broadcast so ACPI can not interfere. Needs + * to run with interrupts enabled as it uses + * smp_function_call. + */ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_FORCE, &cpu); printk(KERN_INFO "Switch to broadcast mode on CPU%d\n", cpu); } + local_irq_disable(); clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu); + local_irq_enable(); + default_idle(); + + /* + * The switch back from broadcast mode needs to be + * called with interrupts disabled. + */ local_irq_disable(); clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu); local_irq_enable(); ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-17 22:19 ` Rafael J. Wysocki @ 2008-06-17 22:25 ` Rafael J. Wysocki 2008-06-18 8:02 ` Thomas Gleixner 2008-06-18 13:15 ` Ingo Molnar 2008-06-18 13:14 ` Ingo Molnar 1 sibling, 2 replies; 90+ messages in thread From: Rafael J. Wysocki @ 2008-06-17 22:25 UTC (permalink / raw) To: Thomas Gleixner Cc: Maciej W. Rozycki, Stephen Rothwell, linux-next, LKML, Ingo Molnar, ACPI Devel Maling List, Len Brown On Wednesday, 18 of June 2008, Rafael J. Wysocki wrote: > On Tuesday, 17 of June 2008, Rafael J. Wysocki wrote: > > On Tuesday, 17 of June 2008, Thomas Gleixner wrote: > > > On Tue, 17 Jun 2008, Rafael J. Wysocki wrote: > > > > > > > > BTW, with the C1E patches reverted I don't get the > > > > WARNING: at /home/rafael/src/linux-next/kernel/smp.c:215 smp_call_function_single+0x3d/0xa2 > > > > in the log. Thomas? > > > > > > Yeah, my bad. Fix below. > > > > Thanks, it eliminates the WARNING, but still the box doesn't work with > > the "x86: add C1E aware idle function" patch applied, even with 'highres=off'. > > > > The main symptom is that CPU loads are computed incorrectly (I got X using 126% > > of CPU time from 'top', for example). Apart from this, some processes (like > > gkrellm) seem to be 'frozen' and only change their state in 'jumps', as though > > they only got CPU from time to time at random. > > > > Reverting the above-mentioned patch fixes those problems. > > Ah. If your fix is replaced with the appended one, the system happily works > with C1E and highres. Scratch that. The symptoms appeared later this time, that's all. I've just got b43 consuming 90+ % of the CPU time. :-( Thanks, Rafael ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-17 22:25 ` Rafael J. Wysocki @ 2008-06-18 8:02 ` Thomas Gleixner 2008-06-18 12:41 ` Thomas Gleixner 2008-06-18 13:15 ` Ingo Molnar 1 sibling, 1 reply; 90+ messages in thread From: Thomas Gleixner @ 2008-06-18 8:02 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Maciej W. Rozycki, Stephen Rothwell, linux-next, LKML, Ingo Molnar, ACPI Devel Maling List, Len Brown On Wed, 18 Jun 2008, Rafael J. Wysocki wrote: > On Wednesday, 18 of June 2008, Rafael J. Wysocki wrote: > > On Tuesday, 17 of June 2008, Rafael J. Wysocki wrote: > > > On Tuesday, 17 of June 2008, Thomas Gleixner wrote: > > > > On Tue, 17 Jun 2008, Rafael J. Wysocki wrote: > > > > > > > > > > BTW, with the C1E patches reverted I don't get the > > > > > WARNING: at /home/rafael/src/linux-next/kernel/smp.c:215 smp_call_function_single+0x3d/0xa2 > > > > > in the log. Thomas? > > > > > > > > Yeah, my bad. Fix below. > > > > > > Thanks, it eliminates the WARNING, but still the box doesn't work with > > > the "x86: add C1E aware idle function" patch applied, even with 'highres=off'. > > > > > > The main symptom is that CPU loads are computed incorrectly (I got X using 126% > > > of CPU time from 'top', for example). Apart from this, some processes (like > > > gkrellm) seem to be 'frozen' and only change their state in 'jumps', as though > > > they only got CPU from time to time at random. > > > > > > Reverting the above-mentioned patch fixes those problems. > > > > Ah. If your fix is replaced with the appended one, the system happily works > > with C1E and highres. > > Scratch that. The symptoms appeared later this time, that's all. I've just got > b43 consuming 90+ % of the CPU time. :-( I would have been pretty surprised if it had helped :) Does the box boot when you disable the local apic timer on the kernel command line with the patch applied ? Also does forcing hpet change anything ? Thanks, tglx ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-18 8:02 ` Thomas Gleixner @ 2008-06-18 12:41 ` Thomas Gleixner 2008-06-18 14:37 ` Rafael J. Wysocki 2008-06-18 14:40 ` Rafael J. Wysocki 0 siblings, 2 replies; 90+ messages in thread From: Thomas Gleixner @ 2008-06-18 12:41 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Maciej W. Rozycki, Stephen Rothwell, linux-next, LKML, Ingo Molnar, ACPI Devel Maling List, Len Brown On Wed, 18 Jun 2008, Thomas Gleixner wrote: > On Wed, 18 Jun 2008, Rafael J. Wysocki wrote: > > On Wednesday, 18 of June 2008, Rafael J. Wysocki wrote: > > > On Tuesday, 17 of June 2008, Rafael J. Wysocki wrote: > > > > On Tuesday, 17 of June 2008, Thomas Gleixner wrote: > > > > > On Tue, 17 Jun 2008, Rafael J. Wysocki wrote: > > > > > > > > > > > > BTW, with the C1E patches reverted I don't get the > > > > > > WARNING: at /home/rafael/src/linux-next/kernel/smp.c:215 smp_call_function_single+0x3d/0xa2 > > > > > > in the log. Thomas? > > > > > > > > > > Yeah, my bad. Fix below. > > > > > > > > Thanks, it eliminates the WARNING, but still the box doesn't work with > > > > the "x86: add C1E aware idle function" patch applied, even with 'highres=off'. > > > > > > > > The main symptom is that CPU loads are computed incorrectly (I got X using 126% > > > > of CPU time from 'top', for example). Apart from this, some processes (like > > > > gkrellm) seem to be 'frozen' and only change their state in 'jumps', as though > > > > they only got CPU from time to time at random. > > > > > > > > Reverting the above-mentioned patch fixes those problems. > > > > > > Ah. If your fix is replaced with the appended one, the system happily works > > > with C1E and highres. > > > > Scratch that. The symptoms appeared later this time, that's all. I've just got > > b43 consuming 90+ % of the CPU time. :-( > > I would have been pretty surprised if it had helped :) > > Does the box boot when you disable the local apic timer on the kernel > command line with the patch applied ? > > Also does forcing hpet change anything ? I just checked that the original c1e series and the affected code in tip are not different. IIRC you confirmed that the C1E patches would work on your box. So I wonder what else got changed which causes these problems. Thanks, tglx ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-18 12:41 ` Thomas Gleixner @ 2008-06-18 14:37 ` Rafael J. Wysocki 2008-06-18 14:40 ` Rafael J. Wysocki 1 sibling, 0 replies; 90+ messages in thread From: Rafael J. Wysocki @ 2008-06-18 14:37 UTC (permalink / raw) To: Thomas Gleixner Cc: Maciej W. Rozycki, Stephen Rothwell, linux-next, LKML, Ingo Molnar, ACPI Devel Maling List, Len Brown On Wednesday, 18 of June 2008, Thomas Gleixner wrote: > On Wed, 18 Jun 2008, Thomas Gleixner wrote: > > On Wed, 18 Jun 2008, Rafael J. Wysocki wrote: > > > On Wednesday, 18 of June 2008, Rafael J. Wysocki wrote: > > > > On Tuesday, 17 of June 2008, Rafael J. Wysocki wrote: > > > > > On Tuesday, 17 of June 2008, Thomas Gleixner wrote: > > > > > > On Tue, 17 Jun 2008, Rafael J. Wysocki wrote: > > > > > > > > > > > > > > BTW, with the C1E patches reverted I don't get the > > > > > > > WARNING: at /home/rafael/src/linux-next/kernel/smp.c:215 smp_call_function_single+0x3d/0xa2 > > > > > > > in the log. Thomas? > > > > > > > > > > > > Yeah, my bad. Fix below. > > > > > > > > > > Thanks, it eliminates the WARNING, but still the box doesn't work with > > > > > the "x86: add C1E aware idle function" patch applied, even with 'highres=off'. > > > > > > > > > > The main symptom is that CPU loads are computed incorrectly (I got X using 126% > > > > > of CPU time from 'top', for example). Apart from this, some processes (like > > > > > gkrellm) seem to be 'frozen' and only change their state in 'jumps', as though > > > > > they only got CPU from time to time at random. > > > > > > > > > > Reverting the above-mentioned patch fixes those problems. > > > > > > > > Ah. If your fix is replaced with the appended one, the system happily works > > > > with C1E and highres. > > > > > > Scratch that. The symptoms appeared later this time, that's all. I've just got > > > b43 consuming 90+ % of the CPU time. :-( > > > > I would have been pretty surprised if it had helped :) > > > > Does the box boot when you disable the local apic timer on the kernel > > command line with the patch applied ? > > > > Also does forcing hpet change anything ? > > I just checked that the original c1e series and the affected code in > tip are not different. IIRC you confirmed that the C1E patches would > work on your box. So I wonder what else got changed which causes these > problems. Well, probably I didn't test that long enough. The symptoms do not always appear immediately, they sometimes appear only after several minutes. Thanks, Rafael ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-18 12:41 ` Thomas Gleixner 2008-06-18 14:37 ` Rafael J. Wysocki @ 2008-06-18 14:40 ` Rafael J. Wysocki 2008-06-18 15:29 ` Thomas Gleixner 1 sibling, 1 reply; 90+ messages in thread From: Rafael J. Wysocki @ 2008-06-18 14:40 UTC (permalink / raw) To: Thomas Gleixner Cc: Maciej W. Rozycki, Stephen Rothwell, linux-next, LKML, Ingo Molnar, ACPI Devel Maling List, Len Brown On Wednesday, 18 of June 2008, Thomas Gleixner wrote: > On Wed, 18 Jun 2008, Thomas Gleixner wrote: > > On Wed, 18 Jun 2008, Rafael J. Wysocki wrote: > > > On Wednesday, 18 of June 2008, Rafael J. Wysocki wrote: > > > > On Tuesday, 17 of June 2008, Rafael J. Wysocki wrote: > > > > > On Tuesday, 17 of June 2008, Thomas Gleixner wrote: > > > > > > On Tue, 17 Jun 2008, Rafael J. Wysocki wrote: > > > > > > > > > > > > > > BTW, with the C1E patches reverted I don't get the > > > > > > > WARNING: at /home/rafael/src/linux-next/kernel/smp.c:215 smp_call_function_single+0x3d/0xa2 > > > > > > > in the log. Thomas? > > > > > > > > > > > > Yeah, my bad. Fix below. > > > > > > > > > > Thanks, it eliminates the WARNING, but still the box doesn't work with > > > > > the "x86: add C1E aware idle function" patch applied, even with 'highres=off'. > > > > > > > > > > The main symptom is that CPU loads are computed incorrectly (I got X using 126% > > > > > of CPU time from 'top', for example). Apart from this, some processes (like > > > > > gkrellm) seem to be 'frozen' and only change their state in 'jumps', as though > > > > > they only got CPU from time to time at random. > > > > > > > > > > Reverting the above-mentioned patch fixes those problems. > > > > > > > > Ah. If your fix is replaced with the appended one, the system happily works > > > > with C1E and highres. > > > > > > Scratch that. The symptoms appeared later this time, that's all. I've just got > > > b43 consuming 90+ % of the CPU time. :-( > > > > I would have been pretty surprised if it had helped :) > > > > Does the box boot when you disable the local apic timer on the kernel > > command line with the patch applied ? > > > > Also does forcing hpet change anything ? > > I just checked that the original c1e series and the affected code in > tip are not different. IIRC you confirmed that the C1E patches would > work on your box. So I wonder what else got changed which causes these > problems. Well, to eliminate any possible correlations, do you have a version of the series or a single patch against the current mainline? Rafael ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-18 14:40 ` Rafael J. Wysocki @ 2008-06-18 15:29 ` Thomas Gleixner 2008-06-21 22:47 ` Rafael J. Wysocki 0 siblings, 1 reply; 90+ messages in thread From: Thomas Gleixner @ 2008-06-18 15:29 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Maciej W. Rozycki, Stephen Rothwell, linux-next, LKML, Ingo Molnar, ACPI Devel Maling List, Len Brown On Wed, 18 Jun 2008, Rafael J. Wysocki wrote: > > I just checked that the original c1e series and the affected code in > > tip are not different. IIRC you confirmed that the C1E patches would > > work on your box. So I wonder what else got changed which causes these > > problems. > > Well, to eliminate any possible correlations, do you have a version of the > series or a single patch against the current mainline? http://userweb.kernel.org/~tglx/952f4a-c1e-apic.patch http://userweb.kernel.org/~tglx/952f4a-c1e.patch c1e-apic is the forward port of the apic changes and c1e is the pure c1e stuff. On my box it does not work w/o the c1e-apic one, but .... Thanks, tglx ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-18 15:29 ` Thomas Gleixner @ 2008-06-21 22:47 ` Rafael J. Wysocki 0 siblings, 0 replies; 90+ messages in thread From: Rafael J. Wysocki @ 2008-06-21 22:47 UTC (permalink / raw) To: Thomas Gleixner Cc: Maciej W. Rozycki, Stephen Rothwell, linux-next, LKML, Ingo Molnar, ACPI Devel Maling List, Len Brown On Wednesday, 18 of June 2008, Thomas Gleixner wrote: > On Wed, 18 Jun 2008, Rafael J. Wysocki wrote: > > > I just checked that the original c1e series and the affected code in > > > tip are not different. IIRC you confirmed that the C1E patches would > > > work on your box. So I wonder what else got changed which causes these > > > problems. > > > > Well, to eliminate any possible correlations, do you have a version of the > > series or a single patch against the current mainline? > > http://userweb.kernel.org/~tglx/952f4a-c1e-apic.patch > http://userweb.kernel.org/~tglx/952f4a-c1e.patch > > c1e-apic is the forward port of the apic changes and c1e is the pure > c1e stuff. On my box it does not work w/o the c1e-apic one, but .... Unfortunately, with the c1e.patch on top of the apic.patch on top of the current mainline I get the same symptoms as with -next: - processes freeze - CPU loads are unreasonably high - things generally get stucked if I don't move the mouse or press keys Removing the the c1e.patch makes things work again. Thanks, Rafael ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-17 22:25 ` Rafael J. Wysocki 2008-06-18 8:02 ` Thomas Gleixner @ 2008-06-18 13:15 ` Ingo Molnar 1 sibling, 0 replies; 90+ messages in thread From: Ingo Molnar @ 2008-06-18 13:15 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Thomas Gleixner, Maciej W. Rozycki, Stephen Rothwell, linux-next, LKML, ACPI Devel Maling List, Len Brown * Rafael J. Wysocki <rjw@sisk.pl> wrote: > > Ah. If your fix is replaced with the appended one, the system > > happily works with C1E and highres. > > Scratch that. The symptoms appeared later this time, that's all. > I've just got b43 consuming 90+ % of the CPU time. :-( ah, ok. Discarded the patch :-/ Ingo ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-17 22:19 ` Rafael J. Wysocki 2008-06-17 22:25 ` Rafael J. Wysocki @ 2008-06-18 13:14 ` Ingo Molnar 1 sibling, 0 replies; 90+ messages in thread From: Ingo Molnar @ 2008-06-18 13:14 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Thomas Gleixner, Maciej W. Rozycki, Stephen Rothwell, linux-next, LKML, ACPI Devel Maling List, Len Brown * Rafael J. Wysocki <rjw@sisk.pl> wrote: > > Thanks, it eliminates the WARNING, but still the box doesn't work > > with the "x86: add C1E aware idle function" patch applied, even with > > 'highres=off'. > > > > The main symptom is that CPU loads are computed incorrectly (I got X > > using 126% of CPU time from 'top', for example). Apart from this, > > some processes (like gkrellm) seem to be 'frozen' and only change > > their state in 'jumps', as though they only got CPU from time to > > time at random. > > > > Reverting the above-mentioned patch fixes those problems. > > Ah. If your fix is replaced with the appended one, the system happily > works with C1E and highres. very nice! I have applied your fix to tip/x86/cpu. does this resolve all problems on your box, or is the IO-APIC problem still open? Ingo ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-16 22:38 ` Rafael J. Wysocki 2008-06-16 23:05 ` Rafael J. Wysocki @ 2008-06-17 20:59 ` Rafael J. Wysocki 2008-06-17 21:19 ` Maciej W. Rozycki 1 sibling, 1 reply; 90+ messages in thread From: Rafael J. Wysocki @ 2008-06-17 20:59 UTC (permalink / raw) To: Maciej W. Rozycki, Ingo Molnar Cc: Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Tuesday, 17 of June 2008, Rafael J. Wysocki wrote: > On Monday, 16 of June 2008, Maciej W. Rozycki wrote: > > On Mon, 16 Jun 2008, Rafael J. Wysocki wrote: > > > > > > > commit 7e3530cd98a0c6ab38f5898e855a5beffab26561 > > > > > Author: Maciej W. Rozycki <macro@linux-mips.org> > > > > > Date: Tue May 27 21:19:51 2008 +0100 > > > > > > > > > > x86: I/O APIC: timer through 8259A second-chance > > > > > > > > > > Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org> > > > > > Signed-off-by: Ingo Molnar <mingo@elte.hu> > > > > > > > > Can I have .config used and a full bootstrap log from that system with > > > > the patch still applied? > > > > > > That may be difficult, because with the patch applied the box either doesn't > > > boot at all, or works unreliably when booted (depending on the set of patches > > > applied on top of it). > > > > Serial console? > > No, this box doesn't have any serial ports. It has a FireWire one, but I don't > have a matching cable ... > > > I'm most interested in one from a configuration that > > does not boot at all as that's easier to reproduce, determine the cause > > and verify whether a change fixes the problem or not. Other > > configurations may then be tested with the fix in place. > > With the -next from today (20080616) I get a different picture. > > Without any patches on top it boots, but the fan is turned 100% on as soon as > the ACPI modules get loaded, regardless of the temperature (normally it does > that above 75^o C, which is impossible to get normally, because there are 3 > temperature trip points below that level; generally the hardware only does that > when overheating). After that, things start to go _very_ slow, like 10x slower > than usually in X and somewhat slower in the fb console, but I was able to get > a dmesg output. This is reproducible 100% of the time. > > With commit 7e3530cd98a0c6ab38f5898e855a5beffab26561 reverted the box seems to > work normally. To debug this problem a bit more, I applied the following change: --- linux-next.orig/arch/x86/kernel/io_apic_64.c +++ linux-next/arch/x86/kernel/io_apic_64.c @@ -1667,7 +1667,7 @@ static inline void __init check_timer(vo pin2 = ioapic_i8259.pin; apic2 = ioapic_i8259.apic; - apic_printk(APIC_VERBOSE,KERN_INFO "..TIMER: vector=0x%02X apic1=%d pin1=%d apic2=%d pin2=%d\n", + printk(KERN_CRIT "TIMER: vector=0x%02X apic1=%d pin1=%d apic2=%d pin2=%d\n", cfg->vector, apic1, pin1, apic2, pin2); if (pin1 != -1) { and found that apic1=0, pin1=2, apic2=-1, pin2=-1. Moreover, the (!no_timer_check && timer_irq_works()) test evidently fails, so the timer cannot be connected to apic1, but the patch forcibly ignores that, which in turn, on this particular box, confuses the heck out of the northbridge. May I gently ask that the patch ("x86: I/O APIC: timer through 8259A second-chance") be reverted? Thanks, Rafael ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-17 20:59 ` Rafael J. Wysocki @ 2008-06-17 21:19 ` Maciej W. Rozycki 2008-06-17 21:38 ` Rafael J. Wysocki 0 siblings, 1 reply; 90+ messages in thread From: Maciej W. Rozycki @ 2008-06-17 21:19 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Tue, 17 Jun 2008, Rafael J. Wysocki wrote: > May I gently ask that the patch ("x86: I/O APIC: timer through 8259A second-chance") > be reverted? We're trying to find a solution for a long-standing problem and this patch is a step in that direction. We need to find out exactly what is going wrong with the HP nx6325 system and removing the patch would make us lose the opportunity to get things right in this area. At the time I submitted that patch I warned a lot of testing would be required before it goes upstream and hopefully my request will get honored. If you do not want to participate in testing for whatever reason, you have the right to do so, but I insist on the patch to stay at least until we know the source of the problem and conclude there is no other way to get it fixed. Len reported he's got the same system and it behaves the same, so I hope he'll be able to do the testing if you decide to opt out. Unfortunately the 64-bit variation has a lot of necessary logging disabled by default (as you have now discovered with the need to rename apic_printk() to printk()), so my plan is to cook up a patch to enable all the available logging facilities around that code first. I was very tired yesterday and could not afford having a look at the logs -- sorry about that. I'll try to do it tonight and see if there is anything else I can do. Maciej ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-17 21:19 ` Maciej W. Rozycki @ 2008-06-17 21:38 ` Rafael J. Wysocki 2008-06-17 22:53 ` Rafael J. Wysocki 0 siblings, 1 reply; 90+ messages in thread From: Rafael J. Wysocki @ 2008-06-17 21:38 UTC (permalink / raw) To: Maciej W. Rozycki, Ingo Molnar Cc: Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Tuesday, 17 of June 2008, Maciej W. Rozycki wrote: > On Tue, 17 Jun 2008, Rafael J. Wysocki wrote: > > > May I gently ask that the patch ("x86: I/O APIC: timer through 8259A second-chance") > > be reverted? > > We're trying to find a solution for a long-standing problem and this > patch is a step in that direction. We need to find out exactly what is > going wrong with the HP nx6325 system and removing the patch would make us > lose the opportunity to get things right in this area. At the time I > submitted that patch I warned a lot of testing would be required before it > goes upstream and hopefully my request will get honored. If you do not > want to participate in testing for whatever reason, you have the right to > do so, but I insist on the patch to stay at least until we know the source > of the problem and conclude there is no other way to get it fixed. Len > reported he's got the same system and it behaves the same, so I hope he'll > be able to do the testing if you decide to opt out. I can do the testing actually, but IMO putting that patch into linux-next was a mistake. > Unfortunately the 64-bit variation has a lot of necessary logging > disabled by default (as you have now discovered with the need to rename > apic_printk() to printk()), so my plan is to cook up a patch to enable all > the available logging facilities around that code first. Well, that's easy. I can send you a dmesg output with all of the printk()s in there functional if that helps, but frankly I don't see how this is going to get you more information than I've already posted. Thanks, Rafael ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-17 21:38 ` Rafael J. Wysocki @ 2008-06-17 22:53 ` Rafael J. Wysocki 2008-06-18 4:02 ` Maciej W. Rozycki 0 siblings, 1 reply; 90+ messages in thread From: Rafael J. Wysocki @ 2008-06-17 22:53 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Tuesday, 17 of June 2008, Rafael J. Wysocki wrote: > On Tuesday, 17 of June 2008, Maciej W. Rozycki wrote: > > On Tue, 17 Jun 2008, Rafael J. Wysocki wrote: > > > > > May I gently ask that the patch ("x86: I/O APIC: timer through 8259A second-chance") > > > be reverted? > > > > We're trying to find a solution for a long-standing problem and this > > patch is a step in that direction. We need to find out exactly what is > > going wrong with the HP nx6325 system and removing the patch would make us > > lose the opportunity to get things right in this area. At the time I > > submitted that patch I warned a lot of testing would be required before it > > goes upstream and hopefully my request will get honored. If you do not > > want to participate in testing for whatever reason, you have the right to > > do so, but I insist on the patch to stay at least until we know the source > > of the problem and conclude there is no other way to get it fixed. Len > > reported he's got the same system and it behaves the same, so I hope he'll > > be able to do the testing if you decide to opt out. > > I can do the testing actually, but IMO putting that patch into linux-next was a > mistake. > > > Unfortunately the 64-bit variation has a lot of necessary logging > > disabled by default (as you have now discovered with the need to rename > > apic_printk() to printk()), so my plan is to cook up a patch to enable all > > the available logging facilities around that code first. > > Well, that's easy. I can send you a dmesg output with all of the printk()s in > there functional if that helps, but frankly I don't see how this is going to > get you more information than I've already posted. Here you go. Below is the relevant snippet from the yesterday's linux-next dmesg with the patches: "x86: I/O APIC: timer through 8259A second-chance" "x86: add C1E aware idle function" reverted and the appended debug patch applied. [ 0.108006] TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 [ 0.108006] ..MP-BIOS bug: 8254 timer not connected to IO-APIC [ 0.108006] ...trying to set up timer (IRQ0) through the 8259A ... <2> failed [ 0.108006] ...trying to set up timer as Virtual Wire IRQ...<2> works. The entire dmesg is at: http://www.sisk.pl/kernel/debug/20080616/dmesg-4.log Thanks, Rafael --- arch/x86/kernel/io_apic_64.c | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) Index: linux-next/arch/x86/kernel/io_apic_64.c =================================================================== --- linux-next.orig/arch/x86/kernel/io_apic_64.c +++ linux-next/arch/x86/kernel/io_apic_64.c @@ -1667,7 +1667,7 @@ static inline void __init check_timer(vo pin2 = ioapic_i8259.pin; apic2 = ioapic_i8259.apic; - apic_printk(APIC_VERBOSE,KERN_INFO "..TIMER: vector=0x%02X apic1=%d pin1=%d apic2=%d pin2=%d\n", + printk(KERN_CRIT "TIMER: vector=0x%02X apic1=%d pin1=%d apic2=%d pin2=%d\n", cfg->vector, apic1, pin1, apic2, pin2); if (pin1 != -1) { @@ -1686,14 +1686,14 @@ static inline void __init check_timer(vo goto out; } clear_IO_APIC_pin(apic1, pin1); - apic_printk(APIC_QUIET,KERN_ERR "..MP-BIOS bug: 8254 timer not " + printk(KERN_CRIT "..MP-BIOS bug: 8254 timer not " "connected to IO-APIC\n"); } - apic_printk(APIC_VERBOSE,KERN_INFO "...trying to set up timer (IRQ0) " + printk(KERN_CRIT "...trying to set up timer (IRQ0) " "through the 8259A ... "); if (pin2 != -1) { - apic_printk(APIC_VERBOSE,"\n..... (found apic %d pin %d) ...", + printk(KERN_CRIT "\n..... (found apic %d pin %d) ...", apic2, pin2); /* * legacy devices should be connected to IO APIC #0 @@ -1702,7 +1702,7 @@ static inline void __init check_timer(vo unmask_IO_APIC_irq(0); enable_8259A_irq(0); if (timer_irq_works()) { - apic_printk(APIC_VERBOSE," works.\n"); + printk(KERN_CRIT " works.\n"); timer_through_8259 = 1; nmi_watchdog_default(); if (nmi_watchdog == NMI_IO_APIC) { @@ -1718,28 +1718,28 @@ static inline void __init check_timer(vo disable_8259A_irq(0); clear_IO_APIC_pin(apic2, pin2); } - apic_printk(APIC_VERBOSE," failed.\n"); + printk(KERN_CRIT " failed.\n"); if (nmi_watchdog == NMI_IO_APIC) { - printk(KERN_WARNING "timer doesn't work through the IO-APIC - disabling NMI Watchdog!\n"); + printk(KERN_CRIT "timer doesn't work through the IO-APIC - disabling NMI Watchdog!\n"); nmi_watchdog = NMI_NONE; } - apic_printk(APIC_VERBOSE, KERN_INFO "...trying to set up timer as Virtual Wire IRQ..."); + printk(KERN_CRIT "...trying to set up timer as Virtual Wire IRQ..."); irq_desc[0].chip = &lapic_irq_type; apic_write(APIC_LVT0, APIC_DM_FIXED | cfg->vector); /* Fixed mode */ enable_8259A_irq(0); if (timer_irq_works()) { - apic_printk(APIC_VERBOSE," works.\n"); + printk(KERN_CRIT " works.\n"); goto out; } disable_8259A_irq(0); apic_write(APIC_LVT0, APIC_LVT_MASKED | APIC_DM_FIXED | cfg->vector); - apic_printk(APIC_VERBOSE," failed.\n"); + printk(KERN_CRIT " failed.\n"); - apic_printk(APIC_VERBOSE, KERN_INFO "...trying to set up timer as ExtINT IRQ..."); + printk(KERN_CRIT "...trying to set up timer as ExtINT IRQ..."); init_8259A(0); make_8259A_irq(0); @@ -1748,10 +1748,10 @@ static inline void __init check_timer(vo unlock_ExtINT_logic(); if (timer_irq_works()) { - apic_printk(APIC_VERBOSE," works.\n"); + printk(KERN_CRIT " works.\n"); goto out; } - apic_printk(APIC_VERBOSE," failed :(.\n"); + printk(KERN_CRIT " failed :(.\n"); panic("IO-APIC + timer doesn't work! Try using the 'noapic' kernel parameter\n"); out: local_irq_restore(flags); ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-17 22:53 ` Rafael J. Wysocki @ 2008-06-18 4:02 ` Maciej W. Rozycki 2008-06-18 19:06 ` Cyrill Gorcunov 2008-06-18 22:11 ` Rafael J. Wysocki 0 siblings, 2 replies; 90+ messages in thread From: Maciej W. Rozycki @ 2008-06-18 4:02 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Wed, 18 Jun 2008, Rafael J. Wysocki wrote: > Here you go. Below is the relevant snippet from the yesterday's linux-next > dmesg with the patches: > "x86: I/O APIC: timer through 8259A second-chance" > "x86: add C1E aware idle function" > reverted and the appended debug patch applied. > > [ 0.108006] TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 > [ 0.108006] ..MP-BIOS bug: 8254 timer not connected to IO-APIC > [ 0.108006] ...trying to set up timer (IRQ0) through the 8259A ... <2> failed > [ 0.108006] ...trying to set up timer as Virtual Wire IRQ...<2> works. > > The entire dmesg is at: http://www.sisk.pl/kernel/debug/20080616/dmesg-4.log Thanks -- this is very important and useful information as it shows the exact alternative used. With such a configuration the "x86: I/O APIC: timer through 8259A second-chance" patch should not matter, because the only change it introduces is an attempt to try the same I/O APIC pin again, but with the IRQ0 line of the master 8259A enabled. That's not a terribly unusual configuration and nothing should get confused in the system. Barring the unlikely possibility of the 8259A actually being wired to INTIN2 of the I/O APIC I can see two possible explanations: 1. The 8259A interrupt actually escapes to the CPU somehow and is handled as an ExtINTA interrupt. This would make the code in check_timer() decide it has found a working configuration, while actually it has been fooled. 2. There is a bug in this patch or an assumption it makes which results in the state of some component not to be restored correctly. Unfortunately I have no resources to test the 64-bit variation of the code, so something may have escaped my attention. I'd like to find out which one is the case -- can you please reapply the patch and send me the corresponding section of the bootstrap log? If the system hangs before you can retrieve the log, please just place: while (1); or something like that after the out: label in check_timer(). Thanks. Maciej ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-18 4:02 ` Maciej W. Rozycki @ 2008-06-18 19:06 ` Cyrill Gorcunov 2008-06-18 22:36 ` Maciej W. Rozycki 2008-06-18 22:11 ` Rafael J. Wysocki 1 sibling, 1 reply; 90+ messages in thread From: Cyrill Gorcunov @ 2008-06-18 19:06 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Rafael J. Wysocki, Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown [Maciej W. Rozycki - Wed, Jun 18, 2008 at 05:02:48AM +0100] | On Wed, 18 Jun 2008, Rafael J. Wysocki wrote: | | > Here you go. Below is the relevant snippet from the yesterday's linux-next | > dmesg with the patches: | > "x86: I/O APIC: timer through 8259A second-chance" | > "x86: add C1E aware idle function" | > reverted and the appended debug patch applied. | > | > [ 0.108006] TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 | > [ 0.108006] ..MP-BIOS bug: 8254 timer not connected to IO-APIC | > [ 0.108006] ...trying to set up timer (IRQ0) through the 8259A ... <2> failed | > [ 0.108006] ...trying to set up timer as Virtual Wire IRQ...<2> works. | > | > The entire dmesg is at: http://www.sisk.pl/kernel/debug/20080616/dmesg-4.log | | Thanks -- this is very important and useful information as it shows the | exact alternative used. | | With such a configuration the "x86: I/O APIC: timer through 8259A | second-chance" patch should not matter, because the only change it | introduces is an attempt to try the same I/O APIC pin again, but with the | IRQ0 line of the master 8259A enabled. That's not a terribly unusual | configuration and nothing should get confused in the system. | | Barring the unlikely possibility of the 8259A actually being wired to | INTIN2 of the I/O APIC I can see two possible explanations: | | 1. The 8259A interrupt actually escapes to the CPU somehow and is handled | as an ExtINTA interrupt. This would make the code in check_timer() | decide it has found a working configuration, while actually it has been | fooled. Maciej, that is why we get 'received illegal vector'? [ 129.092151] APIC error on CPU1: 00(40) | | 2. There is a bug in this patch or an assumption it makes which results | in the state of some component not to be restored correctly. | Unfortunately I have no resources to test the 64-bit variation of the | code, so something may have escaped my attention. | | I'd like to find out which one is the case -- can you please reapply the | patch and send me the corresponding section of the bootstrap log? If the | system hangs before you can retrieve the log, please just place: | | while (1); | | or something like that after the out: label in check_timer(). | | Thanks. | | Maciej | - Cyrill - ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-18 19:06 ` Cyrill Gorcunov @ 2008-06-18 22:36 ` Maciej W. Rozycki 2008-06-20 18:59 ` Cyrill Gorcunov 0 siblings, 1 reply; 90+ messages in thread From: Maciej W. Rozycki @ 2008-06-18 22:36 UTC (permalink / raw) To: Cyrill Gorcunov Cc: Rafael J. Wysocki, Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Wed, 18 Jun 2008, Cyrill Gorcunov wrote: > | 1. The 8259A interrupt actually escapes to the CPU somehow and is handled > | as an ExtINTA interrupt. This would make the code in check_timer() > | decide it has found a working configuration, while actually it has been > | fooled. > > Maciej, that is why we get 'received illegal vector'? > > [ 129.092151] APIC error on CPU1: 00(40) No, but that's an interesting observation, thank you -- well spotted! ExtINTA stands for an "External INTA cycle" which is passed through from the CPU down to the system bus instead of being intercepted by the local APIC unit as usually. In response to the INTA cycle one of the 8259A chips (either the master or the slave, depending on the source of the interrupt selected for handling) supplies the vector directly to the CPU through PCI (or whatever kind of bus links the legacy bridge with the host bridge) and then the FSB. Therefore the vector bypasses all the APIC circuitry and cannot result in an APIC error interrupt. Instead the message quoted means an APIC input is misprogrammed somewhere. This error happens if an interrupt is signalled to an unmasked APIC input which uses the Fixed or Lowest-Priority delivery mode and its vector implies priority below the minimum permitted, that is in the range from 0 to 15. We have code already in place in io_apic_{32,64}.c that can be used to find out the offender with a piece of code like this (#if 0 has to be deactivated for this to work and they may be bit rot bugs to be fixed): int __init all_pic_dump(void) { int v = apic_verbosity; apic_verbosity = APIC_DEBUG; print_IO_APIC(); print_all_local_APICs(); print_PIC(); apic_verbosity = v; return 0; } late_initcall(all_pic_dump); if somebody is willing to aid with debugging this problem. Maciej ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-18 22:36 ` Maciej W. Rozycki @ 2008-06-20 18:59 ` Cyrill Gorcunov 2008-06-20 20:44 ` Maciej W. Rozycki 0 siblings, 1 reply; 90+ messages in thread From: Cyrill Gorcunov @ 2008-06-20 18:59 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Rafael J. Wysocki, Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown [Maciej W. Rozycki - Wed, Jun 18, 2008 at 11:36:16PM +0100] | On Wed, 18 Jun 2008, Cyrill Gorcunov wrote: | | > | 1. The 8259A interrupt actually escapes to the CPU somehow and is handled | > | as an ExtINTA interrupt. This would make the code in check_timer() | > | decide it has found a working configuration, while actually it has been | > | fooled. | > | > Maciej, that is why we get 'received illegal vector'? | > | > [ 129.092151] APIC error on CPU1: 00(40) | | No, but that's an interesting observation, thank you -- well spotted! | | ExtINTA stands for an "External INTA cycle" which is passed through from | the CPU down to the system bus instead of being intercepted by the local | APIC unit as usually. In response to the INTA cycle one of the 8259A | chips (either the master or the slave, depending on the source of the | interrupt selected for handling) supplies the vector directly to the CPU | through PCI (or whatever kind of bus links the legacy bridge with the host | bridge) and then the FSB. Therefore the vector bypasses all the APIC | circuitry and cannot result in an APIC error interrupt. | | Instead the message quoted means an APIC input is misprogrammed | somewhere. This error happens if an interrupt is signalled to an unmasked | APIC input which uses the Fixed or Lowest-Priority delivery mode and its | vector implies priority below the minimum permitted, that is in the range | from 0 to 15. | | We have code already in place in io_apic_{32,64}.c that can be used to | find out the offender with a piece of code like this (#if 0 has to be | deactivated for this to work and they may be bit rot bugs to be fixed): | | int __init all_pic_dump(void) | { | int v = apic_verbosity; | | apic_verbosity = APIC_DEBUG; | print_IO_APIC(); | print_all_local_APICs(); | print_PIC(); | apic_verbosity = v; | | return 0; | } | | late_initcall(all_pic_dump); | | if somebody is willing to aid with debugging this problem. | | Maciej | Thanks, Maciej, i would really like to help... but I can't even hit this bug on my laptop :( - Cyrill - ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-20 18:59 ` Cyrill Gorcunov @ 2008-06-20 20:44 ` Maciej W. Rozycki 0 siblings, 0 replies; 90+ messages in thread From: Maciej W. Rozycki @ 2008-06-20 20:44 UTC (permalink / raw) To: Cyrill Gorcunov Cc: Rafael J. Wysocki, Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Fri, 20 Jun 2008, Cyrill Gorcunov wrote: > i would really like to help... but I can't even hit this > bug on my laptop :( Hmm, most people would be rather happy not to have a given bug on their piece of hardware... ;) Maciej ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-18 4:02 ` Maciej W. Rozycki 2008-06-18 19:06 ` Cyrill Gorcunov @ 2008-06-18 22:11 ` Rafael J. Wysocki 2008-06-18 23:39 ` Maciej W. Rozycki 1 sibling, 1 reply; 90+ messages in thread From: Rafael J. Wysocki @ 2008-06-18 22:11 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Wednesday, 18 of June 2008, Maciej W. Rozycki wrote: > On Wed, 18 Jun 2008, Rafael J. Wysocki wrote: > > > Here you go. Below is the relevant snippet from the yesterday's linux-next > > dmesg with the patches: > > "x86: I/O APIC: timer through 8259A second-chance" > > "x86: add C1E aware idle function" > > reverted and the appended debug patch applied. > > > > [ 0.108006] TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 > > [ 0.108006] ..MP-BIOS bug: 8254 timer not connected to IO-APIC > > [ 0.108006] ...trying to set up timer (IRQ0) through the 8259A ... <2> failed > > [ 0.108006] ...trying to set up timer as Virtual Wire IRQ...<2> works. > > > > The entire dmesg is at: http://www.sisk.pl/kernel/debug/20080616/dmesg-4.log > > Thanks -- this is very important and useful information as it shows the > exact alternative used. > > With such a configuration the "x86: I/O APIC: timer through 8259A > second-chance" patch should not matter, because the only change it > introduces is an attempt to try the same I/O APIC pin again, but with the > IRQ0 line of the master 8259A enabled. That's not a terribly unusual > configuration and nothing should get confused in the system. But it _does_ get confused, really. > Barring the unlikely possibility of the 8259A actually being wired to > INTIN2 of the I/O APIC I can see two possible explanations: > > 1. The 8259A interrupt actually escapes to the CPU somehow and is handled > as an ExtINTA interrupt. This would make the code in check_timer() > decide it has found a working configuration, while actually it has been > fooled. > > 2. There is a bug in this patch or an assumption it makes which results > in the state of some component not to be restored correctly. > Unfortunately I have no resources to test the 64-bit variation of the > code, so something may have escaped my attention. > > I'd like to find out which one is the case -- can you please reapply the > patch and send me the corresponding section of the bootstrap log? If the > system hangs before you can retrieve the log, please just place: Here you go: [ 0.108006] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 [ 0.108006] ..MP-BIOS bug: 8254 timer not connected to IO-APIC [ 0.108006] ...trying to set up timer (IRQ0) through the 8259A ... <3> [ 0.108006] ..... (found apic 0 pin 2) ...<3> works. The full dmesg is at: http://www.sisk.pl/kernel/debug/20080618/dmesg-1.log Thanks, Rafael ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-18 22:11 ` Rafael J. Wysocki @ 2008-06-18 23:39 ` Maciej W. Rozycki 2008-06-19 0:25 ` Rafael J. Wysocki 2008-06-19 9:35 ` Ingo Molnar 0 siblings, 2 replies; 90+ messages in thread From: Maciej W. Rozycki @ 2008-06-18 23:39 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Thu, 19 Jun 2008, Rafael J. Wysocki wrote: > > With such a configuration the "x86: I/O APIC: timer through 8259A > > second-chance" patch should not matter, because the only change it > > introduces is an attempt to try the same I/O APIC pin again, but with the > > IRQ0 line of the master 8259A enabled. That's not a terribly unusual > > configuration and nothing should get confused in the system. > > But it _does_ get confused, really. Something certainly gets confused, but so far I am not sure which bit exactly it is, are you? > > Barring the unlikely possibility of the 8259A actually being wired to > > INTIN2 of the I/O APIC I can see two possible explanations: > > > > 1. The 8259A interrupt actually escapes to the CPU somehow and is handled > > as an ExtINTA interrupt. This would make the code in check_timer() > > decide it has found a working configuration, while actually it has been > > fooled. [...] > Here you go: > > [ 0.108006] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 > [ 0.108006] ..MP-BIOS bug: 8254 timer not connected to IO-APIC > [ 0.108006] ...trying to set up timer (IRQ0) through the 8259A ... <3> > [ 0.108006] ..... (found apic 0 pin 2) ...<3> works. > > The full dmesg is at: http://www.sisk.pl/kernel/debug/20080618/dmesg-1.log Thanks. In this case I suspect the case #1 quoted above happens, that is the 8259A manages to deliver its interrupt somehow. Note at this stage it is meant to be in the AEOI mode, so it can happily resubmit the interrupt indefinitely with no additional handling as long as it receives INTA cycles. Can you please try the patch below on top of "x86: I/O APIC: timer through 8259A second-chance" to see whether my hypothesis is true? It modifies the through-8259A setup path so that the APIC input gets masked, but the 8259A has the timer interrupt still enabled. Let me know how the timer interrupt is routed in this case. BTW, do we have any piece of technical information about the chipset used? The southbridge used is an ATI SB400, which is where I would normally expect two 8259A and an I/O APIC core to be placed. Maciej --- a/arch/x86/kernel/io_apic_64.c 2008-06-18 22:53:34.000000000 +0000 +++ b/arch/x86/kernel/io_apic_64.c 2008-06-18 22:58:45.000000000 +0000 @@ -1714,6 +1714,7 @@ static inline void __init check_timer(vo /* replace_pin_at_irq(0, apic1, pin1, apic2, pin2); */ setup_timer_IRQ0_pin(apic2, pin2, cfg->vector); unmask_IO_APIC_irq(0); + clear_IO_APIC_pin(apic2, pin2); enable_8259A_irq(0); if (timer_irq_works()) { apic_printk(APIC_VERBOSE," works.\n"); ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-18 23:39 ` Maciej W. Rozycki @ 2008-06-19 0:25 ` Rafael J. Wysocki 2008-06-20 0:35 ` Maciej W. Rozycki 2008-06-19 9:35 ` Ingo Molnar 1 sibling, 1 reply; 90+ messages in thread From: Rafael J. Wysocki @ 2008-06-19 0:25 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Thursday, 19 of June 2008, Maciej W. Rozycki wrote: > On Thu, 19 Jun 2008, Rafael J. Wysocki wrote: > > > > With such a configuration the "x86: I/O APIC: timer through 8259A > > > second-chance" patch should not matter, because the only change it > > > introduces is an attempt to try the same I/O APIC pin again, but with the > > > IRQ0 line of the master 8259A enabled. That's not a terribly unusual > > > configuration and nothing should get confused in the system. > > > > But it _does_ get confused, really. > > Something certainly gets confused, but so far I am not sure which bit > exactly it is, are you? No, I'm not. > > > Barring the unlikely possibility of the 8259A actually being wired to > > > INTIN2 of the I/O APIC I can see two possible explanations: > > > > > > 1. The 8259A interrupt actually escapes to the CPU somehow and is handled > > > as an ExtINTA interrupt. This would make the code in check_timer() > > > decide it has found a working configuration, while actually it has been > > > fooled. > [...] > > Here you go: > > > > [ 0.108006] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 > > [ 0.108006] ..MP-BIOS bug: 8254 timer not connected to IO-APIC > > [ 0.108006] ...trying to set up timer (IRQ0) through the 8259A ... <3> > > [ 0.108006] ..... (found apic 0 pin 2) ...<3> works. > > > > The full dmesg is at: http://www.sisk.pl/kernel/debug/20080618/dmesg-1.log > > Thanks. In this case I suspect the case #1 quoted above happens, that is > the 8259A manages to deliver its interrupt somehow. Note at this stage it > is meant to be in the AEOI mode, so it can happily resubmit the interrupt > indefinitely with no additional handling as long as it receives INTA > cycles. > > Can you please try the patch below on top of "x86: I/O APIC: timer > through 8259A second-chance" to see whether my hypothesis is true? It > modifies the through-8259A setup path so that the APIC input gets masked, > but the 8259A has the timer interrupt still enabled. Let me know how the > timer interrupt is routed in this case. That helped a lot, the system seems to work normally now. Here's the relevant snippet from dmesg: [ 0.108006] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 [ 0.108006] ..MP-BIOS bug: 8254 timer not connected to IO-APIC [ 0.108006] ...trying to set up timer (IRQ0) through the 8259A ... <3> [ 0.108006] ..... (found apic 0 pin 2) ...<3> failed. [ 0.108006] ...trying to set up timer as Virtual Wire IRQ...<3> works. and the whole thing is at: http://www.sisk.pl/kernel/debug/20080618/dmesg-2.log > BTW, do we have any piece of technical information about the chipset > used? I, personally, don't have any and AMD only has SB600 documentation on its web page (it's still marked as "AMD confidential" ;-)). > The southbridge used is an ATI SB400, which is where I would > normally expect two 8259A and an I/O APIC core to be placed. There is an interrupt controller in there, but I'm not sure if there's any 8259A. The northbridge is on the CPU, actually. Thanks, Rafael ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-19 0:25 ` Rafael J. Wysocki @ 2008-06-20 0:35 ` Maciej W. Rozycki 2008-06-20 11:53 ` Rafael J. Wysocki 0 siblings, 1 reply; 90+ messages in thread From: Maciej W. Rozycki @ 2008-06-20 0:35 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Thu, 19 Jun 2008, Rafael J. Wysocki wrote: > That helped a lot, the system seems to work normally now. > > Here's the relevant snippet from dmesg: > > [ 0.108006] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 > [ 0.108006] ..MP-BIOS bug: 8254 timer not connected to IO-APIC > [ 0.108006] ...trying to set up timer (IRQ0) through the 8259A ... <3> > [ 0.108006] ..... (found apic 0 pin 2) ...<3> failed. > [ 0.108006] ...trying to set up timer as Virtual Wire IRQ...<3> works. > > and the whole thing is at: http://www.sisk.pl/kernel/debug/20080618/dmesg-2.log Hmm, that only proved the 8259A is indeed wired to the pin #2 of the I/O APIC. > I, personally, don't have any and AMD only has SB600 documentation on its > web page (it's still marked as "AMD confidential" ;-)). Well, the IC block is most likely the same as that's not rocket science and once done there is no need to fiddle with that. That written, I am afraid there is nothing useful about the IC in the document, except that it's there and consists of an I/O APIC providing 24 inputs and the usual pair of 8259A cores. Thanks for the reference anyway. > There is an interrupt controller in there, but I'm not sure if there's any > 8259A. The northbridge is on the CPU, actually. I will praise the day someone ships an x86 machine without an 8259A core! As expressed in another mail I suspect there may actually be a direct route from the 8254 to INTIN0 in the southbridge -- this is what other bootstrap logs seen in the Internet suggest. This would mean this particular BIOS is buggy (is it the latest version?) and provides an incorrect IRQ override in its ACPI tables, for example because the responsible block has been blindly copied from a machine using a commoner wiring. This could be moderately easily fixed up with a quirk based on the PCI ID (after checking it again, we actually used to have a quirk for ATI in this area, but the way it was done suggests the issue was not understood well enough). Could you please remove the hack sent yesterday and test the patch provided below? I do hope it builds, but I have no immediate means to check it. Please report the output. The intent is to test INTIN0 directly before testing INTIN2 through the 8259A. Thanks. Aside of that, what I have gathered from your reports (please correct me if I have got it wrong) is that when the through-8259A mode is used, then after a while 8254 timer interrupts stop arriving. What's interesting, the "Virtual Wire IRQ" seems to work for you correctly (that's quite an odd setup where a local APIC input is used in the native mode -- please post /proc/interrupts for confirmation), which in turn implies the master 8259A drives its INT output as we expect. Why would the I/O APIC input have problems then? Hmm... Maciej patch-2.6.26-rc1-20080505-ioapic-replace-debug-1 diff -up --recursive --new-file linux-2.6.26-rc1-20080505.macro/arch/x86/kernel/io_apic_64.c linux-2.6.26-rc1-20080505/arch/x86/kernel/io_apic_64.c --- linux-2.6.26-rc1-20080505.macro/arch/x86/kernel/io_apic_64.c 2008-06-18 03:24:54.000000000 +0000 +++ linux-2.6.26-rc1-20080505/arch/x86/kernel/io_apic_64.c 2008-06-20 00:12:39.000000000 +0000 @@ -360,6 +360,26 @@ static void add_pin_to_irq(unsigned int entry->pin = pin; } +/* + * Reroute an IRQ to a different pin. + */ +static void __init replace_pin_at_irq(unsigned int irq, + int oldapic, int oldpin, + int newapic, int newpin) +{ + struct irq_pin_list *entry = irq_2_pin + irq; + + while (1) { + if (entry->apic == oldapic && entry->pin == oldpin) { + entry->apic = newapic; + entry->pin = newpin; + } + if (!entry->next) + break; + entry = irq_2_pin + entry->next; + } +} + #define DO_ACTION(name,R,ACTION, FINAL) \ \ @@ -1679,6 +1699,11 @@ static inline void __init check_timer(vo apic2 = apic1; } + replace_pin_at_irq(0, 0, 0, apic1, pin1); + apic1 = 0; + pin1 = 0; + setup_timer_IRQ0_pin(apic1, pin1, cfg->vector); + if (pin1 != -1) { /* * Ok, does IRQ0 through the IOAPIC work? @@ -1711,7 +1736,7 @@ static inline void __init check_timer(vo /* * legacy devices should be connected to IO APIC #0 */ - /* replace_pin_at_irq(0, apic1, pin1, apic2, pin2); */ + replace_pin_at_irq(0, apic1, pin1, apic2, pin2); setup_timer_IRQ0_pin(apic2, pin2, cfg->vector); unmask_IO_APIC_irq(0); enable_8259A_irq(0); ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-20 0:35 ` Maciej W. Rozycki @ 2008-06-20 11:53 ` Rafael J. Wysocki 2008-06-20 11:57 ` Matthew Garrett 2008-06-21 1:49 ` Maciej W. Rozycki 0 siblings, 2 replies; 90+ messages in thread From: Rafael J. Wysocki @ 2008-06-20 11:53 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Friday, 20 of June 2008, Maciej W. Rozycki wrote: > On Thu, 19 Jun 2008, Rafael J. Wysocki wrote: > > > That helped a lot, the system seems to work normally now. > > > > Here's the relevant snippet from dmesg: > > > > [ 0.108006] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 > > [ 0.108006] ..MP-BIOS bug: 8254 timer not connected to IO-APIC > > [ 0.108006] ...trying to set up timer (IRQ0) through the 8259A ... <3> > > [ 0.108006] ..... (found apic 0 pin 2) ...<3> failed. > > [ 0.108006] ...trying to set up timer as Virtual Wire IRQ...<3> works. > > > > and the whole thing is at: http://www.sisk.pl/kernel/debug/20080618/dmesg-2.log > > Hmm, that only proved the 8259A is indeed wired to the pin #2 of the I/O > APIC. > > > I, personally, don't have any and AMD only has SB600 documentation on its > > web page (it's still marked as "AMD confidential" ;-)). > > Well, the IC block is most likely the same as that's not rocket science > and once done there is no need to fiddle with that. That written, I am > afraid there is nothing useful about the IC in the document, except that > it's there and consists of an I/O APIC providing 24 inputs and the usual > pair of 8259A cores. Thanks for the reference anyway. > > > There is an interrupt controller in there, but I'm not sure if there's any > > 8259A. The northbridge is on the CPU, actually. > > I will praise the day someone ships an x86 machine without an 8259A core! > > As expressed in another mail I suspect there may actually be a direct > route from the 8254 to INTIN0 in the southbridge -- this is what other > bootstrap logs seen in the Internet suggest. This would mean this > particular BIOS is buggy (is it the latest version?) and provides an > incorrect IRQ override in its ACPI tables, for example because the > responsible block has been blindly copied from a machine using a commoner > wiring. This could be moderately easily fixed up with a quirk based on > the PCI ID (after checking it again, we actually used to have a quirk for > ATI in this area, but the way it was done suggests the issue was not > understood well enough). > > Could you please remove the hack sent yesterday and test the patch > provided below? I do hope it builds, but I have no immediate means to > check it. Please report the output. The intent is to test INTIN0 > directly before testing INTIN2 through the 8259A. Thanks. Tested, doesn't work. The symptoms are exactly the same as with the unpatched kernel. This is the relevant snippet from dmesg: [ 0.108006] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 [ 0.108006] ..MP-BIOS bug: 8254 timer not connected to IO-APIC [ 0.108006] ...trying to set up timer (IRQ0) through the 8259A ... <3> [ 0.108006] ..... (found apic 0 pin 2) ...<3> works. and the whole thing is at: http://www.sisk.pl/kernel/debug/20080620/dmesg-1.log > Aside of that, what I have gathered from your reports (please correct me > if I have got it wrong) is that when the through-8259A mode is used, then > after a while 8254 timer interrupts stop arriving. What exactly I observe is that in this case: 1) The cooling fan is 100% on, as though the box were overheating, which seems to indicate some serious confusion of the platform (the mechanism turning the fan 100% on is supposed to be transparent to software). 2) Everything seems to slow down substantially, at least as soon as X is started. 3) The box cannot reboot, ie. it turns everything off as expected, but when the BIOS is supposed to restart the box, it just hangs solid. > What's interesting, the "Virtual Wire IRQ" seems to work for you correctly > (that's quite an odd setup where a local APIC input is used in the native > mode -- please post /proc/interrupts for confirmation), CPU0 CPU1 0: 885 37234 IO-APIC-edge timer 1: 1 250 IO-APIC-edge i8042 8: 0 0 IO-APIC-edge rtc0 12: 4 148 IO-APIC-edge i8042 14: 568 52 IO-APIC-edge ide0 15: 0 0 IO-APIC-edge ide1 16: 5048 4555 IO-APIC-fasteoi sata_sil, HDA Intel 18: 45 110 IO-APIC-fasteoi b43 19: 11811 11973 IO-APIC-fasteoi ohci_hcd:usb1, ohci_hcd:usb2, ehci_hcd:usb3 20: 0 4 IO-APIC-fasteoi yenta, tifm_7xx1, ohci1394 21: 11695 1987 IO-APIC-fasteoi acpi 23: 883 115 IO-APIC-fasteoi eth0 NMI: 0 0 Non-maskable interrupts LOC: 36636 585 Local timer interrupts RES: 7982 4590 Rescheduling interrupts CAL: 260 75 function call interrupts TLB: 207 146 TLB shootdowns TRM: 0 0 Thermal event interrupts THR: 0 0 Threshold APIC interrupts SPU: 0 0 Spurious interrupts ERR: 1 (also available at: http://www.sisk.pl/kernel/debug/20080620/interrupts-1.txt). > which in turn implies the master 8259A drives its INT output as we expect. > Why would the I/O APIC input have problems then? Hmm... Because it's wired to something we're not aware of? Thanks, Rafael ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-20 11:53 ` Rafael J. Wysocki @ 2008-06-20 11:57 ` Matthew Garrett 2008-06-20 12:22 ` Rafael J. Wysocki 2008-06-21 1:49 ` Maciej W. Rozycki 1 sibling, 1 reply; 90+ messages in thread From: Matthew Garrett @ 2008-06-20 11:57 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Maciej W. Rozycki, Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Fri, Jun 20, 2008 at 01:53:58PM +0200, Rafael J. Wysocki wrote: > What exactly I observe is that in this case: > 1) The cooling fan is 100% on, as though the box were overheating, which seems > to indicate some serious confusion of the platform (the mechanism turning > the fan 100% on is supposed to be transparent to software). > 2) Everything seems to slow down substantially, at least as soon as X is > started. What does ACPI claim the trip points are set to in this case? On the 6125, if IRQ 2 is enabled in the APIC then the DSDT sets all the thermal trip points to 16 degrees C. I suspect this means that enabling IRQ 2 is the wrong thing to do on this chipset. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-20 11:57 ` Matthew Garrett @ 2008-06-20 12:22 ` Rafael J. Wysocki 2008-06-20 12:27 ` Matthew Garrett 2008-06-24 9:15 ` Pavel Machek 0 siblings, 2 replies; 90+ messages in thread From: Rafael J. Wysocki @ 2008-06-20 12:22 UTC (permalink / raw) To: Matthew Garrett Cc: Maciej W. Rozycki, Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Friday, 20 of June 2008, Matthew Garrett wrote: > On Fri, Jun 20, 2008 at 01:53:58PM +0200, Rafael J. Wysocki wrote: > > > What exactly I observe is that in this case: > > 1) The cooling fan is 100% on, as though the box were overheating, which seems > > to indicate some serious confusion of the platform (the mechanism turning > > the fan 100% on is supposed to be transparent to software). > > 2) Everything seems to slow down substantially, at least as soon as X is > > started. > > What does ACPI claim the trip points are set to in this case? On the > 6125, if IRQ 2 is enabled in the APIC then the DSDT sets all the thermal > trip points to 16 degrees C. I suspect this means that enabling IRQ 2 is > the wrong thing to do on this chipset. Ah, indeed, thanks for the hint. This is the output of $ cat /proc/acpi/thermal_zone/TZ*/trip_points in the failing case: critical (S5): 105 C passive: 16 C: tc1=1 tc2=2 tsp=100 devices=C000 C001 active[0]: 16 C: devices=C34F active[1]: 16 C: devices=C350 active[2]: 16 C: devices=C351 active[3]: 16 C: devices=C352 critical (S5): 100 C passive: 16 C: tc1=1 tc2=2 tsp=300 devices=C000 C001 critical (S5): 100 C passive: 16 C: tc1=1 tc2=2 tsp=300 devices=C000 C001 (also available at: http://www.sisk.pl/kernel/debug/20080620/trip-points.txt). So, the observed slowdown may be a result of throttling. Thanks, Rafael ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-20 12:22 ` Rafael J. Wysocki @ 2008-06-20 12:27 ` Matthew Garrett 2008-06-21 1:09 ` Maciej W. Rozycki 2008-06-24 9:15 ` Pavel Machek 1 sibling, 1 reply; 90+ messages in thread From: Matthew Garrett @ 2008-06-20 12:27 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Maciej W. Rozycki, Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Fri, Jun 20, 2008 at 02:22:11PM +0200, Rafael J. Wysocki wrote: > Ah, indeed, thanks for the hint. This is the output of Right. My recollection of this is somewhat hazy, so here's something I wrote a couple of years ago: "If you dig through the DSDT code for the 6125, you'll find a bit where it writes 0x14 to 0xfec00000 and then checks whether offset 0x12 from there is 1. In other words, it's checking if pin 2 of the io-apic is masked. If it's not masked (that is, offset 0x12 is 0 and irq 2 is enabled) it sets another bit in a register. This is then checked by the thermal zone code which as a result sets the thermal trip temperatures to 16 degrees Celsius. This bites when the acpi_skip_timer_override option is used in Linux." I have no idea what this code is for, but it's pretty clear that Windows sets it up in such a way that this isn't true. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-20 12:27 ` Matthew Garrett @ 2008-06-21 1:09 ` Maciej W. Rozycki 2008-06-21 1:40 ` Matthew Garrett 0 siblings, 1 reply; 90+ messages in thread From: Maciej W. Rozycki @ 2008-06-21 1:09 UTC (permalink / raw) To: Matthew Garrett Cc: Rafael J. Wysocki, Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Fri, 20 Jun 2008, Matthew Garrett wrote: > > Ah, indeed, thanks for the hint. This is the output of > > Right. My recollection of this is somewhat hazy, so here's something I > wrote a couple of years ago: > > "If you dig through the DSDT code for the 6125, you'll find a bit where > it writes 0x14 to 0xfec00000 and then checks whether offset 0x12 from > there is 1. In other words, it's checking if pin 2 of the io-apic is > masked. If it's not masked (that is, offset 0x12 is 0 and irq 2 is > enabled) it sets another bit in a register. This is then checked by the > thermal zone code which as a result sets the thermal trip temperatures > to 16 degrees Celsius. This bites when the acpi_skip_timer_override > option is used in Linux." > > I have no idea what this code is for, but it's pretty clear that Windows > sets it up in such a way that this isn't true. Thanks, that is a very useful insight indeed. I went through the effort to locate a DSDT dump for the nx6325. Here are the relevant parts, first the definition: OperationRegion (C253, SystemMemory, 0xFEC00000, 0x14) Field (C253, ByteAcc, NoLock, Preserve) { C08B, 8, Offset (0x10), Offset (0x12), C08C, 1 } So now we have got a block defined, which corresponds to the location of the I/O APIC and is 0x14 bytes long. That is not top quality code, I would say, but surely it achieves what it is meant to. Within that block two fields are defined: 1. An 8-bit one at the byte offset 0 -- that corresponds to the index register. 2. A 1-bit one at the byte offset 0x12 -- that corresponds to the bit #16 of the data register, which for redirection entries is the mask register. And then we have a method elsewhere, which uses the above definition: Method (_INI, 0, NotSerialized) { C084 () Store (0x00, \_SB.C074.C089.C08A) Store (0x14, C08B) If (LEqual (C08C, 0x00)) { Store (0x01, \_SB.C074.C089.C08A) } } _SB.C074.C089.C08A refers to a piece of 8-bit data at an offset of 0xf0 accessed through an index and data registers located at 0x72 and 0x73 in the port I/O space. That's probably an extended part of the NVRAM associated with the RTC. That location is referred from two places as follows: If (LEqual (\_SB.C074.C089.C08A, 0x01)) { Store (0x0B4B, Local2) } which is obviously that 16C trip point mentioned, overriding the result of the method obtained from the respective device in the usual way, and: If (LEqual (\_SB.C074.C089.C08A, 0x00)) { \_SB.C074.C0E3.C149.C195 (0x00) } elsewhere which sets a location in the embedded controller which seems related to battery control. Overall my guts feeling is it's some debugging or leftover code meant for a different configuration. This is further confirmed by another block defined next to the one quoted above: OperationRegion (C254, SystemIO, 0x21, 0x01) Field (C254, ByteAcc, NoLock, Preserve) { C255, 1 } which quite similarly defines a mask for the 8254 timer interrupt in the master 8259A. This is nowhere used though -- any references may have been removed with the I/O APIC part not adjusted accordingly. Note that the I/O APIC mask defined above is not quite a mask for the 8254 timer interrupt in this system (as it is the ExtINTA 8259A cascade), but it is a common location for one. Anyway, it's clear it's firmware that is at fault here and not hardware. There are actually two bugs -- first is described above and the other one is the IRQ0 override, which is clearly incorrect. The piece of hardware comes from a reputable vendor, so it should be possible to submit a bug report for the firmware. Anybody happens to know the appropriate contact? Meanwhile we may consider implementing a workaround. I think one that does not hurt competent vendors would be preferable. The DSDT containing the rubbish described here is marked with an OEM ID: "HP " and OEM Table ID: "SB400". These keys could be used to remove IRQ0 information from the IRQ tables. Our code is prepared to handle such a case. Something easy to do for a seasoned ACPI fiddler, I suppose. ;) Windows does not trigger this bug, because it stays away from the 8254 on APIC platforms and uses the RTC for the timer instead I am told. Maciej ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-21 1:09 ` Maciej W. Rozycki @ 2008-06-21 1:40 ` Matthew Garrett 2008-06-21 2:41 ` Maciej W. Rozycki 2008-06-26 19:52 ` Rafael J. Wysocki 0 siblings, 2 replies; 90+ messages in thread From: Matthew Garrett @ 2008-06-21 1:40 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Rafael J. Wysocki, Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Sat, Jun 21, 2008 at 02:09:00AM +0100, Maciej W. Rozycki wrote: > Meanwhile we may consider implementing a workaround. I think one that > does not hurt competent vendors would be preferable. The DSDT containing > the rubbish described here is marked with an OEM ID: "HP " and OEM > Table ID: "SB400". These keys could be used to remove IRQ0 information > from the IRQ tables. Our code is prepared to handle such a case. > Something easy to do for a seasoned ACPI fiddler, I suppose. ;) Something roughly like the following? Entirely untested, my 6125 is in a box somewhere. My recollection is that skip_timer_override will disable the IRQ 0->2 mapping, which I believe is what's broken here? diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index 33c5216..6ca5eff 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -1060,6 +1060,16 @@ static int __init force_acpi_ht(const struct dmi_system_id *d) return 0; } +#ifdef CONFIG_X86_IO_APIC +static int __init force_skip_timer_override(const struct dmi_system_id *d) +{ + printk(KERN_NOTICE "%s detected: disabling timer overrides", + d->ident); + acpi_skip_timer_override = 1; + return 0; +} +#endif + /* * If your system is blacklisted here, but you find that acpi=force * works for you, please contact acpi-devel@sourceforge.net @@ -1227,6 +1237,24 @@ static struct dmi_system_id __initdata acpi_dmi_table[] = { DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 360"), }, }, +#ifdef CONFIG_X86_IO_APIC + { + .callback = force_skip_timer_override, + .ident = "HP NX6125 laptop", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"), + DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq nx6125"), + }, + }, + { + .callback = force_skip_timer_override, + .ident = "HP NX6325 laptop", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"), + DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq nx6325"), + }, + }, +#endif {} }; -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply related [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-21 1:40 ` Matthew Garrett @ 2008-06-21 2:41 ` Maciej W. Rozycki 2008-06-21 12:38 ` Matthew Garrett 2008-06-26 19:52 ` Rafael J. Wysocki 1 sibling, 1 reply; 90+ messages in thread From: Maciej W. Rozycki @ 2008-06-21 2:41 UTC (permalink / raw) To: Matthew Garrett Cc: Rafael J. Wysocki, Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Sat, 21 Jun 2008, Matthew Garrett wrote: > > Meanwhile we may consider implementing a workaround. I think one that > > does not hurt competent vendors would be preferable. The DSDT containing > > the rubbish described here is marked with an OEM ID: "HP " and OEM > > Table ID: "SB400". These keys could be used to remove IRQ0 information > > from the IRQ tables. Our code is prepared to handle such a case. > > Something easy to do for a seasoned ACPI fiddler, I suppose. ;) > > Something roughly like the following? Entirely untested, my 6125 is in a Maybe, though your code seems to match product IDs rather than the broken DSDT itself. I think the latter would be preferable as it would cover all the pieces of equipment using the broken piece of firmware rather than ones we have already tracked down. Perhaps the version could be included too, but that would only make sense if the breakage ever gets fixed -- the use of the through-8259A mode for the 8254 timer would allow this piece of equipment to benefit from the I/O APIC driven NMI watchdog. > box somewhere. My recollection is that skip_timer_override will disable > the IRQ 0->2 mapping, which I believe is what's broken here? Not exactly. The IRQ0->2 mapping is certainly wrong here, but so is the identity IRQ0->0 one. Which means it should not be recorded in mp_config_acpi_legacy_irqs() at all. I can cook this part if you'd rather not to, if you do the ACPI part. If you think there is no easy way to match the DSDT rather than the product ID -- we are trying to cope with outright breakage here after all, so any amount of effort is too much ;) -- I can update your proposal with what I have in mind. One point to note -- perhaps it would be better to avoid these #ifdef clauses -- even though it's a workaround, I think the amount of resources consumed does not justify the clutter introduced. Thanks for your submission. Maciej ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-21 2:41 ` Maciej W. Rozycki @ 2008-06-21 12:38 ` Matthew Garrett 0 siblings, 0 replies; 90+ messages in thread From: Matthew Garrett @ 2008-06-21 12:38 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Rafael J. Wysocki, Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Sat, Jun 21, 2008 at 03:41:37AM +0100, Maciej W. Rozycki wrote: > Maybe, though your code seems to match product IDs rather than the broken > DSDT itself. I think the latter would be preferable as it would cover all > the pieces of equipment using the broken piece of firmware rather than > ones we have already tracked down. Perhaps the version could be included > too, but that would only make sense if the breakage ever gets fixed -- the > use of the through-8259A mode for the 8254 timer would allow this piece of > equipment to benefit from the I/O APIC driven NMI watchdog. I haven't seen any other machines with this issue, so I suspect that this is HP-specific code. I'll look into what would need doing to quirk it off the DSDT strings, though. > Not exactly. The IRQ0->2 mapping is certainly wrong here, but so is the > identity IRQ0->0 one. Which means it should not be recorded in > mp_config_acpi_legacy_irqs() at all. I can cook this part if you'd rather > not to, if you do the ACPI part. If you think there is no easy way to > match the DSDT rather than the product ID -- we are trying to cope with > outright breakage here after all, so any amount of effort is too much ;) > -- I can update your proposal with what I have in mind. Ok, that works for me. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-21 1:40 ` Matthew Garrett 2008-06-21 2:41 ` Maciej W. Rozycki @ 2008-06-26 19:52 ` Rafael J. Wysocki 2008-06-27 0:06 ` Maciej W. Rozycki 1 sibling, 1 reply; 90+ messages in thread From: Rafael J. Wysocki @ 2008-06-26 19:52 UTC (permalink / raw) To: Matthew Garrett Cc: Maciej W. Rozycki, Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Saturday, 21 of June 2008, Matthew Garrett wrote: > On Sat, Jun 21, 2008 at 02:09:00AM +0100, Maciej W. Rozycki wrote: > > > Meanwhile we may consider implementing a workaround. I think one that > > does not hurt competent vendors would be preferable. The DSDT containing > > the rubbish described here is marked with an OEM ID: "HP " and OEM > > Table ID: "SB400". These keys could be used to remove IRQ0 information > > from the IRQ tables. Our code is prepared to handle such a case. > > Something easy to do for a seasoned ACPI fiddler, I suppose. ;) > > Something roughly like the following? Entirely untested, my 6125 is in a > box somewhere. My recollection is that skip_timer_override will disable > the IRQ 0->2 mapping, which I believe is what's broken here? Well, actually, I'm not sure that will work. I have only found acpi_skip_timer_override being set to 1 in two places, but it doesn't seem to be read anywhere. What am I missing? > diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c > index 33c5216..6ca5eff 100644 > --- a/arch/x86/kernel/acpi/boot.c > +++ b/arch/x86/kernel/acpi/boot.c > @@ -1060,6 +1060,16 @@ static int __init force_acpi_ht(const struct dmi_system_id *d) > return 0; > } > > +#ifdef CONFIG_X86_IO_APIC > +static int __init force_skip_timer_override(const struct dmi_system_id *d) > +{ > + printk(KERN_NOTICE "%s detected: disabling timer overrides", > + d->ident); > + acpi_skip_timer_override = 1; > + return 0; > +} > +#endif > + > /* > * If your system is blacklisted here, but you find that acpi=force > * works for you, please contact acpi-devel@sourceforge.net > @@ -1227,6 +1237,24 @@ static struct dmi_system_id __initdata acpi_dmi_table[] = { > DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 360"), > }, > }, > +#ifdef CONFIG_X86_IO_APIC > + { > + .callback = force_skip_timer_override, > + .ident = "HP NX6125 laptop", > + .matches = { > + DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"), > + DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq nx6125"), > + }, > + }, > + { > + .callback = force_skip_timer_override, > + .ident = "HP NX6325 laptop", > + .matches = { > + DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"), > + DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq nx6325"), > + }, > + }, > +#endif > {} > }; > ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-26 19:52 ` Rafael J. Wysocki @ 2008-06-27 0:06 ` Maciej W. Rozycki 2008-06-29 14:00 ` Rafael J. Wysocki 0 siblings, 1 reply; 90+ messages in thread From: Maciej W. Rozycki @ 2008-06-27 0:06 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Matthew Garrett, Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Thu, 26 Jun 2008, Rafael J. Wysocki wrote: > Well, actually, I'm not sure that will work. I have only found > acpi_skip_timer_override being set to 1 in two places, but it doesn't seem to > be read anywhere. What am I missing? I believe I removed all the occurences. I am waiting for a proposal of a quirk based on the DSDT ID -- my time is a bit too limited to study the internals of our ACPI code at the moment; sorry about that. I will complement it with a change to remove IRQ0 from I/O APIC tables as promised then; this piece of code I am quite familiar with. Maciej ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-27 0:06 ` Maciej W. Rozycki @ 2008-06-29 14:00 ` Rafael J. Wysocki 2008-06-29 19:05 ` Maciej W. Rozycki 0 siblings, 1 reply; 90+ messages in thread From: Rafael J. Wysocki @ 2008-06-29 14:00 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Matthew Garrett, Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Friday, 27 of June 2008, Maciej W. Rozycki wrote: > On Thu, 26 Jun 2008, Rafael J. Wysocki wrote: > > > Well, actually, I'm not sure that will work. I have only found > > acpi_skip_timer_override being set to 1 in two places, but it doesn't seem to > > be read anywhere. What am I missing? > > I believe I removed all the occurences. I am waiting for a proposal of a > quirk based on the DSDT ID -- my time is a bit too limited to study the > internals of our ACPI code at the moment; sorry about that. I will > complement it with a change to remove IRQ0 from I/O APIC tables as > promised then; this piece of code I am quite familiar with. Well, why don't we use the DMI identification as suggested by Matthew? I think we can safely assume that all of these boxes are broken for now and we can use a more fine grained identification in the future, if necessary. Thanks, Rafael ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-29 14:00 ` Rafael J. Wysocki @ 2008-06-29 19:05 ` Maciej W. Rozycki 2008-06-29 19:23 ` Rafael J. Wysocki 2008-06-29 19:23 ` Matthew Garrett 0 siblings, 2 replies; 90+ messages in thread From: Maciej W. Rozycki @ 2008-06-29 19:05 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Matthew Garrett, Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Sun, 29 Jun 2008, Rafael J. Wysocki wrote: > > I believe I removed all the occurences. I am waiting for a proposal of a > > quirk based on the DSDT ID -- my time is a bit too limited to study the > > internals of our ACPI code at the moment; sorry about that. I will > > complement it with a change to remove IRQ0 from I/O APIC tables as > > promised then; this piece of code I am quite familiar with. > > Well, why don't we use the DMI identification as suggested by Matthew? Because it checks the wrong property. > I think we can safely assume that all of these boxes are broken for now and we > can use a more fine grained identification in the future, if necessary. It is the reverse -- checking the DSDT ID is coarser, matching all the systems that use the broken firmware. With DMI we may face both false positives and false negatives which imply further maintenance actions. Please note as proved over the years understanding of these issues seems to be problematic for people, so the result may be another round of discussions reinventing the wheel in a couple of years' time or so. That's my opinion only though -- if it was to hinder the progress, then I am not going to persist. Have you tried to report the issue through the usual manufacturer's support channels, BTW? They may not even be aware of the existence of the bug. Of course they may dismiss it anyway, but at least they will have a record of it somewhere. Maciej ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-29 19:05 ` Maciej W. Rozycki @ 2008-06-29 19:23 ` Rafael J. Wysocki 2008-06-29 19:56 ` Maciej W. Rozycki 2008-06-29 19:23 ` Matthew Garrett 1 sibling, 1 reply; 90+ messages in thread From: Rafael J. Wysocki @ 2008-06-29 19:23 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Matthew Garrett, Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown, Andi Kleen On Sunday, 29 of June 2008, Maciej W. Rozycki wrote: > On Sun, 29 Jun 2008, Rafael J. Wysocki wrote: > > > > I believe I removed all the occurences. I am waiting for a proposal of a > > > quirk based on the DSDT ID -- my time is a bit too limited to study the > > > internals of our ACPI code at the moment; sorry about that. I will > > > complement it with a change to remove IRQ0 from I/O APIC tables as > > > promised then; this piece of code I am quite familiar with. > > > > Well, why don't we use the DMI identification as suggested by Matthew? > > Because it checks the wrong property. > > > I think we can safely assume that all of these boxes are broken for now and we > > can use a more fine grained identification in the future, if necessary. > > It is the reverse -- checking the DSDT ID is coarser, matching all the > systems that use the broken firmware. How can you tell which DSDTs are broken until somebody reports them? > With DMI we may face both false positives and false negatives which imply > further maintenance actions. With DSDT matching you're likely to end up breaking systems the users of which have not reported problems. > Please note as proved over the years understanding of these issues seems > to be problematic for people, so the result may be another round of > discussions reinventing the wheel in a couple of years' time or so. > > That's my opinion only though -- if it was to hinder the progress, then I > am not going to persist. Good. > Have you tried to report the issue through the usual manufacturer's > support channels, BTW? My experience with HP indicates that it would have been a loss of time. Apart from this, I've always been against forcing people to upgrade their BIOSes just because we just had a briliant idea that made the kernel stop working on their systems. IMO it's extremely user-unfriendly and plain wrong. Thanks, Rafael ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-29 19:23 ` Rafael J. Wysocki @ 2008-06-29 19:56 ` Maciej W. Rozycki 2008-06-29 20:02 ` Ingo Molnar 2008-06-29 22:56 ` Rafael J. Wysocki 0 siblings, 2 replies; 90+ messages in thread From: Maciej W. Rozycki @ 2008-06-29 19:56 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Matthew Garrett, Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown, Andi Kleen On Sun, 29 Jun 2008, Rafael J. Wysocki wrote: > > It is the reverse -- checking the DSDT ID is coarser, matching all the > > systems that use the broken firmware. > > How can you tell which DSDTs are broken until somebody reports them? We know the DSDT matching OEM ID: "HP ", OEM Table ID: "SB400" and OEM Revision: 10000 is broken, because it has already been reported. If these properties are checked, there is no need to for further reports providing us with DMI IDs of systems using the same DSDT. The revision can be used to make sure a good one is not selected inadvertently. > > With DMI we may face both false positives and false negatives which imply > > further maintenance actions. > > With DSDT matching you're likely to end up breaking systems the users of > which have not reported problems. s/breaking/fixing/ Besides, there is nothing to break here -- the mixed interrupt mode will be used when the workaround is selected and the mode has to work or pieces of legacy software, such as DOS, which make use of the 8259A would not work. > > Have you tried to report the issue through the usual manufacturer's > > support channels, BTW? > > My experience with HP indicates that it would have been a loss of time. Well, if you do not report problems, they may never know of their existence and obviously will have no way to fix them. They may ignore your report, but at least you can say you have done your part. Based on the experience the next time you may choose another manufacturer when making a purchase decision. > Apart from this, I've always been against forcing people to upgrade their > BIOSes just because we just had a briliant idea that made the kernel stop > working on their systems. IMO it's extremely user-unfriendly and plain wrong. The BIOS is broken and should be fixed -- it is not our mission to fix up somebody else's faults. As a courtesy to users we may try to work around problems that are hard for them to cope with, but in a sense this is promoting bad quality of hardware: "Don't bother doing this properly -- they will fix it up somehow in the OS anyway." You may argue this is a regression, but this is simply the cost paid for progress -- the kernel stays within the spec as defined both by ACPI and MPS, we have just started using a different configuration now and an interrupt source override provided by the manufacturer explicitly states INTIN2 is good to use. In a sense you were simply lucky previously the kernel was bad enough with the way it configured the timer through the I/O APIC it failed completely avoiding the bug in your firmware. Now the bug has got uncovered. And last but not least, you can always specify "noapic" to get away -- that's a perfectly good workaround. I'll cook up the part I promised shortly and leave it up to the others to "wire" it to some breakage detection logic. Maciej ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-29 19:56 ` Maciej W. Rozycki @ 2008-06-29 20:02 ` Ingo Molnar 2008-06-29 20:14 ` Maciej W. Rozycki 2008-06-29 22:59 ` Rafael J. Wysocki 2008-06-29 22:56 ` Rafael J. Wysocki 1 sibling, 2 replies; 90+ messages in thread From: Ingo Molnar @ 2008-06-29 20:02 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Rafael J. Wysocki, Matthew Garrett, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown, Andi Kleen * Maciej W. Rozycki <macro@linux-mips.org> wrote: > You may argue this is a regression, but this is simply the cost paid > for progress -- the kernel stays within the spec as defined both by > ACPI and MPS, we have just started using a different configuration now > and an interrupt source override provided by the manufacturer > explicitly states INTIN2 is good to use. In a sense you were simply > lucky previously the kernel was bad enough with the way it configured > the timer through the I/O APIC it failed completely avoiding the bug > in your firmware. Now the bug has got uncovered. well as long as we eliminate the bad effects around via DMI exceptions nobody will feel the need to argue whether it's a regression ;-) [this problem could be argued to be a regression, even if it's caused by prior luck/stupidity of Linux. We have to live with the effects of our mistakes.] Ingo ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-29 20:02 ` Ingo Molnar @ 2008-06-29 20:14 ` Maciej W. Rozycki 2008-06-29 23:06 ` Rafael J. Wysocki 2008-06-29 22:59 ` Rafael J. Wysocki 1 sibling, 1 reply; 90+ messages in thread From: Maciej W. Rozycki @ 2008-06-29 20:14 UTC (permalink / raw) To: Ingo Molnar Cc: Rafael J. Wysocki, Matthew Garrett, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown, Andi Kleen On Sun, 29 Jun 2008, Ingo Molnar wrote: > > You may argue this is a regression, but this is simply the cost paid > > for progress -- the kernel stays within the spec as defined both by > > ACPI and MPS, we have just started using a different configuration now > > and an interrupt source override provided by the manufacturer > > explicitly states INTIN2 is good to use. In a sense you were simply > > lucky previously the kernel was bad enough with the way it configured > > the timer through the I/O APIC it failed completely avoiding the bug > > in your firmware. Now the bug has got uncovered. > > well as long as we eliminate the bad effects around via DMI exceptions > nobody will feel the need to argue whether it's a regression ;-) [this > problem could be argued to be a regression, even if it's caused by prior > luck/stupidity of Linux. We have to live with the effects of our > mistakes.] Of course -- this is the only reason I can be bothered with the issue in the first place. Otherwise, I would have said: 'Get the manufacturer to fix it, use "noapic" or live with a local patch.' This is actually how I have kept one of my old MPS SMP systems up for years now -- it has a broken MP table which prevents interrupts from working when too many PCI option cards are present, so I have prepared a patch for patching the table manually. I proposed it once, which you may recall, but it was rejected on the grounds of the syntax being too tough to comprehend to a poor average user being. I am sure more systems would benefit as MP table breakages used to be quite common. Here the simple workaround was "noapic" too, so everyone else could be happy and I have been happy to keep the patch and use the capabilities of the piece of hardware properly despite its broken firmware. Maciej ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-29 20:14 ` Maciej W. Rozycki @ 2008-06-29 23:06 ` Rafael J. Wysocki 2008-06-30 0:45 ` Andi Kleen 2008-06-30 1:39 ` Maciej W. Rozycki 0 siblings, 2 replies; 90+ messages in thread From: Rafael J. Wysocki @ 2008-06-29 23:06 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Ingo Molnar, Matthew Garrett, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown, Andi Kleen, Andrew Morton, Linus Torvalds On Sunday, 29 of June 2008, Maciej W. Rozycki wrote: > On Sun, 29 Jun 2008, Ingo Molnar wrote: > > > > You may argue this is a regression, but this is simply the cost paid > > > for progress -- the kernel stays within the spec as defined both by > > > ACPI and MPS, we have just started using a different configuration now > > > and an interrupt source override provided by the manufacturer > > > explicitly states INTIN2 is good to use. In a sense you were simply > > > lucky previously the kernel was bad enough with the way it configured > > > the timer through the I/O APIC it failed completely avoiding the bug > > > in your firmware. Now the bug has got uncovered. > > > > well as long as we eliminate the bad effects around via DMI exceptions > > nobody will feel the need to argue whether it's a regression ;-) [this > > problem could be argued to be a regression, even if it's caused by prior > > luck/stupidity of Linux. We have to live with the effects of our > > mistakes.] > > Of course -- this is the only reason I can be bothered with the issue in > the first place. Otherwise, I would have said: 'Get the manufacturer to > fix it, use "noapic" or live with a local patch.' In that case your patch would surely make it to the regression list. > This is actually how I have kept one of my old MPS SMP systems up for > years now -- it has a broken MP table which prevents interrupts from > working when too many PCI option cards are present, so I have prepared a > patch for patching the table manually. I proposed it once, which you may > recall, but it was rejected on the grounds of the syntax being too tough > to comprehend to a poor average user being. I am sure more systems would > benefit as MP table breakages used to be quite common. > > Here the simple workaround was "noapic" too, so everyone else could be > happy and I have been happy to keep the patch and use the capabilities of > the piece of hardware properly despite its broken firmware. Again. If there's a configuration that didn't need any manual workarounds before, it's expected to continue to work without any manual workarounds and as a patch submitter, it's _your_ burden to make that happen. Otherwise you throw this burden onto users who (1) don't expect things to stop working, (2) may not be able to figure out themselves what the right workaround is, (3) may not be able to make hardware manufacturers do anything. If there's a configuration that worked before your patch and doesn't work after it, you're hurting the users of that configuration. Thanks, Rafael ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-29 23:06 ` Rafael J. Wysocki @ 2008-06-30 0:45 ` Andi Kleen 2008-06-30 0:47 ` Matthew Garrett 2008-06-30 1:39 ` Maciej W. Rozycki 1 sibling, 1 reply; 90+ messages in thread From: Andi Kleen @ 2008-06-30 0:45 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Maciej W. Rozycki, Ingo Molnar, Matthew Garrett, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown, Andi Kleen, Andrew Morton, Linus Torvalds > > Otherwise you throw this burden onto users who > (1) don't expect things to stop working, > (2) may not be able to figure out themselves what the right workaround is, > (3) may not be able to make hardware manufacturers do anything. Right thing would be to revert the guilty patches until these problems are resolved. > > If there's a configuration that worked before your patch and doesn't work > after it, you're hurting the users of that configuration. ... also past experience is that DMI tables don't work well for this. We tried that early when ACPI was still very problematic and it turned out to be a flawed non-scalable strategy, Typically the configurations causing problems are in multiple motherboards with different DMI strings and it's very difficult to catch them all. Also sometimes BIOS behaviour changes over versions and that's tricky to catch with the standard DMI matches. One way that would half way scale is to check for specific configurations based on PCI-IDs and knowledge of the config space of these chipset, although it's also not ideal because often multiple chipset generations with different PCI-IDs have similar issues. -Andi ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-30 0:45 ` Andi Kleen @ 2008-06-30 0:47 ` Matthew Garrett 0 siblings, 0 replies; 90+ messages in thread From: Matthew Garrett @ 2008-06-30 0:47 UTC (permalink / raw) To: Andi Kleen Cc: Rafael J. Wysocki, Maciej W. Rozycki, Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown, Andi Kleen, Andrew Morton, Linus Torvalds On Mon, Jun 30, 2008 at 02:45:44AM +0200, Andi Kleen wrote: > ... also past experience is that DMI tables don't work well for this. > We tried that early when ACPI was still very problematic and it turned > out to be a flawed non-scalable strategy, > > Typically the configurations causing problems are in multiple motherboards > with different DMI strings and it's very difficult to catch them all. > > Also sometimes BIOS behaviour changes over versions and that's tricky to catch > with the standard DMI matches. In this specific case, the problem is clearly due to nonsensical code in the DSDT that alters the thermal trip points based on ioapic configuration. It's only been observed on two almost identical models from one manufacturer, and doesn't occur on any other known machines with the same chipset. I think it's safe to special-case. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-29 23:06 ` Rafael J. Wysocki 2008-06-30 0:45 ` Andi Kleen @ 2008-06-30 1:39 ` Maciej W. Rozycki 2008-06-30 9:24 ` Andi Kleen 2008-06-30 10:41 ` Rafael J. Wysocki 1 sibling, 2 replies; 90+ messages in thread From: Maciej W. Rozycki @ 2008-06-30 1:39 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Ingo Molnar, Matthew Garrett, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown, Andi Kleen, Andrew Morton, Linus Torvalds On Mon, 30 Jun 2008, Rafael J. Wysocki wrote: > > > well as long as we eliminate the bad effects around via DMI exceptions > > > nobody will feel the need to argue whether it's a regression ;-) [this > > > problem could be argued to be a regression, even if it's caused by prior > > > luck/stupidity of Linux. We have to live with the effects of our > > > mistakes.] > > > > Of course -- this is the only reason I can be bothered with the issue in > > the first place. Otherwise, I would have said: 'Get the manufacturer to > > fix it, use "noapic" or live with a local patch.' > > In that case your patch would surely make it to the regression list. Please be careful -- you seem to contradict yourself. I wrote to the effect of: "If this wasn't a regression, I would have said [...]" and your reply is: "In that case your [non-regressing] patch would surely make it to the regression list." > > This is actually how I have kept one of my old MPS SMP systems up for > > years now -- it has a broken MP table which prevents interrupts from > > working when too many PCI option cards are present, so I have prepared a > > patch for patching the table manually. I proposed it once, which you may > > recall, but it was rejected on the grounds of the syntax being too tough > > to comprehend to a poor average user being. I am sure more systems would > > benefit as MP table breakages used to be quite common. > > > > Here the simple workaround was "noapic" too, so everyone else could be > > happy and I have been happy to keep the patch and use the capabilities of > > the piece of hardware properly despite its broken firmware. > > Again. If there's a configuration that didn't need any manual workarounds > before, it's expected to continue to work without any manual workarounds and > as a patch submitter, it's _your_ burden to make that happen. That is certainly true for standard hardware. We have to take responsibility for own bugs, sure. I cannot readily understand why you apparently try to imply hardware vendors do not. > Otherwise you throw this burden onto users who > (1) don't expect things to stop working, > (2) may not be able to figure out themselves what the right workaround is, > (3) may not be able to make hardware manufacturers do anything. > > If there's a configuration that worked before your patch and doesn't work > after it, you're hurting the users of that configuration. Honestly? These poor users who have no clue or time to follow the development lists and/or fix bugs themselves should report the problem to the supplier of their Linux distribution, who would sort it out by, first, providing a temporary workaround till the problem is sorted out correctly, second, contacting the hardware vendor through a recognised channel to request the problem to be investigated and fixed properly. I am fairly sure all the reputable (responsible?) distribution vendors have service agreements already in place with all the major hardware vendors and all the minor hardware vendors will be happy to cooperate anyway so as not to be minor vendors anymore. This is why I have asked for points of contact repeatedly in this thread. Of course it leaves hobbyist distributions at a slight disadvantage, but their users are sort of expected to be "power users" (otherwise they wouldn't have been hobbyists, would they?) and adding an option or a patch even should not be a problem for them. We may try to do our best to help them, but not at the price of penalising good hardware. Maciej ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-30 1:39 ` Maciej W. Rozycki @ 2008-06-30 9:24 ` Andi Kleen 2008-07-02 1:19 ` Maciej W. Rozycki 2008-06-30 10:41 ` Rafael J. Wysocki 1 sibling, 1 reply; 90+ messages in thread From: Andi Kleen @ 2008-06-30 9:24 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Rafael J. Wysocki, Ingo Molnar, Matthew Garrett, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown, Andi Kleen, Andrew Morton, Linus Torvalds > That is certainly true for standard hardware. We have to take > responsibility for own bugs, sure. I cannot readily understand why you > apparently try to imply hardware vendors do not. Sorry Maciej, you're totally off base on that. On consumer hardware vendors very rarely fix anything after release of the machine and in general users expect Linux to work around any BIOS or hardware bugs that happen (especially if it's a regression and worked before) So you either need to provide a workaround for the problem or your patches should be reverted. -Andi ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-30 9:24 ` Andi Kleen @ 2008-07-02 1:19 ` Maciej W. Rozycki 0 siblings, 0 replies; 90+ messages in thread From: Maciej W. Rozycki @ 2008-07-02 1:19 UTC (permalink / raw) To: Andi Kleen Cc: Rafael J. Wysocki, Ingo Molnar, Matthew Garrett, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown, Andi Kleen, Andrew Morton, Linus Torvalds On Mon, 30 Jun 2008, Andi Kleen wrote: > > That is certainly true for standard hardware. We have to take > > responsibility for own bugs, sure. I cannot readily understand why you > > apparently try to imply hardware vendors do not. > > Sorry Maciej, you're totally off base on that. On consumer hardware Am I? Just a little bit maybe. Or actually I am more like playing a devil's advocate here. ;) > vendors very rarely fix anything after release of the machine > and in general users expect Linux to work around any BIOS or > hardware bugs that happen (especially if it's a regression and worked > before) Well, that's no news to me, but my point is are you happy with such a state of affairs? I am not. It is well known (at least to me) that quality of x86 firmware is questionable and has been such for many years now. I recall bad experiences from as long ago as 15 years. That was before I discovered Linux and even without knowing the quality of free software I considered many implementations of PC BIOSes a bad joke. Of course it may sometimes be difficult to notice all the problematic bugs early enough. Testing is expensive and takes a lot of time. Proving functional correctness of a non-trivial piece of software against a complex specification is infeasible. Back then firmware used to be included in a piece of EPROM memory, so for practical purposes it was cast in stone -- nobody would order new chips with an updated replacement for their PC, which was a practice quite common among workstation/server manufacturers though. These days the firmware is included in an easily reprogrammable piece of Flash memory, which means technically an update can be done by any user. Yet apparently PC equipment manufacturers taught users (similarly to what some companies did about operating system software) that bad quality is an immanent property of firmware. This way they can cut the cost of testing down, effectively shifting it to someone else. They take no responsibility for their mistakes and make the others pay for them. That's quite a convenient situation, isn't it? -- I wish I could apply it to myself as well. I do not blame the users. For most of the users the internals of computer equipment are beyond comprehension and this is perfectly fine as nobody is meant to be skilled in everything. Likewise I do not want to know in details how a bridge is to be constructed -- I only want to use it to cross the river. I just need to trust someone the bridge is safe to use. Similarly the user of a computer trusts someone to decide whether a given piece of equipment is good or not. In this case I think it is our role to make users aware firmware bugs are not our responsibility, and our willingness to cope with them is more a courtesy than a duty. In a perfect world they would go back to the manufacturer, or better yet, to the point of sale and demand the piece of equipment to be replaced with a good one, fixed, discounted or refunded. Just with all the other goods -- if I buy a shirt and discover it has three sleeves despite being advertised for regular human beings, I will not demand from a coat manufacturer to get it fitted with three sleeves to match. Instead I will go to the shop I got the shirt from and demand to get the situation rectified. Of course I could go to a coat manufacturer instead and ask them nicely to add an extra sleeve and they might do it, but that's by no means their duty. As we are not in a perfect world, users are not likely to do so as they can be easily god ridden of, by ignoring them or giving arguments they feel not competent enough to dispute. And if all manufacturers behaved consistently, users would have no alternative for their next purchase. The cost remains though. For example people involved with this case could have spent the time on something creative, like adding new functionality. I do not consider it fair when someone shifts their costs onto me and while I may accept it for a given case for some reasons, I am not going to treat the situation as normal and will seek a proper solution. Here I think there is some potential interest to a few well-defined parties to get better support from hardware manufacturers when it comes to the firmware. These parties may be vendors of Linux distributions who certainly bear costs of dealing with firmware bugs. These parties may be x86 CPU vendors as well as the overall quality of equipment matters for their reputation. And it is not that they can relax unconcerned in the belief the x86 is there forever -- times are changing and there alternatives on the horizon (the Jisus laptop may be just one swallow, but even if it fails, there will be followers), which are unlikely to be beaten by price, but may be beaten by quality. While users will not care how baroque the solution is, they certainly will not disregard how it works. Sorry for such a long dissertation, but I think the current situation is too far from perfect not to do anything about it. I do not seem to be a position to change it, but at least I may try to increase the awareness of the problem. And refer users who complain to the respective manufacturers. What I am sure of is if we just keep papering firmware bugs over and never come back with them to the (ir)responsible manufacturer, then the situation will never change. Maciej ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-30 1:39 ` Maciej W. Rozycki 2008-06-30 9:24 ` Andi Kleen @ 2008-06-30 10:41 ` Rafael J. Wysocki 2008-07-02 1:48 ` Maciej W. Rozycki 1 sibling, 1 reply; 90+ messages in thread From: Rafael J. Wysocki @ 2008-06-30 10:41 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Ingo Molnar, Matthew Garrett, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown, Andi Kleen, Andrew Morton, Linus Torvalds On Monday, 30 of June 2008, Maciej W. Rozycki wrote: > On Mon, 30 Jun 2008, Rafael J. Wysocki wrote: > > > > > well as long as we eliminate the bad effects around via DMI exceptions > > > > nobody will feel the need to argue whether it's a regression ;-) [this > > > > problem could be argued to be a regression, even if it's caused by prior > > > > luck/stupidity of Linux. We have to live with the effects of our > > > > mistakes.] > > > > > > Of course -- this is the only reason I can be bothered with the issue in > > > the first place. Otherwise, I would have said: 'Get the manufacturer to > > > fix it, use "noapic" or live with a local patch.' > > > > In that case your patch would surely make it to the regression list. > > Please be careful -- you seem to contradict yourself. I wrote to the > effect of: "If this wasn't a regression, I would have said [...]" and your > reply is: "In that case your [non-regressing] patch would surely make it > to the regression list." Sorry, I didn't parse that paragraph correctly > > > This is actually how I have kept one of my old MPS SMP systems up for > > > years now -- it has a broken MP table which prevents interrupts from > > > working when too many PCI option cards are present, so I have prepared a > > > patch for patching the table manually. I proposed it once, which you may > > > recall, but it was rejected on the grounds of the syntax being too tough > > > to comprehend to a poor average user being. I am sure more systems would > > > benefit as MP table breakages used to be quite common. > > > > > > Here the simple workaround was "noapic" too, so everyone else could be > > > happy and I have been happy to keep the patch and use the capabilities of > > > the piece of hardware properly despite its broken firmware. > > > > Again. If there's a configuration that didn't need any manual workarounds > > before, it's expected to continue to work without any manual workarounds and > > as a patch submitter, it's _your_ burden to make that happen. > > That is certainly true for standard hardware. We have to take > responsibility for own bugs, sure. I cannot readily understand why you > apparently try to imply hardware vendors do not. > > > Otherwise you throw this burden onto users who > > (1) don't expect things to stop working, > > (2) may not be able to figure out themselves what the right workaround is, > > (3) may not be able to make hardware manufacturers do anything. > > > > If there's a configuration that worked before your patch and doesn't work > > after it, you're hurting the users of that configuration. > > Honestly? These poor users who have no clue or time to follow the > development lists and/or fix bugs themselves should report the problem to > the supplier of their Linux distribution, who would sort it out by, first, > providing a temporary workaround till the problem is sorted out correctly, > second, contacting the hardware vendor through a recognised channel to > request the problem to be investigated and fixed properly. I am fairly > sure all the reputable (responsible?) distribution vendors have service > agreements already in place with all the major hardware vendors and all > the minor hardware vendors will be happy to cooperate anyway so as not to > be minor vendors anymore. This is why I have asked for points of contact > repeatedly in this thread. > > Of course it leaves hobbyist distributions at a slight disadvantage, but > their users are sort of expected to be "power users" (otherwise they > wouldn't have been hobbyists, would they?) and adding an option or a patch > even should not be a problem for them. We may try to do our best to help > them, but not at the price of penalising good hardware. Well, there are lots of pieces of hardware that are not up to the specifications, more or less, and I don't think that's a good enough reason for us to refuse to support them. The same applies to BIOSes IMO. Of course, the _default_ should be to follow the spec, but if that doesn't work on given hardware/BIOS combination and we know what to do to handle it, we should just handle it instead of asking users to fix their BIOSes. I have seen enough failed BIOS upgrades to be very cautious about such things. Certainly, I wouldn't have seriously asked anyone to upgrade the BIOS in a notebook, because if that had failed, the user would have end up with a piece of electronic junk. Thanks, Rafael ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-30 10:41 ` Rafael J. Wysocki @ 2008-07-02 1:48 ` Maciej W. Rozycki 2008-07-02 9:35 ` Andi Kleen 0 siblings, 1 reply; 90+ messages in thread From: Maciej W. Rozycki @ 2008-07-02 1:48 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Ingo Molnar, Matthew Garrett, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown, Andi Kleen, Andrew Morton, Linus Torvalds On Mon, 30 Jun 2008, Rafael J. Wysocki wrote: > Well, there are lots of pieces of hardware that are not up to the > specifications, more or less, and I don't think that's a good enough reason > for us to refuse to support them. The same applies to BIOSes IMO. Refusing to support broken hardware would provide some incentive to manufacturers to improve it, because people would rather not buy unsupported pieces of junk. I realise that may be impractical though -- we would get the blame anyway, because "it runs the other OS just fine." I think we may legitimately request something in return for our effort though, for example at least minimal support from hardware manufacturers. It is not that we would waste a lot of their time, because in general anything we do not filter out must be really tough. > Of course, the _default_ should be to follow the spec, but if that doesn't work > on given hardware/BIOS combination and we know what to do to handle it, we > should just handle it instead of asking users to fix their BIOSes. I think we should insist on getting issues reported back to the manufacturer. We may implement workarounds independently and leave it up to the users whether they want to do a BIOS upgrade or not. > I have seen enough failed BIOS upgrades to be very cautious about such things. > Certainly, I wouldn't have seriously asked anyone to upgrade the BIOS in a > notebook, because if that had failed, the user would have end up with a piece > of electronic junk. That's a valid point, although making the point of quality yet clearer -- being critical enough, I would expect it to have been thorougly tested by the manufacturer. Also solutions like protected Flash areas have been available for many years now, which means a machine should be operative enough for recovery to be doable if an upgrade fails. So perhaps the very first thing to do after a new purchase should be doing a BIOS update, so that you can claim your warranty if something goes wrong. Technically upgrading a laptop should be safer as bearing an on-board UPS they are protected from power failures, which may be problematic for some users of other equipment. Maciej ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-07-02 1:48 ` Maciej W. Rozycki @ 2008-07-02 9:35 ` Andi Kleen 0 siblings, 0 replies; 90+ messages in thread From: Andi Kleen @ 2008-07-02 9:35 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Rafael J. Wysocki, Ingo Molnar, Matthew Garrett, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown, Andi Kleen, Andrew Morton, Linus Torvalds Maciej W. Rozycki wrote: > On Mon, 30 Jun 2008, Rafael J. Wysocki wrote: > >> Well, there are lots of pieces of hardware that are not up to the >> specifications, more or less, and I don't think that's a good enough reason >> for us to refuse to support them. The same applies to BIOSes IMO. > > Refusing to support broken hardware would provide some incentive to > manufacturers to improve it, because people would rather not buy > unsupported pieces of junk. For most consumer level hardware the vendors generally don't really care if Linux runs on it or not. Also they very rarely fix anything after release anyways because they don't make enough money on it. For server hardware that is different (vendors care about Linux, but typically not about mainline, but about given RHEL/SLES releases), but even there we generally try to work around BIOS bugs (at least as long as it is possible) because it tends to be quite difficult logistically to require a BIOS update. In the end it just hurts the user. > I realise that may be impractical though It is. > we would get the blame anyway, because "it runs the other OS just fine." That is exactly what happens. -Andi ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-29 20:02 ` Ingo Molnar 2008-06-29 20:14 ` Maciej W. Rozycki @ 2008-06-29 22:59 ` Rafael J. Wysocki 1 sibling, 0 replies; 90+ messages in thread From: Rafael J. Wysocki @ 2008-06-29 22:59 UTC (permalink / raw) To: Ingo Molnar Cc: Maciej W. Rozycki, Matthew Garrett, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown, Andi Kleen, Andrew Morton, Linus Torvalds On Sunday, 29 of June 2008, Ingo Molnar wrote: > > * Maciej W. Rozycki <macro@linux-mips.org> wrote: > > > You may argue this is a regression, but this is simply the cost paid > > for progress -- the kernel stays within the spec as defined both by > > ACPI and MPS, we have just started using a different configuration now > > and an interrupt source override provided by the manufacturer > > explicitly states INTIN2 is good to use. In a sense you were simply > > lucky previously the kernel was bad enough with the way it configured > > the timer through the I/O APIC it failed completely avoiding the bug > > in your firmware. Now the bug has got uncovered. > > well as long as we eliminate the bad effects around via DMI exceptions > nobody will feel the need to argue whether it's a regression ;-) If all boxes affected by this particulare breakage are covered by DMI-based workarounds, they will continue to work and that won't be any regression. The point is that the patch should go along with such workarounds. > [this problem could be argued to be a regression, even if it's caused by > prior luck/stupidity of Linux. We have to live with the effects of our > mistakes.] That's exactly right. Thanks, Rafael ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-29 19:56 ` Maciej W. Rozycki 2008-06-29 20:02 ` Ingo Molnar @ 2008-06-29 22:56 ` Rafael J. Wysocki 2008-06-30 1:00 ` Maciej W. Rozycki 1 sibling, 1 reply; 90+ messages in thread From: Rafael J. Wysocki @ 2008-06-29 22:56 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Matthew Garrett, Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown, Andi Kleen, Andrew Morton, Linus Torvalds On Sunday, 29 of June 2008, Maciej W. Rozycki wrote: > On Sun, 29 Jun 2008, Rafael J. Wysocki wrote: > > > > It is the reverse -- checking the DSDT ID is coarser, matching all the > > > systems that use the broken firmware. > > > > How can you tell which DSDTs are broken until somebody reports them? > > We know the DSDT matching OEM ID: "HP ", OEM Table ID: "SB400" and OEM > Revision: 10000 is broken, because it has already been reported. If these > properties are checked, there is no need to for further reports providing > us with DMI IDs of systems using the same DSDT. The revision can be used > to make sure a good one is not selected inadvertently. > > > > With DMI we may face both false positives and false negatives which imply > > > further maintenance actions. > > > > With DSDT matching you're likely to end up breaking systems the users of > > which have not reported problems. > > s/breaking/fixing/ No. If your patch is applied in its present form, all of the boxes from HP nx6x25 series won't work any more, although they worked before. If you use DSDT matching and all of the DSDTs of these boxes are similarly broken, which is quite possible, some of them will not be matched and will be broken. If you use DMI matching, there's a chance we'll cover all of them. > Besides, there is nothing to break here -- the mixed interrupt mode will > be used when the workaround is selected and the mode has to work or pieces > of legacy software, such as DOS, which make use of the 8259A would not > work. I'm not sure what you mean here. > > > Have you tried to report the issue through the usual manufacturer's > > > support channels, BTW? > > > > My experience with HP indicates that it would have been a loss of time. > > Well, if you do not report problems, they may never know of their > existence and obviously will have no way to fix them. They may ignore > your report, but at least you can say you have done your part. Based on > the experience the next time you may choose another manufacturer when > making a purchase decision. Surely I will, but as long as I have the HP box here, I need to live with it. Also, there are other people who happen to use the affected boxes and do not expect them to stop working with future kernel releases. > > Apart from this, I've always been against forcing people to upgrade their > > BIOSes just because we just had a briliant idea that made the kernel stop > > working on their systems. IMO it's extremely user-unfriendly and plain wrong. > > The BIOS is broken and should be fixed -- it is not our mission to fix up > somebody else's faults. As a courtesy to users we may try to work around > problems that are hard for them to cope with, but in a sense this is > promoting bad quality of hardware: "Don't bother doing this properly -- > they will fix it up somehow in the OS anyway." > > You may argue this is a regression, This IS a regression. The patch breaks a perfectly working configuration and something like this _always_ is a regression. The root cause of this regression may be a BIOS breakage, but you have to take this into account, this way or another. We can't really afford breaking working configurations. > but this is simply the cost paid for progress -- Sorry, with this philosophy I could reject 90% of suspend-related bug reports. > the kernel stays within the spec as defined both by ACPI and > MPS, we have just started using a different configuration now and an > interrupt source override provided by the manufacturer explicitly states > INTIN2 is good to use. In a sense you were simply lucky previously the > kernel was bad enough with the way it configured the timer through the I/O > APIC it failed completely avoiding the bug in your firmware. Now the bug > has got uncovered. No, you are wrong. The kernel previously _worked_ on the affected boxes and now it _doesn't_. The reason why it worked before doesn't matter one whit. If we did something that made it work despite the BIOS brokenness, we have to continue doing it on these particular boxes. > And last but not least, you can always specify "noapic" to get away -- > that's a perfectly good workaround. Which was unnecessary before your patch. > I'll cook up the part I promised shortly and leave it up to the others to > "wire" it to some breakage detection logic. Please do, perhaps I'll be able to fix it up. Still, you should pay more attention to what your patches may break, IMO, although those systems may contain broken BIOSes or something. If they worked before, they are expected to continue to work and everything that violates this expectation is a regression. Sorry, but that's how it goes. Thanks, Rafael ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-29 22:56 ` Rafael J. Wysocki @ 2008-06-30 1:00 ` Maciej W. Rozycki 2008-06-30 9:06 ` Matthew Garrett 0 siblings, 1 reply; 90+ messages in thread From: Maciej W. Rozycki @ 2008-06-30 1:00 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Matthew Garrett, Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown, Andi Kleen, Andrew Morton, Linus Torvalds On Mon, 30 Jun 2008, Rafael J. Wysocki wrote: > > > With DSDT matching you're likely to end up breaking systems the users of > > > which have not reported problems. > > > > s/breaking/fixing/ > > No. > > If your patch is applied in its present form, all of the boxes from HP > nx6x25 series won't work any more, although they worked before. I have not proposed a patch to do DSDT matching, so you mean Matthew's patch, right? Well, there are two possibilities -- either a true or a false positive. For a true positive, the patch will work around the DSDT problem by disabling the I/O APIC route for the timer interrupt. For a false positive, the effect will be the same, although unnecessary. I am not sure what you think will not work anymore. > If you use DSDT matching and all of the DSDTs of these boxes are similarly > broken, which is quite possible, some of them will not be matched and will be > broken. If you use DMI matching, there's a chance we'll cover all of them. The DSDT is clearly associated with the SB400 southbridge. I would not expect a given make and model to use different southbridges across the series, so there will only be one DSDT per model, possibly in a number of revisions. On the other hand different models may use the same southbridge and hence the same DSDT. Note that Matthew's made a point here, that apparently there are only two models using this southbridge and new ones are unlikely to be released, so my note is for a reference only. > > Besides, there is nothing to break here -- the mixed interrupt mode will > > be used when the workaround is selected and the mode has to work or pieces > > of legacy software, such as DOS, which make use of the 8259A would not > > work. > > I'm not sure what you mean here. The workaround makes the system use the mixed interrupt mode (well, to be honest, it is a simplification, because LINT0 is tried as a native interrupt before falling back to ExtINTA), which means some interrupts go through the I/O APIC and some go through the 8259A. The route through the 8259A has to work, because otherwise legacy software would fail. Without the workaround the APIC mode would be used, where all interrupts go through the I/O APIC (but it fails on your system). The third alternative is the virtual-wire mode, the default at the bootstrap (or IOW the point control is passed to Linux from the firmware) and then forced to stay with the "noapic" option, where all interrupts go through the 8259A. > > Well, if you do not report problems, they may never know of their > > existence and obviously will have no way to fix them. They may ignore > > your report, but at least you can say you have done your part. Based on > > the experience the next time you may choose another manufacturer when > > making a purchase decision. > > Surely I will, but as long as I have the HP box here, I need to live with it. > Also, there are other people who happen to use the affected boxes and do not > expect them to stop working with future kernel releases. There's always the "noapic" option. It was added for the very purpose of dealing with various kinds of breakages manufacturers have been happy to put into I/O APIC interrupts for years and is meant to work. Please report if there is a problem with the option with your system. > > The BIOS is broken and should be fixed -- it is not our mission to fix up > > somebody else's faults. As a courtesy to users we may try to work around > > problems that are hard for them to cope with, but in a sense this is > > promoting bad quality of hardware: "Don't bother doing this properly -- > > they will fix it up somehow in the OS anyway." > > > > You may argue this is a regression, > > This IS a regression. > > The patch breaks a perfectly working configuration and something like this > _always_ is a regression. The root cause of this regression may be a BIOS > breakage, but you have to take this into account, this way or another. > > We can't really afford breaking working configurations. Noted, with the exception yours is not a "perfectly working configuration" -- notice how the timer interrupt is set up twice and fails before the third fallback recovers. If not our persistence to keep it going despite breakage of hardware we would have panic()ked at the very first failure. Now the attempts have been improved so that the second one already succeeds, but it does not make your piece of hardware less broken. > > but this is simply the cost paid for progress -- > > Sorry, with this philosophy I could reject 90% of suspend-related bug reports. Are these genuine bugs in code you take responsibility for or bugs in some other code? > > the kernel stays within the spec as defined both by ACPI and > > MPS, we have just started using a different configuration now and an > > interrupt source override provided by the manufacturer explicitly states > > INTIN2 is good to use. In a sense you were simply lucky previously the > > kernel was bad enough with the way it configured the timer through the I/O > > APIC it failed completely avoiding the bug in your firmware. Now the bug > > has got uncovered. > > No, you are wrong. The kernel previously _worked_ on the affected boxes and > now it _doesn't_. The reason why it worked before doesn't matter one whit. > > If we did something that made it work despite the BIOS brokenness, we have to > continue doing it on these particular boxes. This is what the specs are for to resolve. We keep to the spec on one side and the hardware/firmware has to on the other -- this is a contract set between components. Not some particular version of a piece of software or equipment. If we stopped using parts of some spec, because there are broken pieces of equipment out there, then we would soon reach the point we could not use the spec at all. To give you an example: let's assume we have a class of hardware which comes in two generations, G1 and G2. Both generations were designed to a separate open spec each and the newer one may optionally implement a crippled legacy mode where the older revision of the spec is used; initially all G2 hardware implements this mode. Let's assume we have version V1 of Linux which supports the legacy mode only, which works correctly with all known G1 and G2 hardware at the time of its release. Now in version V2 (V2 = V1 + 1) native Linux support for G2 hardware has been added. Unfortunately one of the manufacturers of G2 hardware misinterpreted the spec for its H2 and an essential status bit B2 is negated compared to the spec and to all the other pieces of G2 hardware. As a result, code updated to work with G2 natively does not work on this H2 piece of equipment. This is clearly a regression, because this H2 piece of equipment used to work flawlessly before. What should we do then? I think we have four notable choices: 1. Ignore all the mix-up and blame the manufacturer. The hardware is faulty and it is up to users to return it to the supplier for money back. 2. Scrap all the G2 support because it introduces a regression. We were not fast enough to implement it before someone broke the spec and we are doomed. Sorry. 3. Add an option that would flip the meaning of B2 or force the legacy mode. This way there is no negative impact on good G2 hardware 4. Discover and special-case H2, proceeding with the option #3 as above automatically. Likewise, no negative impact. In an ideal world (but not as ideal for hardware bugs not to happen) the #1 would be the natural option -- the offender would pay the price of their mistake. Unfortunately we do not live in an ideal world and expect the offender to ignore the blame. Therefore we are left with the remaining options. You seem to insist on the #2 and I argue for either the #3 or the #4. All of the three deal with the problem somehow. Unfortunately I fail to see any advantage from the #2, but I look forward to justification I may have missed. OTOH, the disadvantage from the #3 is negligible -- an additional option put somewhere -- and there is no disadvantage from the #4 that I would recognise. Therefore I fail to see why the #2 would have to be chosen. > > And last but not least, you can always specify "noapic" to get away -- > > that's a perfectly good workaround. > > Which was unnecessary before your patch. It would not be necessary with your piece of hardware running Linux 2.2 too. My old SMP board (mentioned in another mail in this thread) stopped working without "noapic" at one point because of its MP table breakage too and yet "noapic" has not become the default since then. > > I'll cook up the part I promised shortly and leave it up to the others to > > "wire" it to some breakage detection logic. > > Please do, perhaps I'll be able to fix it up. Nothing to do from your side except from further testing perhaps as I think we have agreed upon Matthew's proposal. I'll try to get it wrapped up today, though not necessarily before the noon. ;) > Still, you should pay more attention to what your patches may break, IMO, > although those systems may contain broken BIOSes or something. If they worked > before, they are expected to continue to work and everything that violates this > expectation is a regression. Sorry, but that's how it goes. It is not the lack of attention -- please do me a favour and try not to give me unjustified pieces of advice. Thank you. I have explicitly warned the patch may break things and was pretty much confident it would -- see my comment accompanying the original submission at "http://lkml.org/lkml/2008/5/27/306". I was pretty much confident it would fix more systems than it would break too. We are dealing with substandard hardware/firmware here and these painful efforts should not be necessary at all in the first place. Your system is an example of a particularly degenerate breakage, where the mode of failue triggered is not immediately disastrous, and you are lucky a culprit has been found at all. In all cases thanks a lot for your testing -- you have just uncovered one example of the inevitable and I am trying to tackle it the best way possible. Maciej ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-30 1:00 ` Maciej W. Rozycki @ 2008-06-30 9:06 ` Matthew Garrett 2008-06-30 15:29 ` Maciej W. Rozycki 0 siblings, 1 reply; 90+ messages in thread From: Matthew Garrett @ 2008-06-30 9:06 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Rafael J. Wysocki, Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown, Andi Kleen, Andrew Morton, Linus Torvalds On Mon, Jun 30, 2008 at 02:00:04AM +0100, Maciej W. Rozycki wrote: > The DSDT is clearly associated with the SB400 southbridge. I would not > expect a given make and model to use different southbridges across the > series, so there will only be one DSDT per model, possibly in a number of > revisions. On the other hand different models may use the same > southbridge and hence the same DSDT. > > Note that Matthew's made a point here, that apparently there are only two > models using this southbridge and new ones are unlikely to be released, so > my note is for a reference only. No, there's many other systems using the same southbridge that don't have the bizarre DSDT code and so don't show this behaviour. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-30 9:06 ` Matthew Garrett @ 2008-06-30 15:29 ` Maciej W. Rozycki 2008-06-30 15:35 ` Matthew Garrett 0 siblings, 1 reply; 90+ messages in thread From: Maciej W. Rozycki @ 2008-06-30 15:29 UTC (permalink / raw) To: Matthew Garrett Cc: Rafael J. Wysocki, Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown, Andi Kleen, Andrew Morton, Linus Torvalds On Mon, 30 Jun 2008, Matthew Garrett wrote: > > Note that Matthew's made a point here, that apparently there are only two > > models using this southbridge and new ones are unlikely to be released, so > > my note is for a reference only. > > No, there's many other systems using the same southbridge that don't > have the bizarre DSDT code and so don't show this behaviour. I meant "... two models [of HP laptops] using this southbridge..." of course. :) Now I did a search of the Internet and have become puzzled. Apparently there *are* other devices using this DSDT. See for example a thread at: "http://bbs.archlinux.org/viewtopic.php?pid=359559" where an owner of an HP Compaq 6715s has some other problems with a DSDT which coincidentally is the very same HP/SB400/10000 (though built with a different ASL compiler, hmm...). Matthew, where did you get these DMI IDs from? -- I cannot see them being reported in any bootstrap log. Maciej ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-30 15:29 ` Maciej W. Rozycki @ 2008-06-30 15:35 ` Matthew Garrett 0 siblings, 0 replies; 90+ messages in thread From: Matthew Garrett @ 2008-06-30 15:35 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Rafael J. Wysocki, Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown, Andi Kleen, Andrew Morton, Linus Torvalds On Mon, Jun 30, 2008 at 04:29:33PM +0100, Maciej W. Rozycki wrote: > Now I did a search of the Internet and have become puzzled. Apparently > there *are* other devices using this DSDT. See for example a thread at: > "http://bbs.archlinux.org/viewtopic.php?pid=359559" where an owner of an > HP Compaq 6715s has some other problems with a DSDT which coincidentally > is the very same HP/SB400/10000 (though built with a different ASL > compiler, hmm...). Hm. It'd be interesting to know whether the bizarre debug code is in there. What's even more interesting is that the 6715s is an SB600, not an SB400... > Matthew, where did you get these DMI IDs from? -- I cannot see them being > reported in any bootstrap log. dmidecode or /sys/class/dmi. They're not reported on boot. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-29 19:05 ` Maciej W. Rozycki 2008-06-29 19:23 ` Rafael J. Wysocki @ 2008-06-29 19:23 ` Matthew Garrett 2008-06-29 19:31 ` Rafael J. Wysocki 2008-06-29 20:03 ` Maciej W. Rozycki 1 sibling, 2 replies; 90+ messages in thread From: Matthew Garrett @ 2008-06-29 19:23 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Rafael J. Wysocki, Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Sun, Jun 29, 2008 at 08:05:42PM +0100, Maciej W. Rozycki wrote: > It is the reverse -- checking the DSDT ID is coarser, matching all the > systems that use the broken firmware. With DMI we may face both false > positives and false negatives which imply further maintenance actions. > Please note as proved over the years understanding of these issues seems > to be problematic for people, so the result may be another round of > discussions reinventing the wheel in a couple of years' time or so. The DSDT can't be updated without the BIOS being updated, and the DMI information gives us a BIOS version string that can be matched against if a fixed version is ever released. I'd be in favour of doing it with DMI on the grounds that it's how we already handle machine-specific quirks rather than adding new code to do it. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-29 19:23 ` Matthew Garrett @ 2008-06-29 19:31 ` Rafael J. Wysocki 2008-06-29 20:03 ` Maciej W. Rozycki 1 sibling, 0 replies; 90+ messages in thread From: Rafael J. Wysocki @ 2008-06-29 19:31 UTC (permalink / raw) To: Matthew Garrett Cc: Maciej W. Rozycki, Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Sunday, 29 of June 2008, Matthew Garrett wrote: > On Sun, Jun 29, 2008 at 08:05:42PM +0100, Maciej W. Rozycki wrote: > > > It is the reverse -- checking the DSDT ID is coarser, matching all the > > systems that use the broken firmware. With DMI we may face both false > > positives and false negatives which imply further maintenance actions. > > Please note as proved over the years understanding of these issues seems > > to be problematic for people, so the result may be another round of > > discussions reinventing the wheel in a couple of years' time or so. > > The DSDT can't be updated without the BIOS being updated, and the DMI > information gives us a BIOS version string that can be matched against > if a fixed version is ever released. I'd be in favour of doing it with > DMI on the grounds that it's how we already handle machine-specific > quirks rather than adding new code to do it. I violently agree. Thanks, Rafael ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-29 19:23 ` Matthew Garrett 2008-06-29 19:31 ` Rafael J. Wysocki @ 2008-06-29 20:03 ` Maciej W. Rozycki 2008-06-29 20:07 ` Matthew Garrett 1 sibling, 1 reply; 90+ messages in thread From: Maciej W. Rozycki @ 2008-06-29 20:03 UTC (permalink / raw) To: Matthew Garrett Cc: Rafael J. Wysocki, Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Sun, 29 Jun 2008, Matthew Garrett wrote: > The DSDT can't be updated without the BIOS being updated, and the DMI > information gives us a BIOS version string that can be matched against > if a fixed version is ever released. I'd be in favour of doing it with > DMI on the grounds that it's how we already handle machine-specific > quirks rather than adding new code to do it. Is the DMI ID *guaranteed* to be changed with an update to the DSDT? Anyway, you cannot imply from a given DMI ID a broken DSDT is present, so you will have to repeat the experience of adding another DMI ID whenever a user hits this broken DSDT with another piece of hardware. As long as you are able to pull this piece of information from that user, that is... Maciej ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-29 20:03 ` Maciej W. Rozycki @ 2008-06-29 20:07 ` Matthew Garrett 2008-06-29 20:16 ` Maciej W. Rozycki 0 siblings, 1 reply; 90+ messages in thread From: Matthew Garrett @ 2008-06-29 20:07 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Rafael J. Wysocki, Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Sun, Jun 29, 2008 at 09:03:29PM +0100, Maciej W. Rozycki wrote: > Is the DMI ID *guaranteed* to be changed with an update to the DSDT? The BIOS version is, yes. > Anyway, you cannot imply from a given DMI ID a broken DSDT is present, so > you will have to repeat the experience of adding another DMI ID whenever a > user hits this broken DSDT with another piece of hardware. As long as you > are able to pull this piece of information from that user, that is... These are the only two pieces of hardware ever reported to have this problem. Nobody appears to have demonstrated it on any other HP systems, and any non-HP systems would have a different identifier string. With the SB400 being superceded, I don't expect us to see any more machines with the same ID. -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-29 20:07 ` Matthew Garrett @ 2008-06-29 20:16 ` Maciej W. Rozycki 0 siblings, 0 replies; 90+ messages in thread From: Maciej W. Rozycki @ 2008-06-29 20:16 UTC (permalink / raw) To: Matthew Garrett Cc: Rafael J. Wysocki, Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Sun, 29 Jun 2008, Matthew Garrett wrote: > > Is the DMI ID *guaranteed* to be changed with an update to the DSDT? > > The BIOS version is, yes. Good to know, thanks. > > Anyway, you cannot imply from a given DMI ID a broken DSDT is present, so > > you will have to repeat the experience of adding another DMI ID whenever a > > user hits this broken DSDT with another piece of hardware. As long as you > > are able to pull this piece of information from that user, that is... > > These are the only two pieces of hardware ever reported to have this > problem. Nobody appears to have demonstrated it on any other HP systems, > and any non-HP systems would have a different identifier string. With > the SB400 being superceded, I don't expect us to see any more machines > with the same ID. Fair enough. As I wrote, I'll send an update shortly. Maciej ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-20 12:22 ` Rafael J. Wysocki 2008-06-20 12:27 ` Matthew Garrett @ 2008-06-24 9:15 ` Pavel Machek 2008-06-26 8:37 ` Rafael J. Wysocki 2008-06-27 1:53 ` Maciej W. Rozycki 1 sibling, 2 replies; 90+ messages in thread From: Pavel Machek @ 2008-06-24 9:15 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Matthew Garrett, Maciej W. Rozycki, Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown Hi! > > What does ACPI claim the trip points are set to in this case? On the > > 6125, if IRQ 2 is enabled in the APIC then the DSDT sets all the thermal > > trip points to 16 degrees C. I suspect this means that enabling IRQ 2 is > > the wrong thing to do on this chipset. > > Ah, indeed, thanks for the hint. This is the output of > > $ cat /proc/acpi/thermal_zone/TZ*/trip_points > > in the failing case: > > critical (S5): 105 C > passive: 16 C: tc1=1 tc2=2 tsp=100 devices=C000 C001 > active[0]: 16 C: devices=C34F > active[1]: 16 C: devices=C350 > active[2]: 16 C: devices=C351 > active[3]: 16 C: devices=C352 > critical (S5): 100 C > passive: 16 C: tc1=1 tc2=2 tsp=300 devices=C000 C001 > critical (S5): 100 C > passive: 16 C: tc1=1 tc2=2 tsp=300 devices=C000 C001 Can we call the ACPI BIOS to be terminally broken at this point? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-24 9:15 ` Pavel Machek @ 2008-06-26 8:37 ` Rafael J. Wysocki 2008-06-27 1:53 ` Maciej W. Rozycki 1 sibling, 0 replies; 90+ messages in thread From: Rafael J. Wysocki @ 2008-06-26 8:37 UTC (permalink / raw) To: Pavel Machek Cc: Matthew Garrett, Maciej W. Rozycki, Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Tuesday, 24 of June 2008, Pavel Machek wrote: > Hi! > > > > What does ACPI claim the trip points are set to in this case? On the > > > 6125, if IRQ 2 is enabled in the APIC then the DSDT sets all the thermal > > > trip points to 16 degrees C. I suspect this means that enabling IRQ 2 is > > > the wrong thing to do on this chipset. > > > > Ah, indeed, thanks for the hint. This is the output of > > > > $ cat /proc/acpi/thermal_zone/TZ*/trip_points > > > > in the failing case: > > > > critical (S5): 105 C > > passive: 16 C: tc1=1 tc2=2 tsp=100 devices=C000 C001 > > active[0]: 16 C: devices=C34F > > active[1]: 16 C: devices=C350 > > active[2]: 16 C: devices=C351 > > active[3]: 16 C: devices=C352 > > critical (S5): 100 C > > passive: 16 C: tc1=1 tc2=2 tsp=300 devices=C000 C001 > > critical (S5): 100 C > > passive: 16 C: tc1=1 tc2=2 tsp=300 devices=C000 C001 > > Can we call the ACPI BIOS to be terminally broken at this point? It is broken, but the configuration worked before the patch. Consequently, the patch introduces a regression. Thanks, Rafael ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-24 9:15 ` Pavel Machek 2008-06-26 8:37 ` Rafael J. Wysocki @ 2008-06-27 1:53 ` Maciej W. Rozycki 2008-07-08 12:48 ` Pavel Machek 1 sibling, 1 reply; 90+ messages in thread From: Maciej W. Rozycki @ 2008-06-27 1:53 UTC (permalink / raw) To: Pavel Machek Cc: Rafael J. Wysocki, Matthew Garrett, Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Tue, 24 Jun 2008, Pavel Machek wrote: > > $ cat /proc/acpi/thermal_zone/TZ*/trip_points > > > > in the failing case: > > > > critical (S5): 105 C > > passive: 16 C: tc1=1 tc2=2 tsp=100 devices=C000 C001 > > active[0]: 16 C: devices=C34F > > active[1]: 16 C: devices=C350 > > active[2]: 16 C: devices=C351 > > active[3]: 16 C: devices=C352 > > critical (S5): 100 C > > passive: 16 C: tc1=1 tc2=2 tsp=300 devices=C000 C001 > > critical (S5): 100 C > > passive: 16 C: tc1=1 tc2=2 tsp=300 devices=C000 C001 > > Can we call the ACPI BIOS to be terminally broken at this point? Do we have any point of contact at HP and/or ATI/AMD? I suppose getting hands on a SB400 datasheet could be tricky, but someone may be able to answer questions about the interrupt routing between the 8254, the 8259A and the I/O APIC for this chip and/or fix the DSDT. Maciej ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-27 1:53 ` Maciej W. Rozycki @ 2008-07-08 12:48 ` Pavel Machek 0 siblings, 0 replies; 90+ messages in thread From: Pavel Machek @ 2008-07-08 12:48 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Rafael J. Wysocki, Matthew Garrett, Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Fri 2008-06-27 02:53:09, Maciej W. Rozycki wrote: > On Tue, 24 Jun 2008, Pavel Machek wrote: > > > > $ cat /proc/acpi/thermal_zone/TZ*/trip_points > > > > > > in the failing case: > > > > > > critical (S5): 105 C > > > passive: 16 C: tc1=1 tc2=2 tsp=100 devices=C000 C001 > > > active[0]: 16 C: devices=C34F > > > active[1]: 16 C: devices=C350 > > > active[2]: 16 C: devices=C351 > > > active[3]: 16 C: devices=C352 > > > critical (S5): 100 C > > > passive: 16 C: tc1=1 tc2=2 tsp=300 devices=C000 C001 > > > critical (S5): 100 C > > > passive: 16 C: tc1=1 tc2=2 tsp=300 devices=C000 C001 > > > > Can we call the ACPI BIOS to be terminally broken at this point? > > Do we have any point of contact at HP and/or ATI/AMD? I suppose getting > hands on a SB400 datasheet could be tricky, but someone may be able to > answer questions about the interrupt routing between the 8254, the 8259A > and the I/O APIC for this chip and/or fix the DSDT. Yes, we do have AMD contacts. Contact me privately if that's still relevant. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-20 11:53 ` Rafael J. Wysocki 2008-06-20 11:57 ` Matthew Garrett @ 2008-06-21 1:49 ` Maciej W. Rozycki 1 sibling, 0 replies; 90+ messages in thread From: Maciej W. Rozycki @ 2008-06-21 1:49 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Ingo Molnar, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Fri, 20 Jun 2008, Rafael J. Wysocki wrote: > Tested, doesn't work. The symptoms are exactly the same as with the unpatched > kernel. Thanks. > This is the relevant snippet from dmesg: > > [ 0.108006] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 > [ 0.108006] ..MP-BIOS bug: 8254 timer not connected to IO-APIC > [ 0.108006] ...trying to set up timer (IRQ0) through the 8259A ... <3> > [ 0.108006] ..... (found apic 0 pin 2) ...<3> works. > > and the whole thing is at: http://www.sisk.pl/kernel/debug/20080620/dmesg-1.log Hmm, it means INTIN0 is not connected to the output of the 8254. Which in turn means the input is either externally rewirable or internally reconfigurable for the use with the 8254, or something else, or nothing at all (although it seems a dumb idea not to wire the 8254 to the I/O APIC). It might be interesting to know whether the HPET #0 can be routed to INTIN0 on this platform. > What exactly I observe is that in this case: > 1) The cooling fan is 100% on, as though the box were overheating, which seems > to indicate some serious confusion of the platform (the mechanism turning > the fan 100% on is supposed to be transparent to software). > 2) Everything seems to slow down substantially, at least as soon as X is > started. > 3) The box cannot reboot, ie. it turns everything off as expected, but when the > BIOS is supposed to restart the box, it just hangs solid. OK, as explained by Matthew and investigated by myself, it is not exactly a problem with the timer itself, but broken power-management configuration. This could explain the reboot thing too -- our shutdown code is meant to revert all the APIC configuration back to the bootstrap default as yours would not be the first BIOS that has problems with its reboot vector being entered with the APIC infrastructure active. But the bit that's written to the NVRAM may interact with the BIOS for example. OTOH, perhaps something has got broken on the way with the APIC code too -- I have had a look and now we have two local APIC shutdown functions: disable_local_APIC() and lapic_shutdown() with overlapping functionality, plus the I/O APIC is cleared after the local APIC in at least one place, so I would not feel terribly confident about this code. > > What's interesting, the "Virtual Wire IRQ" seems to work for you correctly > > (that's quite an odd setup where a local APIC input is used in the native > > mode -- please post /proc/interrupts for confirmation), > > CPU0 CPU1 > 0: 885 37234 IO-APIC-edge timer [...] > (also available at: http://www.sisk.pl/kernel/debug/20080620/interrupts-1.txt). One for the other configuration, which reports "Virtual Wire IRQ", i.e. without my "x86: I/O APIC: timer through 8259A second-chance" patch, would be more interesting, though perhaps less so now that the reason of the misbehaviour is known. > > which in turn implies the master 8259A drives its INT output as we expect. > > Why would the I/O APIC input have problems then? Hmm... > > Because it's wired to something we're not aware of? Well, sure, but the question in such a case would be: "What for?" The output of the 8259A has had quite a standard meaning for some 30 years now, so I would expect one would not wire it to anything else but the interrupt input of a CPU or an APIC input without a purpose. Or at least a reason. Maciej ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-18 23:39 ` Maciej W. Rozycki 2008-06-19 0:25 ` Rafael J. Wysocki @ 2008-06-19 9:35 ` Ingo Molnar 2008-06-19 18:17 ` Maciej W. Rozycki 1 sibling, 1 reply; 90+ messages in thread From: Ingo Molnar @ 2008-06-19 9:35 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Rafael J. Wysocki, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown * Maciej W. Rozycki <macro@linux-mips.org> wrote: > --- a/arch/x86/kernel/io_apic_64.c 2008-06-18 22:53:34.000000000 +0000 > +++ b/arch/x86/kernel/io_apic_64.c 2008-06-18 22:58:45.000000000 +0000 > @@ -1714,6 +1714,7 @@ static inline void __init check_timer(vo > /* replace_pin_at_irq(0, apic1, pin1, apic2, pin2); */ > setup_timer_IRQ0_pin(apic2, pin2, cfg->vector); > unmask_IO_APIC_irq(0); > + clear_IO_APIC_pin(apic2, pin2); > enable_8259A_irq(0); > if (timer_irq_works()) { > apic_printk(APIC_VERBOSE," works.\n"); would it be fine with you if we applied this to tip/x86, as it unbreaks Rafael's box? does PIT programming matter? One detail which might matter and which touches IRQ0 generation is the clockevent driver on nohz/highres. See arch/x86/kernel/i8253.c:init_pit_timer(): case CLOCK_EVT_MODE_SHUTDOWN: case CLOCK_EVT_MODE_UNUSED: if (evt->mode == CLOCK_EVT_MODE_PERIODIC || evt->mode == CLOCK_EVT_MODE_ONESHOT) { outb_pit(0x30, PIT_MODE); outb_pit(0, PIT_CH0); outb_pit(0, PIT_CH0); } pit_disable_clocksource(); break; case CLOCK_EVT_MODE_ONESHOT: /* One shot setup */ pit_disable_clocksource(); outb_pit(0x38, PIT_MODE); break; Ingo ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-19 9:35 ` Ingo Molnar @ 2008-06-19 18:17 ` Maciej W. Rozycki 2008-06-20 10:44 ` Ingo Molnar 2008-06-20 13:11 ` Thomas Gleixner 0 siblings, 2 replies; 90+ messages in thread From: Maciej W. Rozycki @ 2008-06-19 18:17 UTC (permalink / raw) To: Ingo Molnar Cc: Rafael J. Wysocki, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown On Thu, 19 Jun 2008, Ingo Molnar wrote: > * Maciej W. Rozycki <macro@linux-mips.org> wrote: > > > --- a/arch/x86/kernel/io_apic_64.c 2008-06-18 22:53:34.000000000 +0000 > > +++ b/arch/x86/kernel/io_apic_64.c 2008-06-18 22:58:45.000000000 +0000 > > @@ -1714,6 +1714,7 @@ static inline void __init check_timer(vo > > /* replace_pin_at_irq(0, apic1, pin1, apic2, pin2); */ > > setup_timer_IRQ0_pin(apic2, pin2, cfg->vector); > > unmask_IO_APIC_irq(0); > > + clear_IO_APIC_pin(apic2, pin2); > > enable_8259A_irq(0); > > if (timer_irq_works()) { > > apic_printk(APIC_VERBOSE," works.\n"); > > would it be fine with you if we applied this to tip/x86, as it unbreaks > Rafael's box? It makes no sense to push it anyweher -- it is a diagnostic check only which makes most of the surrounding code useless. It masks the APIC input selected for use so that it can be seen whether the 8259A delivers its interrupt regardless. Obviously in this case it does not, so I must conclude the 8259A is really wired to this I/O APIC input. As expressed before, unfortunately a lot of diagnostic APIC messages have been disabled in the 64-bit variation. The result is I was unable to get good results from my Internet search for bootstrap logs from other systems using this southbridge. Fortunately at least ACPI messages are present and what I noticed is some of the systems do not provide an IRQ0 override and still work correctly. So it is quite possible the chip actually wires the timer interrupt to INTIN0 and the virtual wire cascade to INTIN2 (that would make the ACPI override provided by this machine incorrect). That would be unusual, but not unreasonable, especially for someone like ATI doing their first chipset with no legacy burden carried over. I'll post a patch shortly, that will make it possible to determine that. Overall, it would really help to see the a piece of documentation for the SB400. Now that ATI has been taken over by AMD it might be a bit easier. Both companies have a reasonably good record of providing technical documentation, but AMD's track seems a little bit better. At least to me. Perhaps someone who cooperates with AMD officially could approach them? > does PIT programming matter? One detail which might matter and which > touches IRQ0 generation is the clockevent driver on nohz/highres. See > arch/x86/kernel/i8253.c:init_pit_timer(): > > case CLOCK_EVT_MODE_SHUTDOWN: > case CLOCK_EVT_MODE_UNUSED: > if (evt->mode == CLOCK_EVT_MODE_PERIODIC || > evt->mode == CLOCK_EVT_MODE_ONESHOT) { > outb_pit(0x30, PIT_MODE); > outb_pit(0, PIT_CH0); > outb_pit(0, PIT_CH0); > } > pit_disable_clocksource(); > break; > > case CLOCK_EVT_MODE_ONESHOT: > /* One shot setup */ > pit_disable_clocksource(); > outb_pit(0x38, PIT_MODE); > break; It does, though not necessarily in this case. In principle all this 8254-through-APIC timer validation code assumes the source retriggers automatically and if an edge is lost because the APIC input targeted is masked or not configured yet, another one will follow shortly by itself. It used to be the case when this code was implemented as we never used any of the single-shot modes of the 8254 back then. Is it now possible at the time check_timer() is called the 8254 has been put in one of the single-shot modes? If so, then additional code has to be put in place either to switch the timer into the periodic mode for the duration of check_timer() or to rearm the timer if in a single-shot mode each time timer_irq_works() is called. Maciej ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-19 18:17 ` Maciej W. Rozycki @ 2008-06-20 10:44 ` Ingo Molnar 2008-06-20 13:11 ` Thomas Gleixner 1 sibling, 0 replies; 90+ messages in thread From: Ingo Molnar @ 2008-06-20 10:44 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Rafael J. Wysocki, Stephen Rothwell, linux-next, LKML, Thomas Gleixner, ACPI Devel Maling List, Len Brown * Maciej W. Rozycki <macro@linux-mips.org> wrote: > As expressed before, unfortunately a lot of diagnostic APIC messages > have been disabled in the 64-bit variation. The result is I was > unable to get good results from my Internet search for bootstrap logs > from other systems using this southbridge. Fortunately at least ACPI > messages are present and what I noticed is some of the systems do not > provide an IRQ0 override and still work correctly. [...] okay, so when those files are unified, the diagnostics should remain and be prominent. (or even be put back into the 64-bit version right now.) > > does PIT programming matter? One detail which might matter and which > > touches IRQ0 generation is the clockevent driver on nohz/highres. See > > arch/x86/kernel/i8253.c:init_pit_timer(): > > > > case CLOCK_EVT_MODE_SHUTDOWN: > > case CLOCK_EVT_MODE_UNUSED: > > if (evt->mode == CLOCK_EVT_MODE_PERIODIC || > > evt->mode == CLOCK_EVT_MODE_ONESHOT) { > > outb_pit(0x30, PIT_MODE); > > outb_pit(0, PIT_CH0); > > outb_pit(0, PIT_CH0); > > } > > pit_disable_clocksource(); > > break; > > > > case CLOCK_EVT_MODE_ONESHOT: > > /* One shot setup */ > > pit_disable_clocksource(); > > outb_pit(0x38, PIT_MODE); > > break; > > It does, though not necessarily in this case. In principle all this > 8254-through-APIC timer validation code assumes the source retriggers > automatically and if an edge is lost because the APIC input targeted > is masked or not configured yet, another one will follow shortly by > itself. It used to be the case when this code was implemented as we > never used any of the single-shot modes of the 8254 back then. > > Is it now possible at the time check_timer() is called the 8254 has > been put in one of the single-shot modes? If so, then additional code > has to be put in place either to switch the timer into the periodic > mode for the duration of check_timer() or to rearm the timer if in a > single-shot mode each time timer_irq_works() is called. that's a question for Thomas i guess, he wrote the PIT single-shot code. Ingo ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-19 18:17 ` Maciej W. Rozycki 2008-06-20 10:44 ` Ingo Molnar @ 2008-06-20 13:11 ` Thomas Gleixner 2008-06-20 20:56 ` Maciej W. Rozycki 1 sibling, 1 reply; 90+ messages in thread From: Thomas Gleixner @ 2008-06-20 13:11 UTC (permalink / raw) To: Maciej W. Rozycki Cc: Ingo Molnar, Rafael J. Wysocki, Stephen Rothwell, linux-next, LKML, ACPI Devel Maling List, Len Brown On Thu, 19 Jun 2008, Maciej W. Rozycki wrote: > On Thu, 19 Jun 2008, Ingo Molnar wrote: > > * Maciej W. Rozycki <macro@linux-mips.org> wrote: > > does PIT programming matter? One detail which might matter and which > > touches IRQ0 generation is the clockevent driver on nohz/highres. See > > arch/x86/kernel/i8253.c:init_pit_timer(): > > > > case CLOCK_EVT_MODE_SHUTDOWN: > > case CLOCK_EVT_MODE_UNUSED: > > if (evt->mode == CLOCK_EVT_MODE_PERIODIC || > > evt->mode == CLOCK_EVT_MODE_ONESHOT) { > > outb_pit(0x30, PIT_MODE); > > outb_pit(0, PIT_CH0); > > outb_pit(0, PIT_CH0); > > } > > pit_disable_clocksource(); > > break; > > > > case CLOCK_EVT_MODE_ONESHOT: > > /* One shot setup */ > > pit_disable_clocksource(); > > outb_pit(0x38, PIT_MODE); > > break; > > It does, though not necessarily in this case. In principle all this > 8254-through-APIC timer validation code assumes the source retriggers > automatically and if an edge is lost because the APIC input targeted is > masked or not configured yet, another one will follow shortly by itself. > It used to be the case when this code was implemented as we never used any > of the single-shot modes of the 8254 back then. > > Is it now possible at the time check_timer() is called the 8254 has been > put in one of the single-shot modes? If so, then additional code has to > be put in place either to switch the timer into the periodic mode for the > duration of check_timer() or to rearm the timer if in a single-shot mode > each time timer_irq_works() is called. At this point the PIT is in periodic mode. Let me explain how the timer startup works: PIT is started in periodic mode ... basic CPU bring up APIC timer initialization (switches PIT off) ... Highres/Dyntick mode switches local apic timers to one shot mode When the system has C2/C3 or C1E states, then we restart the PIT in one shot mode and reprogram it every time when the system goes into idle to replace the local apic timer, which stops in those states. Thanks, tglx ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-20 13:11 ` Thomas Gleixner @ 2008-06-20 20:56 ` Maciej W. Rozycki 0 siblings, 0 replies; 90+ messages in thread From: Maciej W. Rozycki @ 2008-06-20 20:56 UTC (permalink / raw) To: Thomas Gleixner Cc: Ingo Molnar, Rafael J. Wysocki, Stephen Rothwell, linux-next, LKML, ACPI Devel Maling List, Len Brown On Fri, 20 Jun 2008, Thomas Gleixner wrote: > > Is it now possible at the time check_timer() is called the 8254 has been > > put in one of the single-shot modes? If so, then additional code has to > > be put in place either to switch the timer into the periodic mode for the > > duration of check_timer() or to rearm the timer if in a single-shot mode > > each time timer_irq_works() is called. > > At this point the PIT is in periodic mode. I had a feeling this was the case -- thanks for your clarification. Nothing to change in check_timer() as far as this property is concerned then. Maciej ^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: linux-next: Tree for June 13: IO APIC breakage on HP nx6325 2008-06-16 13:39 ` Rafael J. Wysocki 2008-06-16 15:39 ` Maciej W. Rozycki @ 2008-06-17 0:08 ` Len Brown 1 sibling, 0 replies; 90+ messages in thread From: Len Brown @ 2008-06-17 0:08 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Maciej W. Rozycki, Stephen Rothwell, linux-next, LKML, Ingo Molnar, Thomas Gleixner > > Can I have .config used and a full bootstrap log from that system with > > the patch still applied? here you go -- linux-next fails on my nx6325 in the same way. comes up with fan on full speed, even though ACPI reports temperature is only 34C. Also, after booting linux-next, a reboot failed to get through POST and I had to hard poweroff the machine. I'll boot next with the AMD C1E failure reverted -- as it just resulted in a nastygram sent over to kerneloops.org... below is dmesg, interrupts, .config cheers, -Len Linux version 2.6.26-rc6-next-20080616 (lenb@d975xbx2) (gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC) ) #1 SMP Mon Jun 16 19:23:56 EDT 2008 Command line: root=/dev/sda3 debug BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000001bfd0000 (usable) BIOS-e820: 000000001bfd0000 - 000000001bfe5600 (reserved) BIOS-e820: 000000001bfe5600 - 000000001bff8000 (ACPI NVS) BIOS-e820: 000000001bff8000 - 0000000020000000 (reserved) BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) BIOS-e820: 00000000fec00000 - 00000000fec02000 (reserved) BIOS-e820: 00000000ffbc0000 - 00000000ffcc0000 (reserved) BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved) Entering add_active_range(0, 0, 159) 0 entries of 3200 used Entering add_active_range(0, 256, 114640) 1 entries of 3200 used last_pfn = 114640 max_arch_pfn = 17179869183 init_memory_mapping DMI 2.4 present. ACPI: RSDP 000F7D30, 0024 (r2 HP ) ACPI: XSDT 1BFE57B4, 0054 (r1 HP 0944 6070620 HP 1) ACPI: FACP 1BFE5684, 00F4 (r4 HP 0944 3 HP 1) ACPI: DSDT 1BFE58DC, EE7A (r1 HP SB400 10000 MSFT 100000E) ACPI: FACS 1BFF7E80, 0040 ACPI: APIC 1BFE5808, 0062 (r1 HP 0944 1 HP 1) ACPI: MCFG 1BFE586C, 003C (r1 HP 0944 1 HP 1) ACPI: TCPA 1BFE58A8, 0032 (r2 HP 0944 1 HP 1) ACPI: SSDT 1BFF4756, 0059 (r1 HP HPQNLP 1 MSFT 100000E) ACPI: SSDT 1BFF47AF, 0182 (r1 HP PSSTBLID 1 HP 1) ACPI: DMI detected: Hewlett-Packard Scanning NUMA topology in Northbridge 24 No NUMA configuration found Faking a node at 0000000000000000-000000001bfd0000 Entering add_active_range(0, 0, 159) 0 entries of 3200 used Entering add_active_range(0, 256, 114640) 1 entries of 3200 used Bootmem setup node 0 0000000000000000-000000001bfd0000 NODE_DATA [0000000000001000 - 0000000000004fff] bootmap [000000000000a000 - 000000000000d7ff] pages 4 early res: 0 [0-fff] BIOS data page early res: 1 [6000-7fff] TRAMPOLINE early res: 2 [200000-8cd457] TEXT DATA BSS early res: 3 [9fc00-fffff] BIOS reserved early res: 4 [8000-9fff] PGTABLE Scan SMP from ffff810000000000 for 1024 bytes. Scan SMP from ffff81000009fc00 for 1024 bytes. Scan SMP from ffff8100000f0000 for 65536 bytes. Scan SMP from ffff81000009fc00 for 1024 bytes. [ffffe20000000000-ffffe200007fffff] PMD -> [ffff810001200000-ffff8100019fffff] on node 0 Zone PFN ranges: DMA 0 -> 4096 DMA32 4096 -> 1048576 Normal 1048576 -> 1048576 Movable zone start PFN for each node early_node_map[2] active PFN ranges 0: 0 -> 159 0: 256 -> 114640 On node 0 totalpages: 114543 DMA zone: 56 pages used for memmap DMA zone: 0 pages reserved DMA zone: 3943 pages, LIFO batch:0 DMA32 zone: 1512 pages used for memmap DMA32 zone: 109032 pages, LIFO batch:31 Normal zone: 0 pages used for memmap Movable zone: 0 pages used for memmap Detected use of extended apic ids on hypertransport bus ACPI: PM-Timer IO Port: 0x8008 ACPI: Local APIC address 0xfee00000 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 2, version 0, address 0xfec00000, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 21 low level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. Setting APIC routing to flat Using ACPI (MADT) for SMP configuration information PM: Registered nosave memory: 000000000009f000 - 00000000000a0000 PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000 PM: Registered nosave memory: 00000000000e0000 - 0000000000100000 Allocating PCI resources starting at 30000000 (gap: 20000000:c0000000) SMP: Allowing 2 CPUs, 0 hotplug CPUs PERCPU: Allocating 33840 bytes of per cpu data NR_CPUS: 32, nr_cpu_ids: 2, nr_node_ids 1 Built 1 zonelists in Node order, mobility grouping on. Total pages: 112975 Policy zone: DMA32 Kernel command line: root=/dev/sda3 debug Initializing CPU#0 PID hash table entries: 2048 (order: 11, 16384 bytes) Extended CMOS year: 2000 TSC calibrated against PM_TIMER Marking TSC unstable due to TSCs unsynchronized time.c: Detected 1596.000 MHz processor. Console: colour VGA+ 80x25 console [tty0] enabled Checking aperture... No AGP bridge found Node 0: aperture @ 1494000000 size 32 MB Aperture beyond 4GB. Ignoring. Memory: 442552k/458560k available (3545k kernel code, 15620k reserved, 2021k data, 468k init) CPA: page pool initialized 1 of 1 pages preallocated Calibrating delay using timer specific routine.. 3194.16 BogoMIPS (lpj=1597080) Dentry cache hash table entries: 65536 (order: 7, 524288 bytes) Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) Mount-cache hash table entries: 256 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU 0/0 -> Node 0 CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 using C1E aware idle routine ACPI: Core revision 20080609 Parsing all Control Methods: Table [DSDT](id 0001) - 1153 Objects with 113 Devices 337 Methods 33 Regions Parsing all Control Methods: Table [SSDT](id 0002) - 2 Objects with 0 Devices 2 Methods 0 Regions Parsing all Control Methods: Table [SSDT](id 0003) - 8 Objects with 0 Devices 0 Methods 0 Regions tbxface-0596 [00] tb_load_namespace : ACPI Tables successfully acquired evxfevnt-0091 [00] enable : Transition to ACPI mode successful ..MP-BIOS bug: 8254 timer not connected to IO-APIC CPU0: AMD Turion(tm) 64 X2 Mobile Technology TL-50 stepping 02 Using local APIC timer interrupts. APIC timer calibration result 12468754 Detected 12.468 MHz APIC timer. Booting processor 1/1 ip 6000 Initializing CPU#1 Calibrating delay using timer specific routine.. 3191.90 BogoMIPS (lpj=1595950) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU 1/1 -> Node 0 CPU: Physical Processor ID: 0 CPU: Processor Core ID: 1 System has C1E enabled CPU1: AMD Turion(tm) 64 X2 Mobile Technology TL-50 stepping 02 Brought up 2 CPUs Total of 2 processors activated (6386.06 BogoMIPS). CPU0 attaching sched-domain: domain 0: span 0-1 level CPU groups: 0 1 domain 1: span 0-1 level NODE groups: 0-1 CPU1 attaching sched-domain: domain 0: span 0-1 level CPU groups: 1 0 domain 1: span 0-1 level NODE groups: 0-1 net_namespace: 360 bytes ------------[ cut here ]------------ WARNING: at kernel/smp.c:215 smp_call_function_single+0x3d/0xa2() Modules linked in: Pid: 0, comm: swapper Not tainted 2.6.26-rc6-next-20080616 #1 Call Trace: [<ffffffff80231adf>] warn_on_slowpath+0x58/0x94 [<ffffffff80231dd3>] ? __call_console_drivers+0x65/0x76 [<ffffffff802478fe>] ? up+0x34/0x39 [<ffffffff802322a8>] ? release_console_sem+0x190/0x19d [<ffffffff802508b0>] smp_call_function_single+0x3d/0xa2 [<ffffffff8024c64a>] tick_broadcast_on_off+0x46/0x48 [<ffffffff8024bcb1>] tick_notify+0x1db/0x33b [<ffffffff805727ab>] notifier_call_chain+0x33/0x5b [<ffffffff80247aa4>] raw_notifier_call_chain+0xf/0x11 [<ffffffff8024b7cc>] clockevents_notify+0x2b/0x80 [<ffffffff80211621>] c1e_idle+0x91/0xd5 [<ffffffff805727f5>] ? atomic_notifier_call_chain+0x13/0x15 [<ffffffff8020a3f3>] cpu_idle+0x64/0xa8 [<ffffffff8056a33e>] start_secondary+0x15d/0x161 ---[ end trace 4eaa2a86a8e2da22 ]--- Switch to broadcast mode on CPU1 NET: Registered protocol family 16 No dock devices found. ------------[ cut here ]------------ WARNING: at kernel/smp.c:215 smp_call_function_single+0x3d/0xa2() Modules linked in: Pid: 0, comm: swapper Tainted: G W 2.6.26-rc6-next-20080616 #1 Call Trace: [<ffffffff80231adf>] warn_on_slowpath+0x58/0x94 [<ffffffff80288c0a>] ? kmem_cache_alloc+0x12f/0x15d [<ffffffff80241c50>] ? alloc_pid+0x25b/0x377 [<ffffffff8022b17d>] ? enqueue_task_fair+0x1e4/0x1f0 [<ffffffff802508b0>] smp_call_function_single+0x3d/0xa2 [<ffffffff8024c64a>] tick_broadcast_on_off+0x46/0x48 [<ffffffff8024bcb1>] tick_notify+0x1db/0x33b [<ffffffff805727ab>] notifier_call_chain+0x33/0x5b [<ffffffff80247aa4>] raw_notifier_call_chain+0xf/0x11 [<ffffffff8024b7cc>] clockevents_notify+0x2b/0x80 [<ffffffff80211621>] c1e_idle+0x91/0xd5 [<ffffffff805727f5>] ? atomic_notifier_call_chain+0x13/0x15 [<ffffffff8020a3f3>] cpu_idle+0x64/0xa8 [<ffffffff80551c2d>] rest_init+0x61/0x63 [<ffffffff80789d68>] start_kernel+0x2f0/0x2fb [<ffffffff80789376>] x86_64_start_kernel+0x185/0x18c ---[ end trace 4eaa2a86a8e2da22 ]--- Switch to broadcast mode on CPU0 node 0 link 0: io port [1000, fffff] TOM: 0000000020000000 aka 512M node 0 link 0: mmio [f0000000, ffffffff] node 0 link 0: mmio [e0000000, efffffff] node 0 link 0: mmio [c4000000, dfffffff] node 0 link 0: mmio [c0000000, c3ffffff] node 0 link 0: mmio [a0000, bffff] node 0 link 0: mmio [20000000, bfffffff] bus: [00,ff] on node 0 link 0 bus: 00 index 0 io port: [0, ffff] bus: 00 index 1 mmio: [20000000, fcffffffff] bus: 00 index 2 mmio: [a0000, bffff] ACPI: bus type pci registered PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255 PCI: MCFG area at e0000000 reserved in E820 PCI: Using MMCONFIG at e0000000 - efffffff PCI: Using configuration type 1 for base access evgpeblk-0952 [00] ev_create_gpe_block : GPE 00 to 1F [_GPE] 4 regs on int 0x15 ACPI: EC: Look up EC in DSDT ACPI: EC: non-query interrupt received, switching to interrupt mode Completing Region/Field/Buffer/Package initialization:......................................................................................................................................................................... Initialized 29/33 Regions 0/0 Fields 63/64 Buffers 77/78 Packages (1172 nodes) Initializing Device/Processor/Thermal objects by executing _INI methods:....... Executed 7 _INI methods requiring 2 _STA executions (examined 120 objects) evgpeblk-1049 [00] ev_initialize_gpe_bloc: Found 3 Wake, Enabled 11 Runtime GPEs in this block ACPI: Interpreter enabled ACPI: (supports S0 S3 S4 S5) ACPI: Using IOAPIC for interrupt routing ACPI: EC: GPE = 0x11, I/O: command/status = 0x66, data = 0x62 ACPI: EC: driver started in interrupt mode ACPI: PCI Root Bridge [C074] (0000:00) HPET not enabled in BIOS. You might try hpet=force boot option PCI: Transparent bridge - 0000:00:14.4 ACPI: PCI Interrupt Routing Table [\_SB_.C074._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.C074.C075._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.C074.C0DF._PRT] ACPI: PCI Interrupt Link [C125] (IRQs 10 11) *0, disabled. ACPI: PCI Interrupt Link [C126] (IRQs 10 11) *0, disabled. ACPI: PCI Interrupt Link [C127] (IRQs 10 11) *0, disabled. ACPI: PCI Interrupt Link [C128] (IRQs 10 11) *0, disabled. ACPI: PCI Interrupt Link [C129] (IRQs 10 11) *0, disabled. ACPI: PCI Interrupt Link [C12A] (IRQs 9) *0, disabled. ACPI: PCI Interrupt Link [C12B] (IRQs 10 11) *0, disabled. ACPI: PCI Interrupt Link [C12C] (IRQs *10 11) ACPI: Power Resource [C223] (off) ACPI: Power Resource [C1FE] (off) ACPI: Power Resource [C217] (on) ACPI: Power Resource [C34B] (off) ACPI: Power Resource [C34C] (off) ACPI: Power Resource [C34D] (off) ACPI: Power Resource [C34E] (off) Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init ACPI: bus type pnp registered pnp: PnP ACPI: found 13 devices ACPI: ACPI bus type pnp unregistered SCSI subsystem initialized libata version 3.00 loaded. usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: Using ACPI for IRQ routing PCI: Cannot allocate resource region 0 of device 0000:00:14.2 DMAR:parse DMAR table failure. tracer: 1286 pages allocated for 65536<6> entries of 80 bytes actual entries 65586 system 00:00: iomem range 0x0-0x9ffff could not be reserved system 00:00: iomem range 0xe0000-0xfffff could not be reserved system 00:00: iomem range 0x100000-0x1bffffff could not be reserved system 00:0a: ioport range 0x40b-0x40b has been reserved system 00:0a: ioport range 0x4d0-0x4d1 has been reserved system 00:0a: ioport range 0x4d6-0x4d6 has been reserved system 00:0a: ioport range 0x500-0x51f has been reserved system 00:0a: ioport range 0xc00-0xc01 has been reserved system 00:0a: ioport range 0xc14-0xc14 has been reserved system 00:0a: ioport range 0xc50-0xc51 has been reserved system 00:0a: ioport range 0xc52-0xc52 has been reserved system 00:0a: ioport range 0xc6c-0xc6c has been reserved system 00:0a: ioport range 0xc6f-0xc6f has been reserved system 00:0a: ioport range 0xcd4-0xcdf has been reserved system 00:0a: iomem range 0xffb00000-0xffbfffff could not be reserved system 00:0a: iomem range 0xfff00000-0xffffffff could not be reserved system 00:0b: ioport range 0x8000-0x802f has been reserved system 00:0b: ioport range 0x8100-0x811f has been reserved system 00:0b: iomem range 0xe0000000-0xefffffff could not be reserved system 00:0b: iomem range 0xfec00000-0xfec00fff could not be reserved system 00:0c: iomem range 0xcf000-0xcffff has been reserved system 00:0c: iomem range 0x1c000000-0x1fffffff could not be reserved system 00:0c: iomem range 0xfee00000-0xfee00fff has been reserved PCI: region 0000:02:04.0/9 too large: 0x0000000000000000-0x0000000003ffffff PCI: Bridge: 0000:00:01.0 IO window: 6000-6fff MEM window: 0xd0300000-0xd03fffff PREFETCH window: 0x00000000c0000000-0x00000000c3ffffff Switched to high resolution mode on CPU 0 PCI: Bridge: 0000:00:04.0 IO window: 4000-5fff MEM window: 0xcc000000-0xcfffffff PREFETCH window: disabled. PCI: Bridge: 0000:00:05.0 IO window: 2000-3fff MEM window: 0xc8000000-0xcbffffff PREFETCH window: disabled. PCI: Bridge: 0000:00:06.0 IO window: disabled. MEM window: 0xc4000000-0xc40fffff PREFETCH window: disabled. PCI: Bus 3, cardbus bridge: 0000:02:04.0 IO window: 0x00001000-0x000010ff IO window: 0x00001400-0x000014ff MEM window: 0x34000000-0x37ffffff PCI: Bridge: 0000:00:14.4 IO window: 1000-1fff MEM window: 0xd0000000-0xd02fffff PREFETCH window: disabled. PCI: Setting latency timer of device 0000:00:04.0 to 64 PCI: Setting latency timer of device 0000:00:05.0 to 64 PCI: Setting latency timer of device 0000:00:06.0 to 64 ACPI: PCI Interrupt 0000:02:04.0[A] -> GSI 20 (level, low) -> IRQ 20 Int: type 0, pol 3, trig 3, bus 02, IRQ 10, APIC ID 2, APIC INT 14 NET: Registered protocol family 2 Switched to high resolution mode on CPU 1 IP route cache hash table entries: 4096 (order: 3, 32768 bytes) TCP established hash table entries: 16384 (order: 6, 262144 bytes) TCP bind hash table entries: 16384 (order: 6, 262144 bytes) TCP: Hash tables configured (established 16384 bind 16384) TCP reno registered NET: Registered protocol family 1 Installing knfsd (copyright (C) 1996 okir@monad.swb.de). msgmni has been set to 864 io scheduler noop registered io scheduler deadline registered io scheduler cfq registered (default) pci 0000:00:00.0: MSI quirk detected; MSI disabled pci 0000:01:05.0: Boot video device PCI: Setting latency timer of device 0000:00:04.0 to 64 assign_interrupt_mode Found MSI capability Allocate Port Service[0000:00:04.0:pcie00] Allocate Port Service[0000:00:04.0:pcie01] Allocate Port Service[0000:00:04.0:pcie03] PCI: Setting latency timer of device 0000:00:05.0 to 64 assign_interrupt_mode Found MSI capability Allocate Port Service[0000:00:05.0:pcie00] Allocate Port Service[0000:00:05.0:pcie01] Allocate Port Service[0000:00:05.0:pcie03] PCI: Setting latency timer of device 0000:00:06.0 to 64 assign_interrupt_mode Found MSI capability Allocate Port Service[0000:00:06.0:pcie00] Allocate Port Service[0000:00:06.0:pcie01] Allocate Port Service[0000:00:06.0:pcie03] AER service couldn't init device 0000:00:04.0:pcie01 - no _OSC support AER service couldn't init device 0000:00:05.0:pcie01 - no _OSC support AER service couldn't init device 0000:00:06.0:pcie01 - no _OSC support input: Power Button (FF) as /class/input/input0 ACPI: Power Button (FF) [PWRF] input: Sleep Button (CM) as /class/input/input1 ACPI: Sleep Button (CM) [C25A] input: Lid Switch as /class/input/input2 ACPI: Lid Switch [C25B] processor ACPI0007:00: registered as cooling_device0 ACPI: Processor [C000] (supports 8 throttling states) processor ACPI0007:01: registered as cooling_device1 ACPI: Processor [C001] (supports 8 throttling states) Linux agpgart interface v0.103 Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled Floppy drive(s): fd0 is 1.44M floppy0: no floppy controllers found brd: module loaded loop: module loaded Intel(R) PRO/1000 Network Driver - version 7.3.20-k2 Copyright (c) 1999-2006 Intel Corporation. e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI e100: Copyright(c) 1999-2006 Intel Corporation tg3.c:v3.93 (May 22, 2008) ACPI: PCI Interrupt 0000:02:01.0[A] -> GSI 23 (level, low) -> IRQ 23 Int: type 0, pol 3, trig 3, bus 02, IRQ 04, APIC ID 2, APIC INT 17 eth0: Tigon3 [partno(BCM95788A50) rev 3003 PHY(5705)] (PCI:33MHz:32-bit) 10/100/1000Base-T Ethernet 00:17:08:30:e4:ee eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[0] TSOcap[1] eth0: dma_rwctrl[763f0000] dma_mask[32-bit] tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com> console [netcon0] enabled netconsole: network logging started Uniform Multi-Platform E-IDE driver ATIIXP: IDE controller (0x1002:0x4376 rev 0x80) at PCI slot 0000:00:14.1 ACPI: PCI Interrupt 0000:00:14.1[A] -> GSI 16 (level, low) -> IRQ 16 Int: type 0, pol 3, trig 3, bus 00, IRQ 50, APIC ID 2, APIC INT 10 ATIIXP: not 100% native mode: will probe irqs later ide0: BM-DMA at 0x7040-0x7047 ATIIXP: simplex device: DMA disabled ide1: DMA disabled Probing IDE interface ide0... hda: TSSTcorpCDW/DVD TS-L462C, ATAPI CD/DVD-ROM drive hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4 hda: MWDMA2 mode selected Probing IDE interface ide1... ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 ide_generic: please use "probe_mask=0x3f" module parameter for probing all legacy ISA IDE ports ide_generic: I/O resource 0x1F0-0x1F7 not free. ide_generic: I/O resource 0x170-0x177 not free. hda: ATAPI 24X DVD-ROM CD-R/RW drive, 1536kB Cache Uniform CD-ROM driver Revision: 3.20 Driver 'sd' needs updating - please use bus_type methods Driver 'sr' needs updating - please use bus_type methods sata_sil 0000:00:12.0: version 2.3 ACPI: PCI Interrupt 0000:00:12.0[A] -> GSI 16 (level, low) -> IRQ 16 Int: type 0, pol 3, trig 3, bus 00, IRQ 48, APIC ID 2, APIC INT 10 scsi0 : sata_sil scsi1 : sata_sil ata1: SATA max UDMA/100 mmio m512@0xd0409000 tf 0xd0409080 irq 16 ata2: SATA max UDMA/100 mmio m512@0xd0409000 tf 0xd04090c0 irq 16 ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: ATA-7: FUJITSU MHT2040BH, 0000104A, max UDMA/100 ata1.00: 78140160 sectors, multi 16: LBA48 NCQ (depth 0/32) ata1.00: configured for UDMA/100 ata2: SATA link down (SStatus 0 SControl 300) isa bounce pool size: 16 pages scsi 0:0:0:0: Direct-Access ATA FUJITSU MHT2040B 0000 PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 78140160 512-byte hardware sectors (40008 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 78140160 512-byte hardware sectors (40008 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sd 0:0:0:0: [sda] Attached SCSI disk sd 0:0:0:0: Attached scsi generic sg0 type 0 ACPI: PCI Interrupt 0000:02:04.1[A] -> GSI 20 (level, low) -> IRQ 20 Int: type 0, pol 3, trig 3, bus 02, IRQ 10, APIC ID 2, APIC INT 14 ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[20] MMIO=[d0011000-d00117ff] Max Packet=[2048] IR/IT contexts=[4/8] ieee1394: raw1394: /dev/raw1394 device initialized ACPI: PCI Interrupt 0000:00:13.2[A] -> GSI 19 (level, low) -> IRQ 19 Int: type 0, pol 3, trig 3, bus 00, IRQ 4c, APIC ID 2, APIC INT 13 ehci_hcd 0000:00:13.2: EHCI Host Controller ehci_hcd 0000:00:13.2: new USB bus registered, assigned bus number 1 ehci_hcd 0000:00:13.2: irq 19, io mem 0xd0403000 ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 8 ports detected usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: EHCI Host Controller usb usb1: Manufacturer: Linux 2.6.26-rc6-next-20080616 ehci_hcd usb usb1: SerialNumber: 0000:00:13.2 ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver ACPI: PCI Interrupt 0000:00:13.0[A] -> GSI 19 (level, low) -> IRQ 19 Int: type 0, pol 3, trig 3, bus 00, IRQ 4c, APIC ID 2, APIC INT 13 ohci_hcd 0000:00:13.0: OHCI Host Controller ohci_hcd 0000:00:13.0: new USB bus registered, assigned bus number 2 ohci_hcd 0000:00:13.0: irq 19, io mem 0xd0401000 usb usb2: configuration #1 chosen from 1 choice hub 2-0:1.0: USB hub found hub 2-0:1.0: 4 ports detected usb usb2: New USB device found, idVendor=1d6b, idProduct=0001 usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb2: Product: OHCI Host Controller usb usb2: Manufacturer: Linux 2.6.26-rc6-next-20080616 ohci_hcd usb usb2: SerialNumber: 0000:00:13.0 ACPI: PCI Interrupt 0000:00:13.1[A] -> GSI 19 (level, low) -> IRQ 19 Int: type 0, pol 3, trig 3, bus 00, IRQ 4c, APIC ID 2, APIC INT 13 ohci_hcd 0000:00:13.1: OHCI Host Controller ohci_hcd 0000:00:13.1: new USB bus registered, assigned bus number 3 ohci_hcd 0000:00:13.1: irq 19, io mem 0xd0402000 usb usb3: configuration #1 chosen from 1 choice hub 3-0:1.0: USB hub found hub 3-0:1.0: 4 ports detected usb usb3: New USB device found, idVendor=1d6b, idProduct=0001 usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb3: Product: OHCI Host Controller usb usb3: Manufacturer: Linux 2.6.26-rc6-next-20080616 ohci_hcd usb usb3: SerialNumber: 0000:00:13.1 USB Universal Host Controller Interface driver v3.0 Initializing USB Mass Storage driver... usb 3-1: new full speed USB device using ohci_hcd and address 2 usb 3-1: configuration #1 chosen from 1 choice usb 3-1: New USB device found, idVendor=08ff, idProduct=2580 usb 3-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 usb 3-1: Product: Fingerprint Sensor usbcore: registered new interface driver usb-storage USB Mass Storage support registered. PNP: PS/2 Controller [PNP0303:C214,PNP0f13:C215] at 0x60,0x64 irq 1,12 i8042.c: Detected active multiplexing controller, rev 1.1. serio: i8042 KBD port at 0x60,0x64 irq 1 serio: i8042 AUX0 port at 0x60,0x64 irq 12 serio: i8042 AUX1 port at 0x60,0x64 irq 12 serio: i8042 AUX2 port at 0x60,0x64 irq 12 serio: i8042 AUX3 port at 0x60,0x64 irq 12 mice: PS/2 mouse device common for all mice input: AT Translated Set 2 keyboard as /class/input/input3 cpuidle: using governor ladder cpuidle: using governor menu usbcore: registered new interface driver usbhid usbhid: v2.6:USB HID core driver Advanced Linux Sound Architecture Driver Version 1.0.17rc1. ALSA device list: No soundcards found. oprofile: using NMI interrupt. TCP cubic registered NET: Registered protocol family 17 RPC: Registered udp transport module. RPC: Registered tcp transport module. drivers/rtc/hctosys.c: unable to open rtc device (rtc0) Synaptics Touchpad, model: 1, fw: 6.2, id: 0x25a0b1, caps: 0xa04793/0x300000 serio: Synaptics pass-through port at isa0060/serio4/input0 input: SynPS/2 Synaptics TouchPad as /class/input/input4 kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: 468k freed thermal LNXTHERM:01: registered as thermal_zone0 power_supply C1BD: uevent power_supply C1BD: No power supply yet power_supply C1BD: power_supply_changed power_supply C1BD: power_supply_changed_work power_supply C1BD: power_supply_update_gen_leds 1 power_supply C1BD: uevent power_supply C1BD: POWER_SUPPLY_NAME=C1BD power_supply C1BD: Static prop TYPE=Mains power_supply C1BD: 1 dynamic props power_supply C1BD: prop ONLINE=1 ACPI: AC Adapter [C1BD] (on-line) ACPI: Thermal Zone [TZ1] (55 C) thermal LNXTHERM:02: registered as thermal_zone1 ACPI: Thermal Zone [TZ2] (47 C) input: Video Bus as /class/input/input5 thermal LNXTHERM:03: registered as thermal_zone2 ACPI: Video Device [C076] (multi-head: yes rom: no post: no) ACPI: Thermal Zone [TZ3] (28 C) fan PNP0C0B:00: registered as cooling_device2 ACPI: Fan [C34F] (on) fan PNP0C0B:01: registered as cooling_device3 ACPI: Fan [C350] (on) fan PNP0C0B:02: registered as cooling_device4 ACPI: Fan [C351] (on) fan PNP0C0B:03: registered as cooling_device5 ACPI: Fan [C352] (on) power_supply C1BF: uevent power_supply C1BF: No power supply yet power_supply C1BF: power_supply_changed power_supply C1BF: power_supply_changed_work power_supply C1BF: power_supply_update_bat_leds 4 ACPI: Battery Slot [C1BF] (battery present) power_supply C1BF: uevent power_supply C1BF: POWER_SUPPLY_NAME=C1BF power_supply C1BF: Static prop TYPE=Battery power_supply C1BF: 12 dynamic props power_supply C1BF: prop STATUS=Full power_supply C1BF: prop PRESENT=1 power_supply C1BF: prop TECHNOLOGY=Li-ion power_supply C1BF: prop VOLTAGE_MIN_DESIGN=10800000 power_supply C1BF: prop VOLTAGE_NOW=12176000 power_supply C1BF: prop CURRENT_NOW=0 power_supply C1BF: prop CHARGE_FULL_DESIGN=4679000 power_supply C1BF: prop CHARGE_FULL=4679000 power_supply C1BF: prop CHARGE_NOW=4608000 power_supply C1BF: prop MODEL_NAME=Primary power_supply C1BF: prop MANUFACTURER=Hewlett-Packard power_supply C1BF: prop SERIAL_NUMBER=39279 2006/08/07 ACPI: Battery Slot [C1BE] (battery absent) ACPI: WMI: Mapper loaded Yenta: CardBus bridge found at 0000:02:04.0 [103c:30b0] PCI: Bus 3, cardbus bridge: 0000:02:04.0 IO window: 0x00001000-0x000010ff IO window: 0x00001400-0x000014ff PREFETCH window: 0x30400000-0x307fffff MEM window: 0x34000000-0x37ffffff Yenta: Enabling burst memory read transactions Yenta: Using INTVAL to route CSC interrupts to PCI Yenta: Routing CardBus interrupts to PCI Yenta TI: socket 0000:02:04.0, mfunc 0x01a11002, devctl 0x64 ACPI: PCI Interrupt 0000:00:14.2[A] -> GSI 16 (level, low) -> IRQ 16 Int: type 0, pol 3, trig 3, bus 00, IRQ 50, APIC ID 2, APIC INT 10 Yenta: ISA IRQ mask 0x0ef8, PCI irq 20 Socket status: 30000006 Yenta: Raising subordinate bus# of parent bus (#02) from #03 to #06 pcmcia: parent PCI bridge I/O window: 0x1000 - 0x1fff pcmcia: parent PCI bridge Memory window: 0xd0000000 - 0xd02fffff EXT3 FS on sda3, internal journal kjournald starting. Commit interval 5 seconds EXT3 FS on sda1, internal journal EXT3-fs: mounted filesystem with ordered data mode. Adding 4192956k swap on /dev/sda2. Priority:-1 extents:1 across:4192956k powernow-k8: Found 1 AMD Turion(tm) 64 X2 Mobile Technology TL-50 processors (2 cpu cores) (version 2.20.00) powernow-k8: 0 : fid 0x8 (1600 MHz), vid 0x13 powernow-k8: 1 : fid 0x0 (800 MHz), vid 0x1e powernow-k8: ph2 null fid transition 0x8 Clocksource tsc unstable (delta = -243799907 ns) warning: `dbus-daemon' uses deprecated v2 capabilities in a way that may be insecure. CPU0 CPU1 0: 227 11385 IO-APIC-edge timer 1: 1 7 IO-APIC-edge i8042 12: 1 147 IO-APIC-edge i8042 14: 0 55 IO-APIC-edge ide0 15: 0 0 IO-APIC-edge ide1 16: 29 2314 IO-APIC-fasteoi sata_sil, HDA Intel 19: 1 24 IO-APIC-fasteoi ehci_hcd:usb1, ohci_hcd:usb2, ohci_hcd:usb3 20: 0 2 IO-APIC-fasteoi ohci1394, yenta 21: 0 143 IO-APIC-fasteoi acpi NMI: 0 0 Non-maskable interrupts LOC: 11098 7456 Local timer interrupts RES: 3796 2519 Rescheduling interrupts CAL: 63 65 function call interrupts TLB: 323 178 TLB shootdowns TRM: 0 0 Thermal event interrupts THR: 0 0 Threshold APIC interrupts SPU: 0 0 Spurious interrupts ERR: 0 # # Automatically generated make config: don't edit # Linux kernel version: 2.6.26-rc6 # Mon Jun 16 19:22:07 2008 # CONFIG_64BIT=y # CONFIG_X86_32 is not set CONFIG_X86_64=y CONFIG_X86=y CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" # CONFIG_GENERIC_LOCKBREAK is not set CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y # CONFIG_GENERIC_GPIO is not set CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_RWSEM_XCHGADD_ALGORITHM is not set # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_HAVE_CPUMASK_OF_CPU_MAP=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ZONE_DMA32=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_AOUT=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_X86_SMP=y CONFIG_X86_64_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y # CONFIG_KTIME_SCALAR is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=18 # CONFIG_CGROUPS is not set CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y # CONFIG_GROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_RELAY is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_SYSCTL_SYSCALL_CHECK=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_COMPAT_BRK=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_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_PROFILING=y # CONFIG_MARKERS is not set CONFIG_OPROFILE=y CONFIG_HAVE_OPROFILE=y CONFIG_KPROBES=y CONFIG_KRETPROBES=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y # CONFIG_HAVE_DMA_ATTRS is not set CONFIG_USE_GENERIC_SMP_HELPERS=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set # CONFIG_KMOD is not set CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_BLK_DEV_BSG is not set CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" CONFIG_CLASSIC_RCU=y # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_RDC321X is not set # CONFIG_X86_VSMP is not set # CONFIG_PARAVIRT_GUEST is not set CONFIG_MEMTEST=y # 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 is not set # 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_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_MPSC is not set CONFIG_MCORE2=y # CONFIG_GENERIC_CPU is not set CONFIG_X86_CPU=y CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_INTERNODE_CACHE_BYTES=64 CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_P6_NOP=y CONFIG_X86_TSC=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=64 CONFIG_X86_DEBUGCTLMSR=y CONFIG_HPET_TIMER=y CONFIG_DMI=y CONFIG_GART_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_SWIOTLB=y CONFIG_IOMMU_HELPER=y # CONFIG_MAXSMP is not set CONFIG_NR_CPUS=32 CONFIG_SCHED_SMT=y CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_INTEL=y CONFIG_X86_MCE_AMD=y CONFIG_I8K=m # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_NUMA=y CONFIG_K8_NUMA=y CONFIG_X86_64_ACPI_NUMA=y CONFIG_NODES_SPAN_OTHER_NODES=y CONFIG_NUMA_EMU=y CONFIG_NODES_SHIFT=6 CONFIG_ARCH_SPARSEMEM_DEFAULT=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_ILLEGAL_POINTER_VALUE=0xffffc10000000000 CONFIG_SELECT_MEMORY_MODEL=y # CONFIG_FLATMEM_MANUAL is not set # CONFIG_DISCONTIGMEM_MANUAL is not set CONFIG_SPARSEMEM_MANUAL=y CONFIG_SPARSEMEM=y CONFIG_NEED_MULTIPLE_NODES=y CONFIG_HAVE_MEMORY_PRESENT=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPARSEMEM_EXTREME=y CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y CONFIG_SPARSEMEM_VMEMMAP=y # # Memory hotplug is currently incompatible with Software Suspend # CONFIG_PAGEFLAGS_EXTENDED=y CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_MIGRATION=y CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_VIRT_TO_BUS=y CONFIG_MTRR=y CONFIG_MTRR_SANITIZER=y CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0 CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1 # CONFIG_X86_PAT is not set # CONFIG_EFI is not set CONFIG_SECCOMP=y # CONFIG_CC_STACKPROTECTOR is not set # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set # CONFIG_HZ_300 is not set CONFIG_HZ_1000=y CONFIG_HZ=1000 CONFIG_SCHED_HRTICK=y # CONFIG_KEXEC is not set # CONFIG_CRASH_DUMP is not set CONFIG_PHYSICAL_START=0x200000 # CONFIG_RELOCATABLE is not set CONFIG_PHYSICAL_ALIGN=0x200000 CONFIG_HOTPLUG_CPU=y CONFIG_COMPAT_VDSO=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID=y # # Power management options # CONFIG_ARCH_HIBERNATION_HEADER=y CONFIG_PM=y # CONFIG_PM_DEBUG is not set CONFIG_PM_SLEEP_SMP=y CONFIG_PM_SLEEP=y CONFIG_SUSPEND=y CONFIG_SUSPEND_FREEZER=y CONFIG_HIBERNATION=y CONFIG_PM_STD_PARTITION="" CONFIG_ACPI=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_PROCFS=y CONFIG_ACPI_PROCFS_POWER=y CONFIG_ACPI_SYSFS_POWER=y CONFIG_ACPI_PROC_EVENT=y CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=y CONFIG_ACPI_VIDEO=m CONFIG_ACPI_FAN=m CONFIG_ACPI_DOCK=y CONFIG_ACPI_BAY=m CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_HOTPLUG_CPU=y CONFIG_ACPI_THERMAL=m CONFIG_ACPI_NUMA=y CONFIG_ACPI_WMI=m # CONFIG_ACPI_ASUS is not set CONFIG_ACPI_TOSHIBA=m CONFIG_ACPI_CUSTOM_DSDT_FILE="" # CONFIG_ACPI_CUSTOM_DSDT is not set CONFIG_ACPI_BLACKLIST_YEAR=0 CONFIG_ACPI_DEBUG=y # CONFIG_ACPI_DEBUG_FUNC_TRACE is not set CONFIG_ACPI_EC=y # CONFIG_ACPI_PCI_SLOT is not set CONFIG_ACPI_POWER=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y CONFIG_ACPI_CONTAINER=y CONFIG_ACPI_SBS=m # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y CONFIG_CPU_FREQ_DEBUG=y CONFIG_CPU_FREQ_STAT=m CONFIG_CPU_FREQ_STAT_DETAILS=y # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=m CONFIG_CPU_FREQ_GOV_ONDEMAND=y # CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set # # CPUFreq processor drivers # CONFIG_X86_ACPI_CPUFREQ=m CONFIG_X86_POWERNOW_K8=m CONFIG_X86_POWERNOW_K8_ACPI=y CONFIG_X86_SPEEDSTEP_CENTRINO=m CONFIG_X86_P4_CLOCKMOD=m # # shared options # # CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set CONFIG_X86_SPEEDSTEP_LIB=m CONFIG_CPU_IDLE=y CONFIG_CPU_IDLE_GOV_LADDER=y CONFIG_CPU_IDLE_GOV_MENU=y # # Bus options (PCI etc.) # CONFIG_PCI=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_DOMAINS=y CONFIG_DMAR=y CONFIG_DMAR_GFX_WA=y CONFIG_DMAR_FLOPPY_WA=y CONFIG_PCIEPORTBUS=y CONFIG_PCIEAER=y CONFIG_PCIEASPM=y # CONFIG_PCIEASPM_DEBUG is not set CONFIG_ARCH_SUPPORTS_MSI=y CONFIG_PCI_MSI=y CONFIG_PCI_LEGACY=y # CONFIG_PCI_DEBUG is not set # CONFIG_HT_IRQ is not set CONFIG_ISA_DMA_API=y CONFIG_K8_NB=y CONFIG_PCCARD=y CONFIG_PCMCIA_DEBUG=y CONFIG_PCMCIA=m CONFIG_PCMCIA_LOAD_CIS=y CONFIG_PCMCIA_IOCTL=y CONFIG_CARDBUS=y # # PC-card bridges # CONFIG_YENTA=m CONFIG_YENTA_O2=y CONFIG_YENTA_RICOH=y CONFIG_YENTA_TI=y CONFIG_YENTA_ENE_TUNE=y CONFIG_YENTA_TOSHIBA=y # CONFIG_PD6729 is not set # CONFIG_I82092 is not set CONFIG_PCCARD_NONSTATIC=m # CONFIG_HOTPLUG_PCI is not set # # Executable file formats / Emulations # CONFIG_BINFMT_ELF=y CONFIG_COMPAT_BINFMT_ELF=y # CONFIG_BINFMT_MISC is not set CONFIG_IA32_EMULATION=y CONFIG_IA32_AOUT=y CONFIG_COMPAT=y CONFIG_COMPAT_FOR_U64_ALIGNMENT=y CONFIG_SYSVIPC_COMPAT=y # # Networking # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set CONFIG_UNIX=y # CONFIG_NET_KEY is not set CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set CONFIG_IP_FIB_HASH=y CONFIG_IP_PNP=y CONFIG_IP_PNP_DHCP=y # CONFIG_IP_PNP_BOOTP is not set # CONFIG_IP_PNP_RARP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set # CONFIG_ARPD is not set # CONFIG_SYN_COOKIES is not set # CONFIG_INET_AH is not set # CONFIG_INET_ESP is not set # CONFIG_INET_IPCOMP is not set # CONFIG_INET_XFRM_TUNNEL is not set # CONFIG_INET_TUNNEL is not set # CONFIG_INET_XFRM_MODE_TRANSPORT is not set # CONFIG_INET_XFRM_MODE_TUNNEL is not set # CONFIG_INET_XFRM_MODE_BEET is not set # CONFIG_INET_LRO is not set CONFIG_INET_DIAG=y CONFIG_INET_TCP_DIAG=y # CONFIG_TCP_CONG_ADVANCED is not set CONFIG_TCP_CONG_CUBIC=y CONFIG_DEFAULT_TCP_CONG="cubic" # CONFIG_TCP_MD5SIG is not set # CONFIG_IPV6 is not set # CONFIG_NETWORK_SECMARK is not set # CONFIG_NETFILTER is not set # CONFIG_IP_DCCP is not set # CONFIG_IP_SCTP is not set # CONFIG_TIPC is not set # CONFIG_ATM is not set # CONFIG_BRIDGE is not set # CONFIG_VLAN_8021Q is not set # CONFIG_DECNET is not set # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_SCHED is not set # # Network testing # # CONFIG_NET_PKTGEN is not set # CONFIG_NET_TCPPROBE is not set # CONFIG_HAMRADIO is not set # CONFIG_CAN is not set # CONFIG_IRDA is not set # CONFIG_BT is not set # CONFIG_AF_RXRPC is not set # # Wireless # CONFIG_CFG80211=m CONFIG_NL80211=y CONFIG_WIRELESS_EXT=y CONFIG_MAC80211=m # # QoS/HT support disabled # # # QoS/HT support needs CONFIG_NET_SCHED # # # Rate control algorithm selection # CONFIG_MAC80211_RC_DEFAULT_PID=y # CONFIG_MAC80211_RC_DEFAULT_NONE is not set # # Selecting 'y' for an algorithm will # # # build the algorithm into mac80211. # CONFIG_MAC80211_RC_DEFAULT="pid" CONFIG_MAC80211_RC_PID=y # CONFIG_MAC80211_MESH is not set # CONFIG_MAC80211_LEDS is not set # CONFIG_MAC80211_DEBUGFS is not set # CONFIG_MAC80211_DEBUG_PACKET_ALIGNMENT is not set # CONFIG_MAC80211_DEBUG is not set CONFIG_IEEE80211=m # CONFIG_IEEE80211_DEBUG is not set CONFIG_IEEE80211_CRYPT_WEP=m CONFIG_IEEE80211_CRYPT_CCMP=m # CONFIG_IEEE80211_CRYPT_TKIP is not set CONFIG_RFKILL=m CONFIG_RFKILL_INPUT=m CONFIG_RFKILL_LEDS=y # CONFIG_NET_9P is not set # # Device Drivers # # # Generic Driver Options # CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" # CONFIG_STANDALONE is not set CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y CONFIG_BUILTIN_FIRMWARE="" # CONFIG_DEBUG_DRIVER is not set # CONFIG_DEBUG_DEVRES is not set # CONFIG_SYS_HYPERVISOR is not set # CONFIG_CONNECTOR is not set # CONFIG_MTD is not set # CONFIG_PARPORT is not set CONFIG_PNP=y # CONFIG_PNP_DEBUG is not set # # Protocols # CONFIG_PNPACPI=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_FD=y # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=y # CONFIG_BLK_DEV_CRYPTOLOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_SX8 is not set # CONFIG_BLK_DEV_UB is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=4096 # CONFIG_BLK_DEV_XIP is not set # CONFIG_CDROM_PKTCDVD is not set # CONFIG_ATA_OVER_ETH is not set CONFIG_MISC_DEVICES=y # CONFIG_IBM_ASM is not set # CONFIG_PHANTOM is not set # CONFIG_EEPROM_93CX6 is not set # CONFIG_SGI_IOC4 is not set # CONFIG_TIFM_CORE is not set CONFIG_ACER_WMI=m CONFIG_ASUS_LAPTOP=m CONFIG_FUJITSU_LAPTOP=m # CONFIG_FUJITSU_LAPTOP_DEBUG is not set CONFIG_MSI_LAPTOP=m CONFIG_COMPAL_LAPTOP=m CONFIG_SONY_LAPTOP=m CONFIG_SONYPI_COMPAT=y CONFIG_THINKPAD_ACPI=m # CONFIG_THINKPAD_ACPI_DEBUG is not set CONFIG_THINKPAD_ACPI_BAY=y CONFIG_THINKPAD_ACPI_VIDEO=y CONFIG_THINKPAD_ACPI_HOTKEY_POLL=y CONFIG_INTEL_MENLOW=m CONFIG_EEEPC_LAPTOP=m CONFIG_ENCLOSURE_SERVICES=m CONFIG_HAVE_IDE=y CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide/ide.txt for help/info on IDE drives # CONFIG_IDE_TIMINGS=y # CONFIG_BLK_DEV_IDE_SATA is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y # CONFIG_BLK_DEV_IDECS is not set # CONFIG_BLK_DEV_DELKIN is not set CONFIG_BLK_DEV_IDECD=y CONFIG_BLK_DEV_IDECD_VERBOSE_ERRORS=y # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set CONFIG_BLK_DEV_IDEACPI=y # CONFIG_IDE_TASK_IOCTL is not set CONFIG_IDE_PROC_FS=y # # IDE chipset support/bugfixes # CONFIG_IDE_GENERIC=y # CONFIG_BLK_DEV_PLATFORM is not set # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_BLK_DEV_IDEPNP is not set CONFIG_BLK_DEV_IDEDMA_SFF=y # # PCI IDE chipsets support # CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_PCIBUS_ORDER=y # CONFIG_BLK_DEV_OFFBOARD is not set # CONFIG_BLK_DEV_GENERIC is not set # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set CONFIG_BLK_DEV_AMD74XX=y CONFIG_BLK_DEV_ATIIXP=y # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_TRIFLEX is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5520 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_BLK_DEV_HPT366 is not set # CONFIG_BLK_DEV_JMICRON is not set # CONFIG_BLK_DEV_SC1200 is not set CONFIG_BLK_DEV_PIIX=y # CONFIG_BLK_DEV_IT8213 is not set # CONFIG_BLK_DEV_IT821X is not set # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_PDC202XX_OLD is not set CONFIG_BLK_DEV_PDC202XX_NEW=y # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set # CONFIG_BLK_DEV_VIA82CXXX is not set # CONFIG_BLK_DEV_TC86C001 is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_BLK_DEV_HD_ONLY is not set # CONFIG_BLK_DEV_HD is not set # # SCSI device support # # CONFIG_RAID_ATTRS is not set CONFIG_SCSI=y CONFIG_SCSI_DMA=y # CONFIG_SCSI_TGT is not set CONFIG_SCSI_NETLINK=y # CONFIG_SCSI_PROC_FS is not set # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=y # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_CHR_DEV_SG=y # CONFIG_CHR_DEV_SCH is not set # CONFIG_SCSI_ENCLOSURE is not set # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set CONFIG_SCSI_CONSTANTS=y # CONFIG_SCSI_LOGGING is not set # CONFIG_SCSI_SCAN_ASYNC is not set CONFIG_SCSI_WAIT_SCAN=m # # SCSI Transports # CONFIG_SCSI_SPI_ATTRS=y CONFIG_SCSI_FC_ATTRS=y # CONFIG_SCSI_ISCSI_ATTRS is not set # CONFIG_SCSI_SAS_LIBSAS is not set # CONFIG_SCSI_SRP_ATTRS is not set CONFIG_SCSI_LOWLEVEL=y # CONFIG_ISCSI_TCP is not set # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_3W_9XXX is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set CONFIG_SCSI_AIC79XX=y CONFIG_AIC79XX_CMDS_PER_DEVICE=32 CONFIG_AIC79XX_RESET_DELAY_MS=4000 # CONFIG_AIC79XX_DEBUG_ENABLE is not set CONFIG_AIC79XX_DEBUG_MASK=0 # CONFIG_AIC79XX_REG_PRETTY_PRINT is not set # CONFIG_SCSI_AIC94XX is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_ARCMSR is not set # CONFIG_MEGARAID_NEWGEN is not set # CONFIG_MEGARAID_LEGACY is not set # CONFIG_MEGARAID_SAS is not set # CONFIG_SCSI_HPTIOP is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_MVSAS is not set # CONFIG_SCSI_STEX is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_IPR is not set # CONFIG_SCSI_QLOGIC_1280 is not set # CONFIG_SCSI_QLA_FC is not set # CONFIG_SCSI_QLA_ISCSI is not set # CONFIG_SCSI_LPFC is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_DEBUG is not set # CONFIG_SCSI_SRP is not set # CONFIG_SCSI_LOWLEVEL_PCMCIA is not set # CONFIG_SCSI_DH is not set CONFIG_ATA=y # CONFIG_ATA_NONSTANDARD is not set CONFIG_ATA_ACPI=y CONFIG_SATA_PMP=y CONFIG_SATA_AHCI=y # CONFIG_SATA_SIL24 is not set CONFIG_ATA_SFF=y CONFIG_SATA_SVW=y CONFIG_ATA_PIIX=y # CONFIG_SATA_MV is not set CONFIG_SATA_NV=y # CONFIG_PDC_ADMA is not set # CONFIG_SATA_QSTOR is not set # CONFIG_SATA_PROMISE is not set # CONFIG_SATA_SX4 is not set CONFIG_SATA_SIL=y # CONFIG_SATA_SIS is not set # CONFIG_SATA_ULI is not set CONFIG_SATA_VIA=y # CONFIG_SATA_VITESSE is not set # CONFIG_SATA_INIC162X is not set CONFIG_PATA_ACPI=m # CONFIG_PATA_ALI is not set # CONFIG_PATA_AMD is not set # CONFIG_PATA_ARTOP is not set # CONFIG_PATA_ATIIXP is not set # CONFIG_PATA_CMD640_PCI is not set # CONFIG_PATA_CMD64X is not set # CONFIG_PATA_CS5520 is not set # CONFIG_PATA_CS5530 is not set # CONFIG_PATA_CYPRESS is not set # CONFIG_PATA_EFAR is not set # CONFIG_ATA_GENERIC is not set # CONFIG_PATA_HPT366 is not set # CONFIG_PATA_HPT37X is not set # CONFIG_PATA_HPT3X2N is not set # CONFIG_PATA_HPT3X3 is not set # CONFIG_PATA_IT821X is not set # CONFIG_PATA_IT8213 is not set # CONFIG_PATA_JMICRON is not set # CONFIG_PATA_TRIFLEX is not set # CONFIG_PATA_MARVELL is not set # CONFIG_PATA_MPIIX is not set # CONFIG_PATA_OLDPIIX is not set # CONFIG_PATA_NETCELL is not set # CONFIG_PATA_NINJA32 is not set # CONFIG_PATA_NS87410 is not set # CONFIG_PATA_NS87415 is not set # CONFIG_PATA_OPTI is not set # CONFIG_PATA_OPTIDMA is not set # CONFIG_PATA_PCMCIA is not set # CONFIG_PATA_PDC_OLD is not set # CONFIG_PATA_RADISYS is not set # CONFIG_PATA_RZ1000 is not set # CONFIG_PATA_SC1200 is not set # CONFIG_PATA_SERVERWORKS is not set # CONFIG_PATA_PDC2027X is not set # CONFIG_PATA_SIL680 is not set # CONFIG_PATA_SIS is not set # CONFIG_PATA_VIA is not set # CONFIG_PATA_WINBOND is not set CONFIG_PATA_SCH=m # CONFIG_MD is not set # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support # # CONFIG_FIREWIRE is not set CONFIG_IEEE1394=y # # Subsystem Options # # CONFIG_IEEE1394_VERBOSEDEBUG is not set # # Controllers # # CONFIG_IEEE1394_PCILYNX is not set CONFIG_IEEE1394_OHCI1394=y # # Protocols # # CONFIG_IEEE1394_VIDEO1394 is not set # CONFIG_IEEE1394_SBP2 is not set # CONFIG_IEEE1394_ETH1394_ROM_ENTRY is not set # CONFIG_IEEE1394_ETH1394 is not set # CONFIG_IEEE1394_DV1394 is not set CONFIG_IEEE1394_RAWIO=y # CONFIG_I2O is not set # CONFIG_MACINTOSH_DRIVERS is not set CONFIG_NETDEVICES=y CONFIG_NETDEVICES_MULTIQUEUE=y # CONFIG_DUMMY is not set # CONFIG_BONDING is not set # CONFIG_MACVLAN is not set # CONFIG_EQUALIZER is not set CONFIG_TUN=y # CONFIG_VETH is not set # CONFIG_NET_SB1000 is not set # CONFIG_ARCNET is not set CONFIG_PHYLIB=y # # MII PHY device drivers # # CONFIG_MARVELL_PHY is not set # CONFIG_DAVICOM_PHY is not set # CONFIG_QSEMI_PHY is not set # CONFIG_LXT_PHY is not set # CONFIG_CICADA_PHY is not set # CONFIG_VITESSE_PHY is not set # CONFIG_SMSC_PHY is not set # CONFIG_BROADCOM_PHY is not set # CONFIG_ICPLUS_PHY is not set # CONFIG_REALTEK_PHY is not set # CONFIG_FIXED_PHY is not set # CONFIG_MDIO_BITBANG is not set CONFIG_NET_ETHERNET=y CONFIG_MII=y # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set # CONFIG_CASSINI is not set CONFIG_NET_VENDOR_3COM=y CONFIG_VORTEX=y # CONFIG_TYPHOON is not set CONFIG_NET_TULIP=y # CONFIG_DE2104X is not set CONFIG_TULIP=y # CONFIG_TULIP_MWI is not set # CONFIG_TULIP_MMIO is not set # CONFIG_TULIP_NAPI is not set # CONFIG_DE4X5 is not set # CONFIG_WINBOND_840 is not set # CONFIG_DM9102 is not set # CONFIG_ULI526X is not set # CONFIG_PCMCIA_XIRCOM is not set # CONFIG_HP100 is not set # CONFIG_IBM_NEW_EMAC_ZMII is not set # CONFIG_IBM_NEW_EMAC_RGMII is not set # CONFIG_IBM_NEW_EMAC_TAH is not set # CONFIG_IBM_NEW_EMAC_EMAC4 is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_AMD8111_ETH is not set # CONFIG_ADAPTEC_STARFIRE is not set CONFIG_B44=y CONFIG_B44_PCI_AUTOSELECT=y CONFIG_B44_PCICORE_AUTOSELECT=y CONFIG_B44_PCI=y CONFIG_FORCEDETH=y # CONFIG_FORCEDETH_NAPI is not set # CONFIG_EEPRO100 is not set CONFIG_E100=y # CONFIG_E100_FIRMWARE is not set # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set CONFIG_8139CP=y CONFIG_8139TOO=y # CONFIG_8139TOO_PIO is not set # CONFIG_8139TOO_TUNE_TWISTER is not set # CONFIG_8139TOO_8129 is not set # CONFIG_8139_OLD_RX_RESET is not set # CONFIG_R6040 is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # CONFIG_SC92031 is not set CONFIG_NETDEV_1000=y # CONFIG_ACENIC is not set # CONFIG_DL2K is not set CONFIG_E1000=y # CONFIG_E1000_NAPI is not set # CONFIG_E1000_DISABLE_PACKET_SPLIT is not set CONFIG_E1000E=m CONFIG_E1000E_ENABLED=y # CONFIG_IP1000 is not set CONFIG_IGB=m # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set # CONFIG_SIS190 is not set # CONFIG_SKGE is not set # CONFIG_SKY2 is not set # CONFIG_VIA_VELOCITY is not set CONFIG_TIGON3=y CONFIG_BNX2=y # CONFIG_QLA3XXX is not set # CONFIG_ATL1 is not set CONFIG_NETDEV_10000=y # CONFIG_CHELSIO_T1 is not set # CONFIG_CHELSIO_T3 is not set CONFIG_IXGBE=m # CONFIG_IXGB is not set # CONFIG_S2IO is not set # CONFIG_MYRI10GE is not set # CONFIG_NETXEN_NIC is not set # CONFIG_NIU is not set # CONFIG_MLX4_CORE is not set # CONFIG_TEHUTI is not set # CONFIG_BNX2X is not set # CONFIG_SFC is not set # CONFIG_TR is not set # # Wireless LAN # # CONFIG_WLAN_PRE80211 is not set CONFIG_WLAN_80211=y # CONFIG_PCMCIA_RAYCS is not set CONFIG_IPW2100=m # CONFIG_IPW2100_MONITOR is not set # CONFIG_IPW2100_DEBUG is not set CONFIG_IPW2200=m # CONFIG_IPW2200_MONITOR is not set # CONFIG_IPW2200_QOS is not set # CONFIG_IPW2200_DEBUG is not set # CONFIG_LIBERTAS is not set # CONFIG_AIRO is not set # CONFIG_HERMES is not set # CONFIG_ATMEL is not set # CONFIG_AIRO_CS is not set # CONFIG_PCMCIA_WL3501 is not set CONFIG_PRISM54=m # CONFIG_USB_ZD1201 is not set # CONFIG_USB_NET_RNDIS_WLAN is not set # CONFIG_RTL8180 is not set # CONFIG_RTL8187 is not set # CONFIG_ADM8211 is not set # CONFIG_MAC80211_HWSIM is not set # CONFIG_P54_COMMON is not set # CONFIG_ATH5K is not set CONFIG_IWLWIFI=m CONFIG_IWLCORE=m # CONFIG_IWLWIFI_LEDS is not set # CONFIG_IWLWIFI_RFKILL is not set CONFIG_IWL4965=m # CONFIG_IWL4965_LEDS is not set # CONFIG_IWL4965_SPECTRUM_MEASUREMENT is not set # CONFIG_IWLWIFI_DEBUG is not set # CONFIG_IWL5000 is not set CONFIG_IWL3945=m # CONFIG_IWL3945_SPECTRUM_MEASUREMENT is not set # CONFIG_IWL3945_LEDS is not set # CONFIG_IWL3945_DEBUG is not set # CONFIG_HOSTAP is not set # CONFIG_B43 is not set # CONFIG_B43LEGACY is not set # CONFIG_ZD1211RW is not set # CONFIG_RT2X00 is not set # # USB Network Adapters # # CONFIG_USB_CATC is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_USBNET is not set # CONFIG_USB_HSO is not set # CONFIG_NET_PCMCIA is not set # CONFIG_WAN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set # CONFIG_NET_FC is not set CONFIG_NETCONSOLE=y # CONFIG_NETCONSOLE_DYNAMIC is not set CONFIG_NETPOLL=y # CONFIG_NETPOLL_TRAP is not set CONFIG_NET_POLL_CONTROLLER=y # CONFIG_ISDN is not set # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # CONFIG_INPUT_FF_MEMLESS is not set # CONFIG_INPUT_POLLDEV is not set # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set CONFIG_INPUT_EVDEV=y # CONFIG_INPUT_EVBUG is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set # CONFIG_KEYBOARD_STOWAWAY is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y CONFIG_MOUSE_PS2_ALPS=y CONFIG_MOUSE_PS2_LOGIPS2PP=y CONFIG_MOUSE_PS2_SYNAPTICS=y CONFIG_MOUSE_PS2_LIFEBOOK=y CONFIG_MOUSE_PS2_TRACKPOINT=y # CONFIG_MOUSE_PS2_TOUCHKIT is not set # CONFIG_MOUSE_SERIAL is not set # CONFIG_MOUSE_APPLETOUCH is not set # CONFIG_MOUSE_VSXXXAA is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TABLET is not set # CONFIG_INPUT_TOUCHSCREEN is not set # CONFIG_INPUT_MISC is not set # # Hardware I/O ports # CONFIG_SERIO=y CONFIG_SERIO_I8042=y # CONFIG_SERIO_SERPORT is not set # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PCIPS2 is not set CONFIG_SERIO_LIBPS2=y # CONFIG_SERIO_RAW is not set # CONFIG_GAMEPORT is not set # # Character devices # CONFIG_VT=y CONFIG_CONSOLE_TRANSLATIONS=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_VT_HW_CONSOLE_BINDING is not set CONFIG_DEVKMEM=y # CONFIG_SERIAL_NONSTANDARD is not set # CONFIG_NOZOMI is not set # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_SERIAL_8250_PCI=y CONFIG_SERIAL_8250_PNP=y # CONFIG_SERIAL_8250_CS is not set CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 # CONFIG_SERIAL_8250_EXTENDED is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y # CONFIG_SERIAL_JSM is not set CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 # CONFIG_IPMI_HANDLER is not set CONFIG_HW_RANDOM=y CONFIG_HW_RANDOM_INTEL=y CONFIG_HW_RANDOM_AMD=y CONFIG_NVRAM=m # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # # PCMCIA character devices # # CONFIG_SYNCLINK_CS is not set # CONFIG_CARDMAN_4000 is not set # CONFIG_CARDMAN_4040 is not set # CONFIG_IPWIRELESS is not set # CONFIG_MWAVE is not set # CONFIG_PC8736x_GPIO is not set CONFIG_RAW_DRIVER=y CONFIG_MAX_RAW_DEVS=256 CONFIG_HPET=y CONFIG_HPET_MMAP=y # CONFIG_HANGCHECK_TIMER is not set # CONFIG_TCG_TPM is not set # CONFIG_TELCLOCK is not set CONFIG_DEVPORT=y CONFIG_I2C=m CONFIG_I2C_BOARDINFO=y CONFIG_I2C_CHARDEV=m # # I2C Hardware Bus support # # # PC SMBus host controller drivers # # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI1563 is not set # CONFIG_I2C_ALI15X3 is not set # CONFIG_I2C_AMD756 is not set # CONFIG_I2C_AMD8111 is not set # CONFIG_I2C_I801 is not set # CONFIG_I2C_PIIX4 is not set # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_SIS630 is not set # CONFIG_I2C_SIS96X is not set # CONFIG_I2C_VIA is not set # CONFIG_I2C_VIAPRO is not set # # Graphics adapter I2C/DDC channel drivers # # CONFIG_I2C_VOODOO3 is not set # # External I2C/SMBus adapter drivers # # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_TAOS_EVM is not set # CONFIG_I2C_TINY_USB is not set # # Other I2C/SMBus bus drivers # # CONFIG_I2C_ISCH is not set # CONFIG_I2C_OCORES is not set # CONFIG_I2C_SIMTEC is not set # CONFIG_I2C_STUB is not set # CONFIG_I2C_PCA_PLATFORM is not set # # Miscellaneous I2C Chip support # # CONFIG_DS1682 is not set # CONFIG_SENSORS_EEPROM is not set # CONFIG_SENSORS_PCF8574 is not set # CONFIG_PCF8575 is not set # CONFIG_SENSORS_PCA9539 is not set # CONFIG_SENSORS_PCF8591 is not set # CONFIG_SENSORS_MAX6875 is not set # CONFIG_SENSORS_TSL2550 is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_I2C_DEBUG_CHIP is not set # CONFIG_SPI is not set # CONFIG_W1 is not set CONFIG_POWER_SUPPLY=y CONFIG_POWER_SUPPLY_DEBUG=y # CONFIG_PDA_POWER is not set # CONFIG_BATTERY_DS2760 is not set CONFIG_HWMON=m CONFIG_HWMON_VID=m # CONFIG_SENSORS_ABITUGURU is not set # CONFIG_SENSORS_ABITUGURU3 is not set # CONFIG_SENSORS_AD7418 is not set # CONFIG_SENSORS_ADM1021 is not set # CONFIG_SENSORS_ADM1025 is not set # CONFIG_SENSORS_ADM1026 is not set # CONFIG_SENSORS_ADM1029 is not set # CONFIG_SENSORS_ADM1031 is not set # CONFIG_SENSORS_ADM9240 is not set # CONFIG_SENSORS_ADT7470 is not set # CONFIG_SENSORS_ADT7473 is not set # CONFIG_SENSORS_K8TEMP is not set # CONFIG_SENSORS_ASB100 is not set # CONFIG_SENSORS_ATXP1 is not set # CONFIG_SENSORS_DS1621 is not set CONFIG_SENSORS_I5K_AMB=m # CONFIG_SENSORS_F71805F is not set # CONFIG_SENSORS_F71882FG is not set # CONFIG_SENSORS_F75375S is not set # CONFIG_SENSORS_FSCHER is not set # CONFIG_SENSORS_FSCPOS is not set # CONFIG_SENSORS_FSCHMD is not set # CONFIG_SENSORS_GL518SM is not set # CONFIG_SENSORS_GL520SM is not set CONFIG_SENSORS_CORETEMP=m # CONFIG_SENSORS_IT87 is not set # CONFIG_SENSORS_LM63 is not set # CONFIG_SENSORS_LM75 is not set # CONFIG_SENSORS_LM77 is not set # CONFIG_SENSORS_LM78 is not set # CONFIG_SENSORS_LM80 is not set # CONFIG_SENSORS_LM83 is not set # CONFIG_SENSORS_LM85 is not set # CONFIG_SENSORS_LM87 is not set # CONFIG_SENSORS_LM90 is not set # CONFIG_SENSORS_LM92 is not set CONFIG_SENSORS_LM93=m # CONFIG_SENSORS_MAX1619 is not set # CONFIG_SENSORS_MAX6650 is not set # CONFIG_SENSORS_PC87360 is not set # CONFIG_SENSORS_PC87427 is not set # CONFIG_SENSORS_SIS5595 is not set # CONFIG_SENSORS_DME1737 is not set # CONFIG_SENSORS_SMSC47M1 is not set # CONFIG_SENSORS_SMSC47M192 is not set CONFIG_SENSORS_SMSC47B397=m # CONFIG_SENSORS_ADS7828 is not set # CONFIG_SENSORS_THMC50 is not set # CONFIG_SENSORS_VIA686A is not set # CONFIG_SENSORS_VT1211 is not set # CONFIG_SENSORS_VT8231 is not set # CONFIG_SENSORS_W83781D is not set # CONFIG_SENSORS_W83791D is not set # CONFIG_SENSORS_W83792D is not set # CONFIG_SENSORS_W83793 is not set # CONFIG_SENSORS_W83L785TS is not set # CONFIG_SENSORS_W83L786NG is not set # CONFIG_SENSORS_W83627HF is not set # CONFIG_SENSORS_W83627EHF is not set # CONFIG_SENSORS_HDAPS is not set # CONFIG_SENSORS_APPLESMC is not set # CONFIG_HWMON_DEBUG_CHIP is not set CONFIG_THERMAL=y # CONFIG_WATCHDOG is not set # # Sonics Silicon Backplane # CONFIG_SSB_POSSIBLE=y CONFIG_SSB=y CONFIG_SSB_SPROM=y CONFIG_SSB_PCIHOST_POSSIBLE=y CONFIG_SSB_PCIHOST=y # CONFIG_SSB_B43_PCI_BRIDGE is not set # CONFIG_SSB_DEBUG is not set CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y CONFIG_SSB_DRIVER_PCICORE=y # # Multifunction device drivers # # CONFIG_MFD_SM501 is not set # CONFIG_HTC_PASIC3 is not set # # Multimedia devices # # # Multimedia core support # # CONFIG_VIDEO_DEV is not set # CONFIG_DVB_CORE is not set # CONFIG_VIDEO_MEDIA is not set # # Multimedia drivers # # CONFIG_DAB is not set # # Graphics support # CONFIG_AGP=y CONFIG_AGP_AMD64=y CONFIG_AGP_INTEL=m # CONFIG_AGP_SIS is not set # CONFIG_AGP_VIA is not set CONFIG_DRM=m # CONFIG_DRM_TDFX is not set # CONFIG_DRM_R128 is not set CONFIG_DRM_RADEON=m CONFIG_DRM_I810=m # CONFIG_DRM_I830 is not set CONFIG_DRM_I915=m CONFIG_DRM_MGA=m # CONFIG_DRM_SIS is not set # CONFIG_DRM_VIA is not set # CONFIG_DRM_SAVAGE is not set # CONFIG_VGASTATE is not set CONFIG_VIDEO_OUTPUT_CONTROL=y # CONFIG_FB is not set CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_LCD_CLASS_DEVICE=m CONFIG_BACKLIGHT_CLASS_DEVICE=m # CONFIG_BACKLIGHT_CORGI is not set # CONFIG_BACKLIGHT_PROGEAR is not set # CONFIG_BACKLIGHT_MBP_NVIDIA is not set # # Display device support # # CONFIG_DISPLAY_SUPPORT is not set # # Console display driver support # CONFIG_VGA_CONSOLE=y CONFIG_VGACON_SOFT_SCROLLBACK=y CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=256 CONFIG_VIDEO_SELECT=y CONFIG_DUMMY_CONSOLE=y CONFIG_SOUND=y CONFIG_SND=y CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_SEQUENCER=m # CONFIG_SND_SEQ_DUMMY is not set CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_PCM_OSS_PLUGINS=y # CONFIG_SND_SEQUENCER_OSS is not set # CONFIG_SND_DYNAMIC_MINORS is not set CONFIG_SND_SUPPORT_OLD_API=y CONFIG_SND_VERBOSE_PROCFS=y # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set CONFIG_SND_VMASTER=y CONFIG_SND_AC97_CODEC=m CONFIG_SND_DRIVERS=y # CONFIG_SND_PCSP is not set # CONFIG_SND_DUMMY is not set # CONFIG_SND_VIRMIDI is not set # CONFIG_SND_MTPAV is not set # CONFIG_SND_SERIAL_U16550 is not set # CONFIG_SND_MPU401 is not set CONFIG_SND_AC97_POWER_SAVE=y CONFIG_SND_AC97_POWER_SAVE_DEFAULT=5 CONFIG_SND_PCI=y # CONFIG_SND_AD1889 is not set # CONFIG_SND_ALS300 is not set # CONFIG_SND_ALS4000 is not set # CONFIG_SND_ALI5451 is not set CONFIG_SND_ATIIXP=m # CONFIG_SND_ATIIXP_MODEM is not set # CONFIG_SND_AU8810 is not set # CONFIG_SND_AU8820 is not set # CONFIG_SND_AU8830 is not set # CONFIG_SND_AW2 is not set # CONFIG_SND_AZT3328 is not set # CONFIG_SND_BT87X is not set # CONFIG_SND_CA0106 is not set # CONFIG_SND_CMIPCI is not set # CONFIG_SND_OXYGEN is not set # CONFIG_SND_CS4281 is not set # CONFIG_SND_CS46XX is not set # CONFIG_SND_CS5530 is not set # CONFIG_SND_DARLA20 is not set # CONFIG_SND_GINA20 is not set # CONFIG_SND_LAYLA20 is not set # CONFIG_SND_DARLA24 is not set # CONFIG_SND_GINA24 is not set # CONFIG_SND_LAYLA24 is not set # CONFIG_SND_MONA is not set # CONFIG_SND_MIA is not set # CONFIG_SND_ECHO3G is not set # CONFIG_SND_INDIGO is not set # CONFIG_SND_INDIGOIO is not set # CONFIG_SND_INDIGODJ is not set # CONFIG_SND_EMU10K1 is not set # CONFIG_SND_EMU10K1X is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set # CONFIG_SND_FM801 is not set CONFIG_SND_HDA_INTEL=m # CONFIG_SND_HDA_HWDEP is not set CONFIG_SND_HDA_CODEC_REALTEK=y CONFIG_SND_HDA_CODEC_ANALOG=y CONFIG_SND_HDA_CODEC_SIGMATEL=y CONFIG_SND_HDA_CODEC_VIA=y CONFIG_SND_HDA_CODEC_ATIHDMI=y CONFIG_SND_HDA_CODEC_CONEXANT=y CONFIG_SND_HDA_CODEC_CMEDIA=y CONFIG_SND_HDA_CODEC_SI3054=y CONFIG_SND_HDA_GENERIC=y CONFIG_SND_HDA_POWER_SAVE=y CONFIG_SND_HDA_POWER_SAVE_DEFAULT=5 # CONFIG_SND_HDSP is not set # CONFIG_SND_HDSPM is not set # CONFIG_SND_HIFIER is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_ICE1724 is not set CONFIG_SND_INTEL8X0=m # CONFIG_SND_INTEL8X0M is not set # CONFIG_SND_KORG1212 is not set # CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_MIXART is not set # CONFIG_SND_NM256 is not set # CONFIG_SND_PCXHR is not set # CONFIG_SND_RIPTIDE is not set # CONFIG_SND_RME32 is not set # CONFIG_SND_RME96 is not set # CONFIG_SND_RME9652 is not set # CONFIG_SND_SONICVIBES is not set # CONFIG_SND_TRIDENT is not set # CONFIG_SND_VIA82XX is not set # CONFIG_SND_VIA82XX_MODEM is not set # CONFIG_SND_VIRTUOSO is not set # CONFIG_SND_VX222 is not set # CONFIG_SND_YMFPCI is not set CONFIG_SND_USB=y # CONFIG_SND_USB_AUDIO is not set # CONFIG_SND_USB_USX2Y is not set # CONFIG_SND_USB_CAIAQ is not set CONFIG_SND_PCMCIA=y # CONFIG_SND_VXPOCKET is not set # CONFIG_SND_PDAUDIOCF is not set # CONFIG_SND_SOC is not set # CONFIG_SOUND_PRIME is not set CONFIG_AC97_BUS=m CONFIG_HID_SUPPORT=y CONFIG_HID=y # CONFIG_HID_DEBUG is not set # CONFIG_HIDRAW is not set # # USB Input Devices # CONFIG_USB_HID=y # CONFIG_USB_HIDINPUT_POWERBOOK is not set # CONFIG_HID_FF is not set # CONFIG_USB_HIDDEV is not set CONFIG_USB_SUPPORT=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB_ARCH_HAS_EHCI=y CONFIG_USB=y # CONFIG_USB_DEBUG is not set CONFIG_USB_ANNOUNCE_NEW_DEVICES=y # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_DEVICE_CLASS is not set # CONFIG_USB_DYNAMIC_MINORS is not set CONFIG_USB_SUSPEND=y # CONFIG_USB_OTG is not set # CONFIG_USB_WUSB is not set # # USB Host Controller Drivers # # CONFIG_USB_C67X00_HCD is not set CONFIG_USB_EHCI_HCD=y # CONFIG_USB_EHCI_ROOT_HUB_TT is not set # CONFIG_USB_EHCI_TT_NEWSCHED is not set # CONFIG_USB_ISP116X_HCD is not set # CONFIG_USB_ISP1760_HCD is not set CONFIG_USB_OHCI_HCD=y # CONFIG_USB_OHCI_HCD_SSB is not set # CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set # CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set CONFIG_USB_OHCI_LITTLE_ENDIAN=y CONFIG_USB_UHCI_HCD=y # CONFIG_USB_SL811_HCD is not set # CONFIG_USB_R8A66597_HCD is not set # CONFIG_USB_WHCI_HCD is not set # CONFIG_USB_HWA_HCD is not set # # USB Device Class drivers # # CONFIG_USB_ACM is not set # CONFIG_USB_PRINTER is not set # CONFIG_USB_WDM is not set # # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' # # # may also be needed; see USB_STORAGE Help for more information # CONFIG_USB_STORAGE=y # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_DPCM is not set # CONFIG_USB_STORAGE_USBAT is not set # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # CONFIG_USB_STORAGE_ALAUDA is not set # CONFIG_USB_STORAGE_ONETOUCH is not set # CONFIG_USB_STORAGE_KARMA is not set # CONFIG_USB_STORAGE_CYPRESS_ATACB is not set # CONFIG_USB_LIBUSUAL is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # CONFIG_USB_MICROTEK is not set # CONFIG_USB_MON is not set # # USB port drivers # # CONFIG_USB_SERIAL is not set # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_ADUTUX is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_BERRY_CHARGE is not set # CONFIG_USB_LED is not set # CONFIG_USB_CYPRESS_CY7C63 is not set # CONFIG_USB_CYTHERM is not set # CONFIG_USB_PHIDGET is not set # CONFIG_USB_IDMOUSE is not set # CONFIG_USB_FTDI_ELAN is not set # CONFIG_USB_APPLEDISPLAY is not set # CONFIG_USB_SISUSBVGA is not set # CONFIG_USB_LD is not set # CONFIG_USB_TRANCEVIBRATOR is not set # CONFIG_USB_IOWARRIOR is not set # CONFIG_USB_TEST is not set # CONFIG_USB_ISIGHTFW is not set # CONFIG_USB_GOTEMP is not set # CONFIG_USB_GADGET is not set # CONFIG_UWB is not set # CONFIG_MMC is not set # CONFIG_MEMSTICK is not set CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=m # # LED drivers # # CONFIG_LEDS_PCA9532 is not set # CONFIG_LEDS_CLEVO_MAIL is not set # # LED Triggers # CONFIG_LEDS_TRIGGERS=y CONFIG_LEDS_TRIGGER_TIMER=m CONFIG_LEDS_TRIGGER_IDE_DISK=y CONFIG_LEDS_TRIGGER_HEARTBEAT=m # CONFIG_LEDS_TRIGGER_DEFAULT_ON is not set # CONFIG_ACCESSIBILITY is not set # CONFIG_INFINIBAND is not set # CONFIG_EDAC is not set CONFIG_RTC_LIB=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_HCTOSYS_DEVICE="rtc0" # CONFIG_RTC_DEBUG is not set # # RTC interfaces # CONFIG_RTC_INTF_SYSFS=y # CONFIG_RTC_INTF_PROC is not set # CONFIG_RTC_INTF_DEV is not set CONFIG_RTC_DRV_TEST=m # # I2C RTC drivers # # CONFIG_RTC_DRV_DS1307 is not set # CONFIG_RTC_DRV_DS1374 is not set # CONFIG_RTC_DRV_DS1672 is not set # CONFIG_RTC_DRV_MAX6900 is not set # CONFIG_RTC_DRV_RS5C372 is not set # CONFIG_RTC_DRV_ISL1208 is not set # CONFIG_RTC_DRV_X1205 is not set # CONFIG_RTC_DRV_PCF8563 is not set # CONFIG_RTC_DRV_PCF8583 is not set # CONFIG_RTC_DRV_M41T80 is not set # CONFIG_RTC_DRV_S35390A is not set # CONFIG_RTC_DRV_FM3130 is not set # # SPI RTC drivers # # # Platform RTC drivers # # CONFIG_RTC_DRV_CMOS is not set # CONFIG_RTC_DRV_DS1511 is not set # CONFIG_RTC_DRV_DS1553 is not set # CONFIG_RTC_DRV_DS1742 is not set # CONFIG_RTC_DRV_STK17TA8 is not set # CONFIG_RTC_DRV_M48T86 is not set # CONFIG_RTC_DRV_M48T59 is not set # CONFIG_RTC_DRV_V3020 is not set # # on-CPU RTC drivers # # CONFIG_DMADEVICES is not set # CONFIG_UIO is not set # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set CONFIG_DMIID=y # CONFIG_ISCSI_IBFT_FIND is not set # # File systems # CONFIG_EXT2_FS=y CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y # CONFIG_EXT2_FS_SECURITY is not set # CONFIG_EXT2_FS_XIP is not set CONFIG_EXT3_FS=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y # CONFIG_EXT3_FS_SECURITY is not set # CONFIG_EXT4DEV_FS is not set CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set CONFIG_FS_MBCACHE=y CONFIG_REISERFS_FS=y # CONFIG_REISERFS_CHECK is not set # CONFIG_REISERFS_PROC_INFO is not set CONFIG_REISERFS_FS_XATTR=y CONFIG_REISERFS_FS_POSIX_ACL=y # CONFIG_REISERFS_FS_SECURITY is not set # CONFIG_JFS_FS is not set CONFIG_FS_POSIX_ACL=y # CONFIG_XFS_FS is not set # CONFIG_GFS2_FS is not set # CONFIG_OCFS2_FS is not set CONFIG_DNOTIFY=y CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y # CONFIG_QUOTA is not set # CONFIG_AUTOFS_FS is not set CONFIG_AUTOFS4_FS=y # CONFIG_FUSE_FS is not set CONFIG_GENERIC_ACL=y # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=y CONFIG_JOLIET=y # CONFIG_ZISOFS is not set # CONFIG_UDF_FS is not set # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" # CONFIG_NTFS_FS is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_SYSCTL=y CONFIG_SYSFS=y CONFIG_TMPFS=y CONFIG_TMPFS_POSIX_ACL=y # CONFIG_HUGETLBFS is not set # CONFIG_HUGETLB_PAGE is not set # CONFIG_CONFIGFS_FS is not set # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_VXFS_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_ROMFS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=y CONFIG_NFS_V3=y # CONFIG_NFS_V3_ACL is not set # CONFIG_NFS_V4 is not set CONFIG_NFSD=y CONFIG_NFSD_V3=y # CONFIG_NFSD_V3_ACL is not set # CONFIG_NFSD_V4 is not set CONFIG_ROOT_NFS=y CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=y CONFIG_NFS_COMMON=y CONFIG_SUNRPC=y # CONFIG_SUNRPC_BIND34 is not set # CONFIG_RPCSEC_GSS_KRB5 is not set # CONFIG_RPCSEC_GSS_SPKM3 is not set # CONFIG_SMB_FS is not set # CONFIG_CIFS is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=y # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set CONFIG_NLS_ISO8859_15=y # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_UTF8=y # CONFIG_DLM is not set # # Kernel hacking # CONFIG_TRACE_IRQFLAGS_SUPPORT=y # CONFIG_PRINTK_TIME is not set CONFIG_ENABLE_WARN_DEPRECATED=y # CONFIG_ENABLE_MUST_CHECK is not set CONFIG_FRAME_WARN=2048 CONFIG_MAGIC_SYSRQ=y CONFIG_UNUSED_SYMBOLS=y CONFIG_DEBUG_FS=y # CONFIG_HEADERS_CHECK is not set CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_SHIRQ is not set CONFIG_DETECT_SOFTLOCKUP=y # CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0 CONFIG_SCHED_DEBUG=y CONFIG_SCHEDSTATS=y CONFIG_TIMER_STATS=y # CONFIG_DEBUG_OBJECTS is not set CONFIG_DEBUG_SLAB=y CONFIG_DEBUG_SLAB_LEAK=y # CONFIG_DEBUG_RT_MUTEXES is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_MUTEXES is not set # CONFIG_DEBUG_LOCK_ALLOC is not set # CONFIG_PROVE_LOCKING is not set # CONFIG_LOCK_STAT is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set CONFIG_STACKTRACE=y # CONFIG_DEBUG_KOBJECT is not set CONFIG_DEBUG_BUGVERBOSE=y # CONFIG_DEBUG_INFO is not set # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_WRITECOUNT is not set # CONFIG_DEBUG_LIST is not set # CONFIG_DEBUG_SG is not set CONFIG_FRAME_POINTER=y # CONFIG_BOOT_PRINTK_DELAY is not set # CONFIG_FAULT_INJECTION is not set CONFIG_LATENCYTOP=y CONFIG_HAVE_FTRACE=y CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_TRACING=y # CONFIG_FTRACE is not set # CONFIG_IRQSOFF_TRACER is not set # CONFIG_SYSPROF_TRACER is not set # CONFIG_SCHED_TRACER is not set # CONFIG_CONTEXT_SWITCH_TRACER is not set # CONFIG_FTRACE_STARTUP_TEST is not set # CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set # CONFIG_SAMPLES is not set CONFIG_HAVE_ARCH_KGDB=y # CONFIG_KGDB is not set # CONFIG_KERNEL_TESTS is not set # CONFIG_NONPROMISC_DEVMEM is not set CONFIG_EARLY_PRINTK=y CONFIG_DEBUG_STACKOVERFLOW=y # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUG_PAGEALLOC is not set # CONFIG_DEBUG_PER_CPU_MAPS is not set # CONFIG_X86_PTDUMP is not set # CONFIG_DEBUG_RODATA is not set # CONFIG_DIRECT_GBPAGES is not set # CONFIG_DEBUG_NX_TEST is not set CONFIG_X86_MPPARSE=y # CONFIG_IOMMU_DEBUG is not set CONFIG_MMIOTRACE_HOOKS=y CONFIG_MMIOTRACE=y # CONFIG_MMIOTRACE_TEST is not set CONFIG_IO_DELAY_TYPE_0X80=0 CONFIG_IO_DELAY_TYPE_0XED=1 CONFIG_IO_DELAY_TYPE_UDELAY=2 CONFIG_IO_DELAY_TYPE_NONE=3 CONFIG_IO_DELAY_0X80=y # CONFIG_IO_DELAY_0XED is not set # CONFIG_IO_DELAY_UDELAY is not set # CONFIG_IO_DELAY_NONE is not set CONFIG_DEFAULT_IO_DELAY_TYPE=0 CONFIG_DEBUG_BOOT_PARAMS=y # CONFIG_CPA_DEBUG is not set # # Security options # # CONFIG_KEYS is not set # CONFIG_SECURITY is not set # CONFIG_SECURITY_FILE_CAPABILITIES is not set CONFIG_CRYPTO=m # # Crypto core or helper # CONFIG_CRYPTO_ALGAPI=m CONFIG_CRYPTO_BLKCIPHER=m CONFIG_CRYPTO_MANAGER=m # CONFIG_CRYPTO_GF128MUL is not set # CONFIG_CRYPTO_NULL is not set # CONFIG_CRYPTO_CRYPTD is not set # CONFIG_CRYPTO_AUTHENC is not set # CONFIG_CRYPTO_TEST is not set # # Authenticated Encryption with Associated Data # # CONFIG_CRYPTO_CCM is not set # CONFIG_CRYPTO_GCM is not set # CONFIG_CRYPTO_SEQIV is not set # # Block modes # CONFIG_CRYPTO_CBC=m # CONFIG_CRYPTO_CTR is not set # CONFIG_CRYPTO_CTS is not set CONFIG_CRYPTO_ECB=m # CONFIG_CRYPTO_LRW is not set CONFIG_CRYPTO_PCBC=m # CONFIG_CRYPTO_XTS is not set # # Hash modes # # CONFIG_CRYPTO_HMAC is not set # CONFIG_CRYPTO_XCBC is not set # # Digest # # CONFIG_CRYPTO_CRC32C is not set # CONFIG_CRYPTO_MD4 is not set # CONFIG_CRYPTO_MD5 is not set CONFIG_CRYPTO_MICHAEL_MIC=m # CONFIG_CRYPTO_RMD128 is not set # CONFIG_CRYPTO_RMD160 is not set # CONFIG_CRYPTO_RMD256 is not set # CONFIG_CRYPTO_RMD320 is not set # CONFIG_CRYPTO_SHA1 is not set # CONFIG_CRYPTO_SHA256 is not set # CONFIG_CRYPTO_SHA512 is not set # CONFIG_CRYPTO_TGR192 is not set # CONFIG_CRYPTO_WP512 is not set # # Ciphers # CONFIG_CRYPTO_AES=m # CONFIG_CRYPTO_AES_X86_64 is not set # CONFIG_CRYPTO_ANUBIS is not set CONFIG_CRYPTO_ARC4=m # CONFIG_CRYPTO_BLOWFISH is not set # CONFIG_CRYPTO_CAMELLIA is not set # CONFIG_CRYPTO_CAST5 is not set # CONFIG_CRYPTO_CAST6 is not set # CONFIG_CRYPTO_DES is not set # CONFIG_CRYPTO_FCRYPT is not set # CONFIG_CRYPTO_KHAZAD is not set # CONFIG_CRYPTO_SALSA20 is not set # CONFIG_CRYPTO_SALSA20_X86_64 is not set # CONFIG_CRYPTO_SEED is not set # CONFIG_CRYPTO_SERPENT is not set # CONFIG_CRYPTO_TEA is not set # CONFIG_CRYPTO_TWOFISH is not set # CONFIG_CRYPTO_TWOFISH_X86_64 is not set # # Compression # # CONFIG_CRYPTO_DEFLATE is not set # CONFIG_CRYPTO_LZO is not set # CONFIG_CRYPTO_HW is not set CONFIG_HAVE_KVM=y # CONFIG_VIRTUALIZATION is not set # # Library routines # CONFIG_BITREVERSE=y CONFIG_GENERIC_FIND_FIRST_BIT=y CONFIG_GENERIC_FIND_NEXT_BIT=y # CONFIG_CRC_CCITT is not set # CONFIG_CRC16 is not set # CONFIG_CRC_ITU_T is not set CONFIG_CRC32=y # CONFIG_CRC7 is not set # CONFIG_LIBCRC32C is not set CONFIG_ZLIB_INFLATE=y CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y ^ permalink raw reply [flat|nested] 90+ messages in thread
end of thread, other threads:[~2008-07-08 20:31 UTC | newest] Thread overview: 90+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-06-13 13:22 linux-next: Tree for June 13 Stephen Rothwell 2008-06-13 17:13 ` linux-next: Tree for June 13 (XEN) Randy Dunlap 2008-06-13 22:16 ` Jeremy Fitzhardinge 2008-06-14 20:31 ` Jens Axboe 2008-06-14 23:13 ` Randy Dunlap 2008-06-15 6:11 ` Jeremy Fitzhardinge 2008-06-16 19:30 ` Jens Axboe 2008-06-16 20:40 ` Jeremy Fitzhardinge 2008-06-13 22:58 ` linux-next: Tree for June 13 (x86_64: panic) Randy Dunlap 2008-06-14 8:16 ` Stephen Rothwell 2008-06-14 23:15 ` Randy Dunlap 2008-06-15 16:33 ` linux-next: Tree for June 13 (soft lockup) Randy Dunlap 2008-06-15 18:31 ` linux-next: Tree for June 13 Rafael J. Wysocki [not found] ` <200806160314.49489.rjw@sisk.pl> 2008-06-16 2:45 ` linux-next: Tree for June 13: IO APIC breakage on HP nx6325 Maciej W. Rozycki 2008-06-16 13:39 ` Rafael J. Wysocki 2008-06-16 15:39 ` Maciej W. Rozycki 2008-06-16 22:38 ` Rafael J. Wysocki 2008-06-16 23:05 ` Rafael J. Wysocki 2008-06-17 7:12 ` Thomas Gleixner 2008-06-17 20:44 ` Rafael J. Wysocki 2008-06-17 22:19 ` Rafael J. Wysocki 2008-06-17 22:25 ` Rafael J. Wysocki 2008-06-18 8:02 ` Thomas Gleixner 2008-06-18 12:41 ` Thomas Gleixner 2008-06-18 14:37 ` Rafael J. Wysocki 2008-06-18 14:40 ` Rafael J. Wysocki 2008-06-18 15:29 ` Thomas Gleixner 2008-06-21 22:47 ` Rafael J. Wysocki 2008-06-18 13:15 ` Ingo Molnar 2008-06-18 13:14 ` Ingo Molnar 2008-06-17 20:59 ` Rafael J. Wysocki 2008-06-17 21:19 ` Maciej W. Rozycki 2008-06-17 21:38 ` Rafael J. Wysocki 2008-06-17 22:53 ` Rafael J. Wysocki 2008-06-18 4:02 ` Maciej W. Rozycki 2008-06-18 19:06 ` Cyrill Gorcunov 2008-06-18 22:36 ` Maciej W. Rozycki 2008-06-20 18:59 ` Cyrill Gorcunov 2008-06-20 20:44 ` Maciej W. Rozycki 2008-06-18 22:11 ` Rafael J. Wysocki 2008-06-18 23:39 ` Maciej W. Rozycki 2008-06-19 0:25 ` Rafael J. Wysocki 2008-06-20 0:35 ` Maciej W. Rozycki 2008-06-20 11:53 ` Rafael J. Wysocki 2008-06-20 11:57 ` Matthew Garrett 2008-06-20 12:22 ` Rafael J. Wysocki 2008-06-20 12:27 ` Matthew Garrett 2008-06-21 1:09 ` Maciej W. Rozycki 2008-06-21 1:40 ` Matthew Garrett 2008-06-21 2:41 ` Maciej W. Rozycki 2008-06-21 12:38 ` Matthew Garrett 2008-06-26 19:52 ` Rafael J. Wysocki 2008-06-27 0:06 ` Maciej W. Rozycki 2008-06-29 14:00 ` Rafael J. Wysocki 2008-06-29 19:05 ` Maciej W. Rozycki 2008-06-29 19:23 ` Rafael J. Wysocki 2008-06-29 19:56 ` Maciej W. Rozycki 2008-06-29 20:02 ` Ingo Molnar 2008-06-29 20:14 ` Maciej W. Rozycki 2008-06-29 23:06 ` Rafael J. Wysocki 2008-06-30 0:45 ` Andi Kleen 2008-06-30 0:47 ` Matthew Garrett 2008-06-30 1:39 ` Maciej W. Rozycki 2008-06-30 9:24 ` Andi Kleen 2008-07-02 1:19 ` Maciej W. Rozycki 2008-06-30 10:41 ` Rafael J. Wysocki 2008-07-02 1:48 ` Maciej W. Rozycki 2008-07-02 9:35 ` Andi Kleen 2008-06-29 22:59 ` Rafael J. Wysocki 2008-06-29 22:56 ` Rafael J. Wysocki 2008-06-30 1:00 ` Maciej W. Rozycki 2008-06-30 9:06 ` Matthew Garrett 2008-06-30 15:29 ` Maciej W. Rozycki 2008-06-30 15:35 ` Matthew Garrett 2008-06-29 19:23 ` Matthew Garrett 2008-06-29 19:31 ` Rafael J. Wysocki 2008-06-29 20:03 ` Maciej W. Rozycki 2008-06-29 20:07 ` Matthew Garrett 2008-06-29 20:16 ` Maciej W. Rozycki 2008-06-24 9:15 ` Pavel Machek 2008-06-26 8:37 ` Rafael J. Wysocki 2008-06-27 1:53 ` Maciej W. Rozycki 2008-07-08 12:48 ` Pavel Machek 2008-06-21 1:49 ` Maciej W. Rozycki 2008-06-19 9:35 ` Ingo Molnar 2008-06-19 18:17 ` Maciej W. Rozycki 2008-06-20 10:44 ` Ingo Molnar 2008-06-20 13:11 ` Thomas Gleixner 2008-06-20 20:56 ` Maciej W. Rozycki 2008-06-17 0:08 ` Len Brown
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).