Linux 2.6.19-rc4

Linux 2.6.19-rc4

[Linus Torvalds]

Another week, another -rc4.

Before I forget, I'd like to thank Adrian Bunk for his regressions 
listings, and ask people who are involved with those (both on the blamer 
and blamee sides) to follow them, and keep making sure that we get them 
resolved - if only by reminding people about the issues, and testing that 
things that are claimed to be resolved really are.

-rc4 is mostly some driver (scsi, and random smattering of other stuff) 
and architecture (avr32, power, arm, with some mips and x86 noise) 
updates, with various random fixes thrown in. The shortlog (appended) is 
about as descriptive as they get - nothing earth-shattering. Things do 
seem to be calming down, although I hope they do so even more for -rc5 if 
we want to have a timely release.

		Linus

---
Adrian Bunk (2):
      [SCSI] aic7xxx: cleanups
      [SCSI] aic79xx: make ahd_set_tags() static

Akinobu Mita (2):
      [WATCHDOG] sc1200wdt.c pnp unregister fix.
      isdn/gigaset: avoid cs->dev null pointer dereference

Al Viro (5):
      [IPV4] ipconfig: fix RARP ic_servaddr breakage
      uml: mconsole fixes
      IOC4 should depend on PCI
      missing include of dma-mapping.h
      missing includes of io.h

Alan Cox (3):
      intel fb: switch to pci_get API
      [SCSI] Switch fdomain to the pci_get API
      JMB 368 PATA detection

Alan Stern (1):
      workqueue: update kerneldoc

Albert Cahalan (1):
      fix i386 regparm=3 RT signal handlers on x86_64

Alexey Dobriyan (4):
      [SCSI] scsi_lib.c: use BUILD_BUG_ON
      CONFIG_PM=n slim: drivers/pcmcia/*
      i82092: wire up errors from pci_register_driver()
      cryptocop: double spin_lock_irqsave()

Amol Lad (3):
      drm: ioremap balanced with iounmap for drivers/char/drm
      [SCSI] drivers/scsi: Handcrafted MIN/MAX macro removal
      ioremap balanced with iounmap for drivers/pcmcia

Andrew Morton (5):
      vmlinux.lds: consolidate initcall sections
      drivers: wait for threaded probes between initcall levels
      ioc4_serial: irq flags fix
      uml: fix compilation options for USER_OBJS
      fix "sunrpc: fix refcounting problems in rpc servers"

Andrew Vasquez (5):
      [SCSI] Maintain module-parameter name consistency with qla2xxx/qla4xxx.
      [SCSI] qla2xxx: Check return value of sysfs_create_bin_file() usage.
      [SCSI] qla2xxx: Workaround D3 power-management issues.
      [SCSI] qla2xxx: Correct QUEUE_FULL handling.
      [SCSI] qla2xxx: Update version number to 8.01.07-k3.

Andrey Mirkin (1):
      [SCSI] megaraid_{mm,mbox}: 64-bit DMA capability fix

Andrey Panin (1):
      visws build fix

Anton Vorontsov (2):
      [ARM] 3897/1: corgi_bl fix module compiling
      [ARM] 3898/1: corgi_bl fix module loading

Arnd Bergmann (2):
      [POWERPC] spufs: fix another off-by-one bug in spufs_mbox_read
      [POWERPC] cell: update defconfig

Auke Kok (3):
      e1000: FIX: 82542 doesn't support WoL
      e1000: Increment version to 7.2.9-k4
      e100: account for closed interface when shutting down

Ben Nizette (1):
      AVR32: add io{read,write}{8,16,32}{be,} support

Benjamin Herrenschmidt (7):
      [POWERPC] Consolidate feature fixup code
      [POWERPC] Support nested cpu feature sections
      [POWERPC] Support feature fixups in vdso's
      [POWERPC] Support feature fixups in modules
      [POWERPC] Cell timebase bug workaround
      [POWERPC] Fix device_is_compatible() const warning
      [POWERPC] Fix CHRP platforms with only 8259

bibo,mao (1):
      fix efi_memory_present_wrapper()

Bruce Allan (1):
      e1000: FIX: fix wrong txdctl threshold bitmasks

Christophe Saout (1):
      Fix dmsetup table output change

Cornelia Huck (2):
      [S390] cio: css_probe_device() must be called enabled.
      [S390] cio: Make ccw_device_register() static.

Craig Hughes (1):
      [ARM] 3902/1: Enable GPIO81-84 on PXA255

Dave Jones (2):
      fix return code in error case.
      PCI: x86-64: mmconfig missing printk levels

David Brownell (1):
      pcmcia: at91_cf update

David Howells (1):
      VFS: Fix an error in unused dentry counting

David S. Miller (4):
      [ATM] horizon: read_bia() needs to be __devinit
      [SPARC64]: Fix central/FHC bus handling on Ex000 systems.
      [SPARC64]: Fix memory corruption in pci_4u_free_consistent().
      [SPARC]: Fix bus_id[] string overflow.

Dominik Brodowski (2):
      pcmcia: add more IDs to hostap_cs.c
      PCMCIA: fix __must_check warnings

Doug Maxey (1):
      [SCSI] qla4xxx: fix double printk on load

Dwayne Grant Mcconnell (1):
      [POWERPC] spufs: fix signal2 file to report signal2

Eiichiro Oiwa (1):
      PCI: fix pci_fixup_video as it blows up on sparc64

Eric Sandeen (2):
      jbd: journal_dirty_data re-check for unmapped buffers
      jbd2: journal_dirty_data re-check for unmapped buffers

Eric Sesterhenn (2):
      Remove unnecessary check in drivers/video/intelfb/intelfbhw.c
      [SCSI] lpfc: check before dereference in lpfc_ct.c

Eric W. Biederman (2):
      x86-64: Simplify the vector allocator.
      x86-64: Only look at per_cpu data for online cpus.

FUJITA Tomonori (1):
      [SCSI] replace u8 and u32 with __u8 and __u32 in scsi.h for user space

Gavin McCullagh (1):
      [TCP] H-TCP: fix integer overflow

Geert Uytterhoeven (1):
      m68k: consolidate initcall sections

Gerald Schaefer (1):
      [S390] Initialize interval value to 0.

Gerrit Renker (1):
      [DCCP]: Update documentation references.

Giridhar Pemmasani (2):
      __vmalloc with GFP_ATOMIC causes 'sleeping from invalid context'
      Fix GFP_HIGHMEM slab panic

Guennadi Liakhovetski (1):
      [SCSI] tmscsim: set max_sectors

Haavard Skinnemoen (7):
      AVR32: Minor Makefile cleanup
      AVR32: Silence some compile warnings
      AVR32: Don't try to iounmap P2 segment addresses
      AVR32: Fix oversize immediates in atomic.h
      AVR32: Implement and export __raw_{read,write}s[bwl]
      AVR32: Use __raw MMIO access for internal peripherals
      AVR32: Update defconfig

Hannes Reinecke (6):
      [SCSI] aic7xxx: Adjust .max_sectors
      [SCSI] scsi_debug: support REPORT TARGET PORT GROUPS
      [SCSI] aic79xx: Fixup external device reset
      [SCSI] aic79xx: set precompensation
      [SCSI] aic7xxx: Remove slave_destroy
      [SCSI] aic79xx: Print out signalling

Heiko Carstens (1):
      [S390] uaccess error handling.

Henne (3):
      [SCSI] Scsi_Cmnd convertion in sun3-driver
      [SCSI] Scsi_Cmnd conversion in qlogicfas408 driver
      [SCSI] fix typo in previous Scsi_Cmnd convertion in aic7xxx_old.c

Henrik Kretzschmar (3):
      [SCSI] Scsi_Cmnd conversion in psi240i driver
      [SCSI] convert ninja driver to struct scsi_cmnd
      [SCSI] fc4: Conversion to struct scsi_cmnd in fc4

Hugh Dickins (3):
      hugetlb: fix size=4G parsing
      hugetlb: fix prio_tree unit
      hugetlb: fix absurd HugePages_Rsvd

Jake Moilanen (1):
      [POWERPC] Add 970GX cputable entry

James Bottomley (1):
      [SCSI] add can_queue to host parameters

Jan Dittmer (1):
      Add missing space in module.c for taintskernel

Jeff Garzik (2):
      drm: fix error returns, sysfs error handling
      PCMCIA: handle sysfs, PCI errors

Jens Axboe (2):
      CFQ: use irq safe locking in cfq_cic_link()
      CFQ: bad locking in changed_ioprio()

Jes Sorensen (1):
      [SCSI] qla1280 bus reset typo

Jesper Juhl (1):
      silence 'make xmldocs' warning by adding missing description of 'raw' in nand_base.c:1485

Jesse Brandeburg (4):
      e1000: FIX: don't poke at manageability registers for incompatible adapters
      e1000: FIX: Disable Packet Split for non jumbo frames
      e1000: FIX: Don't limit descriptor size to 4kb for PCI-E adapters
      e1000: FIX: move length adjustment due to crc stripping disabled.

Jim Houston (1):
      time_adjust cleared before use

Jonathan McDowell (1):
      Export soc_common_drv_pcmcia_remove to allow modular PCMCIA.

Jun'ichi Nomura (2):
      fix bd_claim_by_kobject error handling
      clean up add_bd_holder()

Kai Makisara (1):
      [SCSI] st: Fixup -ENOMEDIUM

Karsten Wiese (1):
      PCI: Remove quirk_via_abnormal_poweroff

Kaustav Majumdar (1):
      pcmcia: update alloc_io_space for conflict checking for multifunction PC card

Keith Packard (1):
      Merge headphone and speaker volume controls for Panasonic R4 laptop

Kevin Hilman (1):
      [ARM] 3909/1: Disable UWIND_INFO for ARM (again)

Kristian Mueller (1):
      APM: URL of APM 1.2 specs has changed

Kristoffer Ericson (1):
      [ARM] 3914/1: [Jornada7xx] - Typo Fix in cpu-sa1110.c (b != B)

Lennert Buytenhek (1):
      [ARM] 3913/1: n2100: fix IRQ routing for second ethernet port

Linus Torvalds (2):
      Revert "r8169: mac address change support"
      Linux 2.6.19-rc4

Liu Dave-r63238 (1):
      [POWERPC] Fix the UCC rx/tx clock of QE

Manish Lachwani (1):
      [MIPS] Make SB1 cache flushes not to use on_each_cpu

Mark A. Greer (1):
      [POWERPC] Don't require execute perms on wrapper when building zImage.initrd

Martin Bligh (2):
      vmscan: Fix temp_priority race
      Use min of two prio settings in calculating distress for reclaim

Mel Gorman (1):
      Calculation fix for memory holes beyong the end of physical memory

Michael Holzheu (1):
      strstrip remove last blank fix

Michael Karcher (1):
      drm: savage: dev->agp_buffer_map is not initialized for AGP DMA on savages

Michael Reed (1):
      [SCSI] mptfc: stall eh handlers if resetting while rport blocked

Mike Christie (5):
      [SCSI] iscsi class: fix slab corruption during restart
      [SCSI] libiscsi: fix oops in connection create failure path
      [SCSI] libiscsi: fix missed iscsi_task_put in xmit error path
      [SCSI] libiscsi: fix aen support
      [SCSI] libiscsi: fix logout pdu processing

MUNEDA Takahiro (1):
      acpiphp: fix latch status

Neil Brown (1):
      sunrpc: fix refcounting problems in rpc servers

NeilBrown (3):
      md: fix bug where spares don't always get rebuilt properly when they become live
      md: simplify checking of available size when resizing an array
      md: fix up maintenance of ->degraded in multipath

Nick Piggin (1):
      mm: clean up pagecache allocation

Olaf Hering (1):
      [POWERPC] Fix hang in start_ldr if _end or _edata is unaligned

Oleg Nesterov (10):
      fill_tgid: fix task_struct leak and possible oops
      bacct_add_tsk: fix unsafe and wrong parent/group_leader dereference
      taskstats_tgid_free: fix usage
      taskstats_tgid_alloc: optimization
      taskstats: kill ->taskstats_lock in favor of ->siglock
      taskstats: don't use tasklist_lock
      fill_tgid: cleanup delays accounting
      taskstats: fix sk_buff leak
      taskstats: fix sk_buff size calculation
      xacct_add_tsk: fix pure theoretical ->mm use-after-free

Olof Johansson (1):
      [POWERPC] Make sure __cpu_preinit_ppc970 gets called on 970GX processors

Om Narasimhan (1):
      pcmcia: au1000_generic fix

Paolo 'Blaisorblade' Giarrusso (1):
      Fix "Remove the use of _syscallX macros in UML"

Patrick McHardy (4):
      [XFRM]: Fix xfrm_state accounting
      [NETFILTER]: Fix ip6_tables protocol bypass bug
      [NETFILTER]: Fix ip6_tables extension header bypass bug
      [CRYPTO] users: Select ECB/CBC where needed

Paul Mundt (1):
      [S390] sys_getcpu compat wrapper.

Pavel Emelianov (1):
      Fix potential OOPs in blkdev_open()

Peter Zijlstra (1):
      lockdep: annotate DECLARE_WAIT_QUEUE_HEAD

Ralf Baechle (11):
      [MIPS] Oprofile: fix on non-VSMP / non-SMTC SMP configurations.
      [MIPS] Oprofile: Fix MIPSxx counter number detection.
      [MIPS] SMTC: Make 8 the default number of processors.
      [MIPS] Wire up getcpu(2) and epoll_wait(2) syscalls.
      [MIPS] Ocelot G: Fix build error and numerous warnings.
      [MIPS] EMMA 2 / Markeins: Fix build wreckage due to genirq wreckage.
      [MIPS] EMMA 2 / Markeins: Formitting fixes split from actual address fixes.
      [MIPS] EMMA 2 / Markeins: Convert to name struct resource initialization.
      [MIPS] EMMA 2 / Markeins: struct resource takes physical addresses.
      [MIPS] JMR3927: Fixup another victim of the irq pt_regs cleanup.
      [MIPS] MIPS doesn't need compat_sys_getdents.

Ralph Wuerthner (1):
      [S390] Improve AP bus device removal.

Randy Dunlap (11):
      [SCSI] lpfc: fix printk format warning
      pcmcia/ds: driver layer error checking
      [BRIDGE]: correct print message typo
      ext4: fix printk format warnings
      md: fix printk format warnings, seen on powerpc64:
      ioc4: fix printk format warning
      cciss: fix printk format warning
      move SYS_HYPERVISOR inside the Generic Driver menu
      ndiswrapper: don't set the module->taints flags
      MTD: fix last kernel-doc warning
      docbook: make a filesystems book

Roland Scheidegger (1):
      drm: radeon: only allow specific type-3 packetss through verifier

Russell King (8):
      [ARM] Fix breakage in 7281c248f797723f66244b7ecef204620f664648
      [ARM] Comment out missing configuration symbols
      [ARM] Fix SMP irqflags support
      [ARM] Add realview SMP default configuration
      [ARM] Add __must_check to uaccess functions
      [ARM] Fix i2c-pxa slave mode support
      [ARM] Fix suspend oops caused by PXA2xx PCMCIA driver
      [ARM] Add KBUILD_IMAGE target support

Santiago Leon (1):
      [SCSI] ibmvscsi: correctly reenable CRQ

Satoru Takeuchi (1):
      cpu-hotplug: release `workqueue_mutex' properly on CPU hot-remove

Scott Wood (1):
      [POWERPC] IPIC: Fix spinlock recursion in set_irq_handler

Sergei Shtylyov (1):
      [MIPS] Au1xx0 code sets incorrect mips_hpt_frequency

Sergey Kononenko (1):
      [SCSI] aic94xx: Supermicro motherboards support

Sergey Vlasov (1):
      drivers/ide/pci/generic.c: add missing newline to the all-generic-ide message

Shaohua Li (1):
      PCI: reset pci device state to unknown state for resume

Srinivasa Ds (1):
      [POWERPC] Fix build breakage with CONFIG_PPC32

Stefan Richter (1):
      ieee1394: ohci1394: revert fail on error in suspend

Stephen Hemminger (1):
      [TCP] cubic: scaling error

Stephen Rothwell (2):
      [POWERPC] Simplify stolen time calculation
      Constify compat_get_bitmap argument

Swen Schillig (1):
      [SCSI] zfcp: initialize scsi_host_template.max_sectors with appropriate value

Takashi Ohmasa (2):
      [ARM] 3899/1: Fix the normalization of the denormal double precision number.
      [ARM] 3900/1: Fix VFP Division by Zero exception handling.

Tilman Sauerbeck (1):
      drm: mga: set dev_priv_size

Timur Tabi (1):
      [POWERPC] Fix spelling errors in ucc_fast.c and ucc_slow.c

Vasily Averin (1):
      missing unused dentry in prune_dcache()?

Yasunori Goto (1):
      memory hotplug: __GFP_NOWARN is better for __kmalloc_section_memmap()

Yoichi Yuasa (3):
      [MIPS] Fix warning about unused definition in c-sb1.c
      [MIPS] Au1000: Fix warning about unused variable.
      [MIPS] Fix return value of TXX9 SPI interrupt handler

Zang Roy-r61911 (1):
      [POWERPC] Fix compiler warning message on get_property call

Re: Linux 2.6.19-rc4

[Andrew Morton]

On Mon, 30 Oct 2006 20:27:17 -0800 (PST)
Linus Torvalds <torvalds@osdl.org> wrote:

> Jun'ichi Nomura (2):
>       fix bd_claim_by_kobject error handling
>       clean up add_bd_holder()

That didn't go so well.  I guess the below was intended, but I wonder if
we actually merged the correct patch?


From: Andrew Morton <akpm@osdl.org>

fs/block_dev.c: In function 'find_bd_holder':
fs/block_dev.c:666: warning: return makes integer from pointer without a cast
fs/block_dev.c:669: warning: return makes integer from pointer without a cast
fs/block_dev.c: In function 'add_bd_holder':
fs/block_dev.c:685: warning: unused variable 'tmp'
fs/block_dev.c: In function 'bd_claim_by_kobject':
fs/block_dev.c:773: warning: assignment makes pointer from integer without a cast

Cc: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---

 fs/block_dev.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff -puN fs/block_dev.c~find_bd_holder-fix fs/block_dev.c
--- a/fs/block_dev.c~find_bd_holder-fix
+++ a/fs/block_dev.c
@@ -656,7 +656,8 @@ static void free_bd_holder(struct bd_hol
  * If found, increment the reference count and return the pointer.
  * If not found, returns NULL.
  */
-static int find_bd_holder(struct block_device *bdev, struct bd_holder *bo)
+static struct bd_holder *find_bd_holder(struct block_device *bdev,
+					struct bd_holder *bo)
 {
 	struct bd_holder *tmp;
 
@@ -682,7 +683,6 @@ static int find_bd_holder(struct block_d
  */
 static int add_bd_holder(struct block_device *bdev, struct bd_holder *bo)
 {
-	struct bd_holder *tmp;
 	int ret;
 
 	if (!bo)
_

Re: Linux 2.6.19-rc4

[Jun'ichi Nomura]

Hi Andrew,

Andrew Morton wrote:
>>       clean up add_bd_holder()
> 
> That didn't go so well.  I guess the below was intended, but I wonder if
> we actually merged the correct patch?

Sorry for the silly mistake...
and thank you for fixing it up.
It is exactly what I intended.

Thanks,
-- 
Jun'ichi Nomura, NEC Corporation of America

Re: Linux 2.6.19-rc4: udev compatibility broken?

[Mark Lord]

[-- Attachment #1: Type: text/plain, Size: 301 bytes --]

>From dmesg at failed startup with -rc4 on a SLES10 installation:

>udevd[853]: init_udevd_socket: error getting socket: Address family not supported

Note that 2.6.19-rc3-git7 boots/runs fine on exact same setup,
with the exact same .config (attached).

This is SUSE EL 10, with udev-085-30.10.

??


[-- Attachment #2: dot_config --]
[-- Type: text/plain, Size: 45947 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.19-rc4
# Tue Oct 31 11:11:03 2006
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION="-ml"
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_IPC_NS is not set
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set
# CONFIG_UTS_NS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_CPUSETS is not set
# CONFIG_RELAY is not set
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y

#
# Block layer
#
CONFIG_BLOCK=y
CONFIG_LBD=y
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set

#
# 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"

#
# Processor type and features
#
CONFIG_SMP=y
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
CONFIG_MPENTIUM4=y
# 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_X86_GENERIC=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_NR_CPUS=2
# 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_PREEMPT_BKL is not set
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_MCE=y
# CONFIG_X86_MCE_NONFATAL is not set
CONFIG_X86_MCE_P4THERMAL=y
CONFIG_VM86=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
CONFIG_MICROCODE=m
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m

#
# Firmware Drivers
#
CONFIG_EDD=m
# CONFIG_EFI_VARS is not set
CONFIG_DELL_RBU=m
CONFIG_DCDBAS=m
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_HIGHMEM=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not set
# CONFIG_HIGHPTE is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_EFI=y
CONFIG_IRQBALANCE=y
CONFIG_BOOT_IOREMAP=y
CONFIG_REGPARM=y
# CONFIG_SECCOMP is not set
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
CONFIG_PHYSICAL_START=0x100000
# CONFIG_HOTPLUG_CPU is not set
CONFIG_COMPAT_VDSO=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
# CONFIG_PM_LEGACY is not set
# CONFIG_PM_DEBUG is not set
CONFIG_PM_SYSFS_DEPRECATED=y

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_AC=m
CONFIG_ACPI_BATTERY=m
CONFIG_ACPI_BUTTON=m
# CONFIG_ACPI_VIDEO is not set
# CONFIG_ACPI_HOTKEY is not set
CONFIG_ACPI_FAN=m
# CONFIG_ACPI_DOCK is not set
CONFIG_ACPI_PROCESSOR=m
CONFIG_ACPI_THERMAL=m
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_IBM 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_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not set
# CONFIG_ACPI_SBS is not set

#
# APM (Advanced Power Management) BIOS Support
#
# CONFIG_APM is not set

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=m
# CONFIG_CPU_FREQ_DEBUG is not set
# CONFIG_CPU_FREQ_STAT is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE 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=m
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m

#
# CPUFreq processor drivers
#
CONFIG_X86_ACPI_CPUFREQ=m
# CONFIG_X86_POWERNOW_K6 is not set
# CONFIG_X86_POWERNOW_K7 is not set
# CONFIG_X86_POWERNOW_K8 is not set
# CONFIG_X86_GX_SUSPMOD is not set
CONFIG_X86_SPEEDSTEP_CENTRINO=m
CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI=y
CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y
CONFIG_X86_SPEEDSTEP_ICH=m
CONFIG_X86_SPEEDSTEP_SMI=m
CONFIG_X86_P4_CLOCKMOD=m
# CONFIG_X86_CPUFREQ_NFORCE2 is not set
# CONFIG_X86_LONGRUN is not set
# CONFIG_X86_LONGHAUL is not set

#
# shared options
#
# CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set
CONFIG_X86_SPEEDSTEP_LIB=m
CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK=y

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
# CONFIG_PCIEPORTBUS is not set
# CONFIG_PCI_MSI is not set
# CONFIG_PCI_MULTITHREAD_PROBE is not set
# CONFIG_PCI_DEBUG is not set
# CONFIG_HT_IRQ is not set
CONFIG_ISA_DMA_API=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
CONFIG_SCx200=m
# CONFIG_SCx200HR_TIMER is not set

#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set

#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_MISC=m

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
# CONFIG_NETDEBUG is not set
CONFIG_PACKET=m
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=m
# CONFIG_XFRM_SUB_POLICY is not set
CONFIG_NET_KEY=m
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_MULTIPATH_CACHED is not set
CONFIG_IP_ROUTE_VERBOSE=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=m
CONFIG_NET_IPGRE=m
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=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=m
# 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_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_IPV6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETFILTER is not set

#
# DCCP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP is not set

#
# SCTP Configuration (EXPERIMENTAL)
#
CONFIG_IP_SCTP=m
# CONFIG_SCTP_DBG_MSG is not set
# CONFIG_SCTP_DBG_OBJCNT is not set
# CONFIG_SCTP_HMAC_NONE is not set
# CONFIG_SCTP_HMAC_SHA1 is not set
CONFIG_SCTP_HMAC_MD5=y

#
# TIPC Configuration (EXPERIMENTAL)
#
# 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_LLC=m
CONFIG_LLC2=m
# 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

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set

#
# Network testing
#
CONFIG_NET_PKTGEN=m
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_IEEE80211 is not set
CONFIG_FIB_RULES=y

#
# Device Drivers
#

#
# Generic Driver Options
#
# CONFIG_STANDALONE is not set
# CONFIG_PREVENT_FIRMWARE_BUILD is not set
CONFIG_FW_LOADER=m
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_SYS_HYPERVISOR is not set

#
# Connector - unified userspace <-> kernelspace linker
#
CONFIG_CONNECTOR=m

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set

#
# Protocols
#
CONFIG_ISAPNP=y
# CONFIG_PNPBIOS is not set
CONFIG_PNPACPI=y

#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_DEV_XD is not set
# 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=m
CONFIG_BLK_DEV_NBD=m
# 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=64000
CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
CONFIG_BLK_DEV_INITRD=y
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set

#
# Misc devices
#
# CONFIG_IBM_ASM is not set
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set

#
# ATA/ATAPI/MFM/RLL support
#
# CONFIG_IDE is not set

#
# SCSI device support
#
CONFIG_RAID_ATTRS=m
CONFIG_SCSI=y
# CONFIG_SCSI_NETLINK is not set
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=y
# CONFIG_BLK_DEV_SR_VENDOR is not set
CONFIG_CHR_DEV_SG=y
# CONFIG_CHR_DEV_SCH is not set

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=m
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
CONFIG_SCSI_SAS_ATTRS=m
CONFIG_SCSI_SAS_LIBSAS=m
# CONFIG_SCSI_SAS_LIBSAS_DEBUG is not set

#
# SCSI low-level drivers
#
# CONFIG_ISCSI_TCP is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 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 is not set
# CONFIG_SCSI_AIC94XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 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_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_STEX is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS 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_SYM53C416 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set

#
# Serial ATA (prod) and Parallel ATA (experimental) drivers
#
CONFIG_ATA=y
CONFIG_SATA_AHCI=m
# CONFIG_SATA_SVW is not set
CONFIG_ATA_PIIX=y
# CONFIG_SATA_MV is not set
# CONFIG_SATA_NV is not set
# 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 is not set
# CONFIG_SATA_SIL24 is not set
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_ULI is not set
# CONFIG_SATA_VIA is not set
# CONFIG_SATA_VITESSE is not set
# 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_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CS5535 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_ISAPNP is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_PATA_LEGACY is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_QDI 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

#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set

#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID10=m
CONFIG_MD_RAID456=m
CONFIG_MD_RAID5_RESHAPE=y
CONFIG_MD_MULTIPATH=m
# CONFIG_MD_FAULTY is not set
CONFIG_BLK_DEV_DM=m
# CONFIG_DM_DEBUG is not set
CONFIG_DM_CRYPT=m
CONFIG_DM_SNAPSHOT=m
CONFIG_DM_MIRROR=m
CONFIG_DM_ZERO=m
CONFIG_DM_MULTIPATH=m
CONFIG_DM_MULTIPATH_EMC=m

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
# CONFIG_FUSION_SPI is not set
# CONFIG_FUSION_FC is not set
# CONFIG_FUSION_SAS is not set

#
# IEEE 1394 (FireWire) support
#
CONFIG_IEEE1394=m

#
# Subsystem Options
#
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
CONFIG_IEEE1394_OUI_DB=y
CONFIG_IEEE1394_EXTRA_CONFIG_ROMS=y
CONFIG_IEEE1394_CONFIG_ROM_IP1394=y
CONFIG_IEEE1394_EXPORT_FULL_API=y

#
# Device Drivers
#
CONFIG_IEEE1394_PCILYNX=m
CONFIG_IEEE1394_OHCI1394=m

#
# Protocol Drivers
#
CONFIG_IEEE1394_VIDEO1394=m
CONFIG_IEEE1394_SBP2=m
# CONFIG_IEEE1394_SBP2_PHYS_DMA is not set
CONFIG_IEEE1394_ETH1394=m
CONFIG_IEEE1394_DV1394=m
CONFIG_IEEE1394_RAWIO=m

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Network device support
#
CONFIG_NETDEVICES=y
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=m
# CONFIG_NET_SB1000 is not set

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# PHY device support
#
# CONFIG_PHYLIB is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
# CONFIG_NET_PCI is not set

#
# Ethernet (1000 Mbit)
#
CONFIG_ACENIC=m
# CONFIG_ACENIC_OMIT_TIGON_I is not set
CONFIG_DL2K=m
CONFIG_E1000=m
CONFIG_E1000_NAPI=y
# CONFIG_E1000_DISABLE_PACKET_SPLIT is not set
CONFIG_NS83820=m
CONFIG_HAMACHI=m
CONFIG_YELLOWFIN=m
# CONFIG_R8169 is not set
CONFIG_SIS190=m
CONFIG_SKGE=m
CONFIG_SKY2=m
CONFIG_SK98LIN=m
CONFIG_TIGON3=m
CONFIG_BNX2=m
CONFIG_QLA3XXX=m

#
# Ethernet (10000 Mbit)
#
# CONFIG_CHELSIO_T1 is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set
# CONFIG_MYRI10GE is not set

#
# Token Ring devices
#
# CONFIG_TR is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Wan interfaces
#
# 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_SHAPER is not set
CONFIG_NETCONSOLE=m
CONFIG_NETPOLL=y
CONFIG_NETPOLL_RX=y
CONFIG_NETPOLL_TRAP=y
CONFIG_NET_POLL_CONTROLLER=y

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS 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_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
CONFIG_KEYBOARD_SUNKBD=m
# CONFIG_KEYBOARD_LKKBD is not set
CONFIG_KEYBOARD_XTKBD=m
CONFIG_KEYBOARD_NEWTON=m
# CONFIG_KEYBOARD_STOWAWAY is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_SERIAL=m
CONFIG_MOUSE_INPORT=m
CONFIG_MOUSE_ATIXL=y
CONFIG_MOUSE_LOGIBM=m
CONFIG_MOUSE_PC110PAD=m
# CONFIG_MOUSE_VSXXXAA is not set
CONFIG_INPUT_JOYSTICK=y
CONFIG_JOYSTICK_ANALOG=m
CONFIG_JOYSTICK_A3D=m
CONFIG_JOYSTICK_ADI=m
CONFIG_JOYSTICK_COBRA=m
CONFIG_JOYSTICK_GF2K=m
CONFIG_JOYSTICK_GRIP=m
CONFIG_JOYSTICK_GRIP_MP=m
CONFIG_JOYSTICK_GUILLEMOT=m
CONFIG_JOYSTICK_INTERACT=m
CONFIG_JOYSTICK_SIDEWINDER=m
CONFIG_JOYSTICK_TMDC=m
CONFIG_JOYSTICK_IFORCE=m
# CONFIG_JOYSTICK_IFORCE_USB is not set
CONFIG_JOYSTICK_IFORCE_232=y
CONFIG_JOYSTICK_WARRIOR=m
CONFIG_JOYSTICK_MAGELLAN=m
CONFIG_JOYSTICK_SPACEORB=m
CONFIG_JOYSTICK_SPACEBALL=m
CONFIG_JOYSTICK_STINGER=m
# CONFIG_JOYSTICK_TWIDJOY is not set
# CONFIG_JOYSTICK_JOYDUMP is not set
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_GUNZE=m
# CONFIG_TOUCHSCREEN_ELO is not set
# CONFIG_TOUCHSCREEN_MTOUCH is not set
# CONFIG_TOUCHSCREEN_MK712 is not set
# CONFIG_TOUCHSCREEN_PENMOUNT is not set
# CONFIG_TOUCHSCREEN_TOUCHRIGHT is not set
# CONFIG_TOUCHSCREEN_TOUCHWIN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=y
# CONFIG_INPUT_WISTRON_BTNS is not set
CONFIG_INPUT_UINPUT=m

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=m
CONFIG_SERIO_CT82C710=m
CONFIG_SERIO_PCIPS2=m
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
CONFIG_GAMEPORT=m
CONFIG_GAMEPORT_NS558=m
CONFIG_GAMEPORT_L4=m
CONFIG_GAMEPORT_EMU10K1=m
CONFIG_GAMEPORT_FM801=m

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=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=y
CONFIG_LEGACY_PTY_COUNT=256

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
CONFIG_NVRAM=m
CONFIG_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# Ftape, the floppy tape device driver
#
CONFIG_AGP=y
CONFIG_AGP_ALI=m
CONFIG_AGP_ATI=m
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not set
CONFIG_AGP_INTEL=y
CONFIG_AGP_NVIDIA=m
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_EFFICEON is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
# CONFIG_SCx200_GPIO is not set
# CONFIG_PC8736x_GPIO is not set
# CONFIG_NSC_GPIO is not set
# CONFIG_CS5535_GPIO is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
CONFIG_HANGCHECK_TIMER=m

#
# TPM devices
#
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set

#
# I2C support
#
CONFIG_I2C=y
# CONFIG_I2C_CHARDEV is not set

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=y
# CONFIG_I2C_ALGOPCF is not set
# CONFIG_I2C_ALGOPCA is not set

#
# I2C Hardware Bus support
#
# 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_I810 is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set
# CONFIG_I2C_PCA_ISA is not set

#
# Miscellaneous I2C Chip support
#
# CONFIG_SENSORS_DS1337 is not set
# CONFIG_SENSORS_DS1374 is not set
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_MAX6875 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

#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set

#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set

#
# Hardware Monitoring support
#
# CONFIG_HWMON is not set
# CONFIG_HWMON_VID is not set

#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m
CONFIG_VIDEO_V4L1=y
CONFIG_VIDEO_V4L1_COMPAT=y
CONFIG_VIDEO_V4L2=y

#
# Video Capture Adapters
#

#
# Video Capture Adapters
#
# CONFIG_VIDEO_ADV_DEBUG is not set
CONFIG_VIDEO_HELPER_CHIPS_AUTO=y
CONFIG_VIDEO_TVAUDIO=m
CONFIG_VIDEO_TDA7432=m
CONFIG_VIDEO_TDA9840=m
CONFIG_VIDEO_TDA9875=m
CONFIG_VIDEO_TEA6415C=m
CONFIG_VIDEO_TEA6420=m
CONFIG_VIDEO_MSP3400=m
CONFIG_VIDEO_WM8775=m
CONFIG_VIDEO_BT819=m
CONFIG_VIDEO_BT856=m
CONFIG_VIDEO_KS0127=m
CONFIG_VIDEO_SAA7110=m
CONFIG_VIDEO_SAA7111=m
CONFIG_VIDEO_SAA7114=m
CONFIG_VIDEO_SAA711X=m
CONFIG_VIDEO_TVP5150=m
CONFIG_VIDEO_VPX3220=m
CONFIG_VIDEO_CX25840=m
CONFIG_VIDEO_CX2341X=m
CONFIG_VIDEO_SAA7185=m
CONFIG_VIDEO_ADV7170=m
CONFIG_VIDEO_ADV7175=m
# CONFIG_VIDEO_VIVI is not set
CONFIG_VIDEO_BT848=m
# CONFIG_VIDEO_BT848_DVB is not set
CONFIG_VIDEO_SAA6588=m
CONFIG_VIDEO_PMS=m
CONFIG_VIDEO_CPIA=m
# CONFIG_VIDEO_CPIA_USB is not set
CONFIG_VIDEO_CPIA2=m
CONFIG_VIDEO_SAA5246A=m
CONFIG_VIDEO_SAA5249=m
CONFIG_TUNER_3036=m
CONFIG_VIDEO_STRADIS=m
CONFIG_VIDEO_ZORAN_ZR36060=m
CONFIG_VIDEO_ZORAN=m
CONFIG_VIDEO_ZORAN_BUZ=m
CONFIG_VIDEO_ZORAN_DC10=m
CONFIG_VIDEO_ZORAN_DC30=m
CONFIG_VIDEO_ZORAN_LML33=m
CONFIG_VIDEO_ZORAN_LML33R10=m
CONFIG_VIDEO_ZORAN_AVS6EYES=m
CONFIG_VIDEO_SAA7134=m
# CONFIG_VIDEO_SAA7134_ALSA is not set
# CONFIG_VIDEO_SAA7134_DVB is not set
CONFIG_VIDEO_MXB=m
CONFIG_VIDEO_DPC=m
CONFIG_VIDEO_HEXIUM_ORION=m
CONFIG_VIDEO_HEXIUM_GEMINI=m
CONFIG_VIDEO_CX88=m
# CONFIG_VIDEO_CX88_ALSA is not set
CONFIG_VIDEO_CX88_BLACKBIRD=m
# CONFIG_VIDEO_CX88_DVB is not set

#
# V4L USB devices
#
CONFIG_VIDEO_PVRUSB2=m
CONFIG_VIDEO_PVRUSB2_29XXX=y
CONFIG_VIDEO_PVRUSB2_24XXX=y
CONFIG_VIDEO_PVRUSB2_SYSFS=y
# CONFIG_VIDEO_PVRUSB2_DEBUGIFC is not set
CONFIG_VIDEO_EM28XX=m
CONFIG_VIDEO_USBVIDEO=m
CONFIG_USB_VICAM=m
CONFIG_USB_IBMCAM=m
CONFIG_USB_KONICAWC=m
CONFIG_USB_QUICKCAM_MESSENGER=m
CONFIG_USB_ET61X251=m
CONFIG_VIDEO_OVCAMCHIP=m
CONFIG_USB_W9968CF=m
CONFIG_USB_OV511=m
CONFIG_USB_SE401=m
CONFIG_USB_SN9C102=m
CONFIG_USB_STV680=m
CONFIG_USB_ZC0301=m
CONFIG_USB_PWC=m
# CONFIG_USB_PWC_DEBUG is not set

#
# Radio Adapters
#
# CONFIG_RADIO_CADET is not set
# CONFIG_RADIO_RTRACK is not set
# CONFIG_RADIO_RTRACK2 is not set
# CONFIG_RADIO_AZTECH is not set
# CONFIG_RADIO_GEMTEK is not set
# CONFIG_RADIO_GEMTEK_PCI is not set
# CONFIG_RADIO_MAXIRADIO is not set
# CONFIG_RADIO_MAESTRO is not set
# CONFIG_RADIO_SF16FMI is not set
# CONFIG_RADIO_SF16FMR2 is not set
# CONFIG_RADIO_TERRATEC is not set
# CONFIG_RADIO_TRUST is not set
# CONFIG_RADIO_TYPHOON is not set
# CONFIG_RADIO_ZOLTRIX is not set
# CONFIG_USB_DSBR is not set

#
# Digital Video Broadcasting Devices
#
CONFIG_DVB=y
CONFIG_DVB_CORE=m
CONFIG_DVB_CORE_ATTACH=y

#
# Supported SAA7146 based PCI Adapters
#
CONFIG_DVB_AV7110=m
# CONFIG_DVB_AV7110_FIRMWARE is not set
CONFIG_DVB_AV7110_OSD=y
CONFIG_DVB_BUDGET=m
CONFIG_DVB_BUDGET_CI=m
CONFIG_DVB_BUDGET_AV=m
CONFIG_DVB_BUDGET_PATCH=m

#
# Supported USB Adapters
#
CONFIG_DVB_USB=m
# CONFIG_DVB_USB_DEBUG is not set
CONFIG_DVB_USB_A800=m
CONFIG_DVB_USB_DIBUSB_MB=m
CONFIG_DVB_USB_DIBUSB_MB_FAULTY=y
CONFIG_DVB_USB_DIBUSB_MC=m
CONFIG_DVB_USB_DIB0700=m
CONFIG_DVB_USB_UMT_010=m
CONFIG_DVB_USB_CXUSB=m
CONFIG_DVB_USB_DIGITV=m
CONFIG_DVB_USB_VP7045=m
CONFIG_DVB_USB_VP702X=m
CONFIG_DVB_USB_GP8PSK=m
CONFIG_DVB_USB_NOVA_T_USB2=m
CONFIG_DVB_USB_DTT200U=m
CONFIG_DVB_TTUSB_BUDGET=m
CONFIG_DVB_TTUSB_DEC=m
CONFIG_DVB_CINERGYT2=m
CONFIG_DVB_CINERGYT2_TUNING=y
CONFIG_DVB_CINERGYT2_STREAM_URB_COUNT=32
CONFIG_DVB_CINERGYT2_STREAM_BUF_SIZE=512
CONFIG_DVB_CINERGYT2_QUERY_INTERVAL=250
CONFIG_DVB_CINERGYT2_ENABLE_RC_INPUT_DEVICE=y
CONFIG_DVB_CINERGYT2_RC_QUERY_INTERVAL=50

#
# Supported FlexCopII (B2C2) Adapters
#
CONFIG_DVB_B2C2_FLEXCOP=m
CONFIG_DVB_B2C2_FLEXCOP_PCI=m
CONFIG_DVB_B2C2_FLEXCOP_USB=m
# CONFIG_DVB_B2C2_FLEXCOP_DEBUG is not set

#
# Supported BT878 Adapters
#
CONFIG_DVB_BT8XX=m

#
# Supported Pluto2 Adapters
#
CONFIG_DVB_PLUTO2=m

#
# Supported DVB Frontends
#

#
# Customise DVB Frontends
#
# CONFIG_DVB_FE_CUSTOMISE is not set

#
# DVB-S (satellite) frontends
#
CONFIG_DVB_STV0299=m
CONFIG_DVB_CX24110=m
# CONFIG_DVB_CX24123 is not set
CONFIG_DVB_TDA8083=m
CONFIG_DVB_MT312=m
CONFIG_DVB_VES1X93=m
CONFIG_DVB_S5H1420=m
CONFIG_DVB_TDA10086=m

#
# DVB-T (terrestrial) frontends
#
CONFIG_DVB_SP8870=m
CONFIG_DVB_SP887X=m
CONFIG_DVB_CX22700=m
CONFIG_DVB_CX22702=m
CONFIG_DVB_L64781=m
CONFIG_DVB_TDA1004X=m
CONFIG_DVB_NXT6000=m
CONFIG_DVB_MT352=m
CONFIG_DVB_ZL10353=m
CONFIG_DVB_DIB3000MB=m
CONFIG_DVB_DIB3000MC=m

#
# DVB-C (cable) frontends
#
CONFIG_DVB_VES1820=m
CONFIG_DVB_TDA10021=m
CONFIG_DVB_STV0297=m

#
# ATSC (North American/Korean Terrestrial/Cable DTV) frontends
#
CONFIG_DVB_NXT200X=m
CONFIG_DVB_OR51211=m
# CONFIG_DVB_OR51132 is not set
CONFIG_DVB_BCM3510=m
CONFIG_DVB_LGDT330X=m

#
# Tuners/PLL support
#
CONFIG_DVB_PLL=m
CONFIG_DVB_TDA826X=m
CONFIG_DVB_TUNER_MT2060=m

#
# Miscellaneous devices
#
CONFIG_DVB_LNBP21=m
# CONFIG_DVB_ISL6421 is not set
CONFIG_DVB_TUA6100=m
CONFIG_VIDEO_SAA7146=m
CONFIG_VIDEO_SAA7146_VV=m
CONFIG_VIDEO_VIDEOBUF=m
CONFIG_VIDEO_TUNER=m
CONFIG_VIDEO_BUF=m
CONFIG_VIDEO_BTCX=m
CONFIG_VIDEO_IR=m
CONFIG_VIDEO_TVEEPROM=m
CONFIG_USB_DABUSB=m

#
# Graphics support
#
CONFIG_FIRMWARE_EDID=y
CONFIG_FB=y
# CONFIG_FB_DDC is not set
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
# 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=y
CONFIG_FB_VESA=y
# CONFIG_FB_IMAC is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_I810 is not set
CONFIG_FB_INTEL=y
# CONFIG_FB_INTEL_DEBUG is not set
CONFIG_FB_INTEL_I2C=y
# 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_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_CYBLA is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL 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_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y

#
# Logo configuration
#
# CONFIG_LOGO is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Sound
#
CONFIG_SOUND=m

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_HWDEP=m
CONFIG_SND_RAWMIDI=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=y
CONFIG_SND_RTCTIMER=m
CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y
CONFIG_SND_DYNAMIC_MINORS=y
CONFIG_SND_SUPPORT_OLD_API=y
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
CONFIG_SND_MPU401_UART=m
CONFIG_SND_OPL3_LIB=m
CONFIG_SND_OPL4_LIB=m
CONFIG_SND_VX_LIB=m
CONFIG_SND_AC97_CODEC=m
CONFIG_SND_AC97_BUS=m
# CONFIG_SND_DUMMY is not set
CONFIG_SND_VIRMIDI=m
CONFIG_SND_MTPAV=m
CONFIG_SND_SERIAL_U16550=m
CONFIG_SND_MPU401=m

#
# ISA devices
#
CONFIG_SND_AD1848_LIB=m
CONFIG_SND_CS4231_LIB=m
CONFIG_SND_ADLIB=m
CONFIG_SND_AD1816A=m
CONFIG_SND_AD1848=m
CONFIG_SND_ALS100=m
CONFIG_SND_AZT2320=m
CONFIG_SND_CMI8330=m
CONFIG_SND_CS4231=m
CONFIG_SND_CS4232=m
CONFIG_SND_CS4236=m
CONFIG_SND_DT019X=m
CONFIG_SND_ES968=m
CONFIG_SND_ES1688=m
CONFIG_SND_ES18XX=m
CONFIG_SND_GUS_SYNTH=m
CONFIG_SND_GUSCLASSIC=m
CONFIG_SND_GUSEXTREME=m
CONFIG_SND_GUSMAX=m
CONFIG_SND_INTERWAVE=m
CONFIG_SND_INTERWAVE_STB=m
CONFIG_SND_OPL3SA2=m
CONFIG_SND_OPTI92X_AD1848=m
CONFIG_SND_OPTI92X_CS4231=m
CONFIG_SND_OPTI93X=m
CONFIG_SND_MIRO=m
CONFIG_SND_SB8=m
CONFIG_SND_SB16=m
CONFIG_SND_SBAWE=m
# CONFIG_SND_SB16_CSP is not set
CONFIG_SND_SGALAXY=m
CONFIG_SND_SSCAPE=m
CONFIG_SND_WAVEFRONT=m

#
# PCI devices
#
CONFIG_SND_AD1889=m
CONFIG_SND_ALS300=m
CONFIG_SND_ALS4000=m
CONFIG_SND_ALI5451=m
CONFIG_SND_ATIIXP=m
CONFIG_SND_ATIIXP_MODEM=m
CONFIG_SND_AU8810=m
CONFIG_SND_AU8820=m
CONFIG_SND_AU8830=m
CONFIG_SND_AZT3328=m
CONFIG_SND_BT87X=m
CONFIG_SND_BT87X_OVERCLOCK=y
CONFIG_SND_CA0106=m
CONFIG_SND_CMIPCI=m
CONFIG_SND_CS4281=m
CONFIG_SND_CS46XX=m
CONFIG_SND_CS46XX_NEW_DSP=y
CONFIG_SND_CS5535AUDIO=m
CONFIG_SND_DARLA20=m
CONFIG_SND_GINA20=m
CONFIG_SND_LAYLA20=m
CONFIG_SND_DARLA24=m
CONFIG_SND_GINA24=m
CONFIG_SND_LAYLA24=m
CONFIG_SND_MONA=m
CONFIG_SND_MIA=m
CONFIG_SND_ECHO3G=m
CONFIG_SND_INDIGO=m
CONFIG_SND_INDIGOIO=m
CONFIG_SND_INDIGODJ=m
CONFIG_SND_EMU10K1=m
CONFIG_SND_EMU10K1X=m
CONFIG_SND_ENS1370=m
CONFIG_SND_ENS1371=m
CONFIG_SND_ES1938=m
CONFIG_SND_ES1968=m
CONFIG_SND_FM801=m
CONFIG_SND_FM801_TEA575X_BOOL=y
CONFIG_SND_FM801_TEA575X=m
CONFIG_SND_HDA_INTEL=m
CONFIG_SND_HDSP=m
CONFIG_SND_HDSPM=m
CONFIG_SND_ICE1712=m
CONFIG_SND_ICE1724=m
CONFIG_SND_INTEL8X0=m
CONFIG_SND_INTEL8X0M=m
CONFIG_SND_KORG1212=m
CONFIG_SND_MAESTRO3=m
CONFIG_SND_MIXART=m
CONFIG_SND_NM256=m
CONFIG_SND_PCXHR=m
CONFIG_SND_RIPTIDE=m
CONFIG_SND_RME32=m
CONFIG_SND_RME96=m
CONFIG_SND_RME9652=m
CONFIG_SND_SONICVIBES=m
CONFIG_SND_TRIDENT=m
CONFIG_SND_VIA82XX=m
CONFIG_SND_VIA82XX_MODEM=m
CONFIG_SND_VX222=m
CONFIG_SND_YMFPCI=m
CONFIG_SND_AC97_POWER_SAVE=y

#
# USB devices
#
CONFIG_SND_USB_AUDIO=m
CONFIG_SND_USB_USX2Y=m

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set

#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=m
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_BANDWIDTH is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
CONFIG_USB_SUSPEND=y
# CONFIG_USB_OTG is not set

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
# CONFIG_USB_EHCI_SPLIT_ISO is not set
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
CONFIG_USB_ISP116X_HCD=m
CONFIG_USB_OHCI_HCD=m
# CONFIG_USB_OHCI_BIG_ENDIAN is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=m
CONFIG_USB_SL811_HCD=m

#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
CONFIG_USB_PRINTER=m

#
# 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=y
CONFIG_USB_STORAGE_FREECOM=y
CONFIG_USB_STORAGE_DPCM=y
CONFIG_USB_STORAGE_USBAT=y
CONFIG_USB_STORAGE_SDDR09=y
CONFIG_USB_STORAGE_SDDR55=y
CONFIG_USB_STORAGE_JUMPSHOT=y
CONFIG_USB_STORAGE_ALAUDA=y
# CONFIG_USB_STORAGE_KARMA is not set
CONFIG_USB_LIBUSUAL=y

#
# USB Input Devices
#
CONFIG_USB_HID=m
CONFIG_USB_HIDINPUT=y
# CONFIG_USB_HIDINPUT_POWERBOOK is not set
# CONFIG_HID_FF is not set
CONFIG_USB_HIDDEV=y

#
# USB HID Boot Protocol drivers
#
CONFIG_USB_KBD=m
CONFIG_USB_MOUSE=m
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_ACECAD is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
CONFIG_USB_TOUCHSCREEN=m
CONFIG_USB_TOUCHSCREEN_EGALAX=y
CONFIG_USB_TOUCHSCREEN_PANJIT=y
CONFIG_USB_TOUCHSCREEN_3M=y
CONFIG_USB_TOUCHSCREEN_ITM=y
CONFIG_USB_TOUCHSCREEN_ETURBO=y
CONFIG_USB_TOUCHSCREEN_GUNZE=y
# CONFIG_USB_YEALINK is not set
# CONFIG_USB_XPAD is not set
CONFIG_USB_ATI_REMOTE=m
CONFIG_USB_ATI_REMOTE2=m
CONFIG_USB_KEYSPAN_REMOTE=m
# CONFIG_USB_APPLETOUCH is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set

#
# USB Network Adapters
#
CONFIG_USB_CATC=m
CONFIG_USB_KAWETH=m
CONFIG_USB_PEGASUS=m
CONFIG_USB_RTL8150=m
CONFIG_USB_USBNET=m
CONFIG_USB_NET_AX8817X=m
CONFIG_USB_NET_CDCETHER=m
CONFIG_USB_NET_GL620A=m
CONFIG_USB_NET_NET1080=m
CONFIG_USB_NET_PLUSB=m
CONFIG_USB_NET_MCS7830=m
CONFIG_USB_NET_RNDIS_HOST=m
CONFIG_USB_NET_CDC_SUBSET=m
CONFIG_USB_ALI_M5632=y
CONFIG_USB_AN2720=y
CONFIG_USB_BELKIN=y
CONFIG_USB_ARMLINUX=y
CONFIG_USB_EPSON2888=y
CONFIG_USB_NET_ZAURUS=m
CONFIG_USB_MON=y

#
# USB port drivers
#

#
# USB Serial Converter support
#
CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_GENERIC=y
# CONFIG_USB_SERIAL_AIRCABLE is not set
CONFIG_USB_SERIAL_AIRPRIME=m
CONFIG_USB_SERIAL_ARK3116=m
CONFIG_USB_SERIAL_BELKIN=m
CONFIG_USB_SERIAL_WHITEHEAT=m
CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m
CONFIG_USB_SERIAL_CP2101=m
CONFIG_USB_SERIAL_CYPRESS_M8=m
CONFIG_USB_SERIAL_EMPEG=m
CONFIG_USB_SERIAL_FTDI_SIO=m
CONFIG_USB_SERIAL_FUNSOFT=m
CONFIG_USB_SERIAL_VISOR=m
CONFIG_USB_SERIAL_IPAQ=m
CONFIG_USB_SERIAL_IR=m
CONFIG_USB_SERIAL_EDGEPORT=m
CONFIG_USB_SERIAL_EDGEPORT_TI=m
CONFIG_USB_SERIAL_GARMIN=m
CONFIG_USB_SERIAL_IPW=m
CONFIG_USB_SERIAL_KEYSPAN_PDA=m
CONFIG_USB_SERIAL_KEYSPAN=m
# CONFIG_USB_SERIAL_KEYSPAN_MPR is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA28 is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA28X is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA28XA is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA28XB is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA19 is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA18X is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA19W is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA19QW is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA19QI is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA49W is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA49WLC is not set
CONFIG_USB_SERIAL_KLSI=m
CONFIG_USB_SERIAL_KOBIL_SCT=m
CONFIG_USB_SERIAL_MCT_U232=m
CONFIG_USB_SERIAL_MOS7720=m
CONFIG_USB_SERIAL_MOS7840=m
CONFIG_USB_SERIAL_NAVMAN=m
CONFIG_USB_SERIAL_PL2303=m
CONFIG_USB_SERIAL_HP4X=m
CONFIG_USB_SERIAL_SAFE=m
# CONFIG_USB_SERIAL_SAFE_PADDED is not set
CONFIG_USB_SERIAL_SIERRAWIRELESS=m
CONFIG_USB_SERIAL_TI=m
CONFIG_USB_SERIAL_CYBERJACK=m
CONFIG_USB_SERIAL_XIRCOM=m
CONFIG_USB_SERIAL_OPTION=m
CONFIG_USB_SERIAL_OMNINET=m
CONFIG_USB_EZUSB=y

#
# USB Miscellaneous drivers
#
CONFIG_USB_EMI62=m
CONFIG_USB_EMI26=m
CONFIG_USB_ADUTUX=m
# 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_LED is not set
CONFIG_USB_CYPRESS_CY7C63=m
CONFIG_USB_CYTHERM=m
CONFIG_USB_PHIDGET=m
CONFIG_USB_PHIDGETKIT=m
CONFIG_USB_PHIDGETMOTORCONTROL=m
CONFIG_USB_PHIDGETSERVO=m
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
CONFIG_USB_SISUSBVGA=m
# CONFIG_USB_SISUSBVGA_CON is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_TEST is not set

#
# USB DSL modem support
#

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
# CONFIG_MMC is not set

#
# LED devices
#
# CONFIG_NEW_LEDS is not set

#
# LED drivers
#

#
# LED Triggers
#

#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set

#
# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
#
CONFIG_EDAC=y

#
# Reporting subsystems
#
# CONFIG_EDAC_DEBUG is not set
CONFIG_EDAC_MM_EDAC=m
# CONFIG_EDAC_AMD76X is not set
CONFIG_EDAC_E7XXX=m
CONFIG_EDAC_E752X=m
CONFIG_EDAC_I82875P=m
CONFIG_EDAC_I82860=m
# CONFIG_EDAC_R82600 is not set
CONFIG_EDAC_POLL=y

#
# Real Time Clock
#
CONFIG_RTC_LIB=m
CONFIG_RTC_CLASS=m

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=m
CONFIG_RTC_INTF_PROC=m
CONFIG_RTC_INTF_DEV=m
CONFIG_RTC_INTF_DEV_UIE_EMUL=y

#
# RTC drivers
#
CONFIG_RTC_DRV_X1205=m
CONFIG_RTC_DRV_DS1307=m
CONFIG_RTC_DRV_DS1553=m
CONFIG_RTC_DRV_ISL1208=m
CONFIG_RTC_DRV_DS1672=m
CONFIG_RTC_DRV_DS1742=m
CONFIG_RTC_DRV_PCF8563=m
CONFIG_RTC_DRV_PCF8583=m
CONFIG_RTC_DRV_RS5C372=m
CONFIG_RTC_DRV_M48T86=m
CONFIG_RTC_DRV_TEST=m
CONFIG_RTC_DRV_V3020=m

#
# DMA Engine support
#
CONFIG_DMA_ENGINE=y

#
# DMA Clients
#
CONFIG_NET_DMA=y

#
# DMA Devices
#
CONFIG_INTEL_IOATDMA=m

#
# File systems
#
CONFIG_EXT2_FS=m
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=m
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_EXT4DEV_FS=m
CONFIG_EXT4DEV_FS_XATTR=y
CONFIG_EXT4DEV_FS_POSIX_ACL=y
CONFIG_EXT4DEV_FS_SECURITY=y
CONFIG_JBD=m
CONFIG_JBD_DEBUG=y
CONFIG_JBD2=m
# CONFIG_JBD2_DEBUG is not set
CONFIG_FS_MBCACHE=m
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=y
# 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_MINIX_FS is not set
CONFIG_ROMFS_FS=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m
# CONFIG_FUSE_FS is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# 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 is not set
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_RAMFS=y
CONFIG_CONFIGFS_FS=m

#
# 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_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
# CONFIG_NFS_DIRECTIO is not set
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V3_ACL is not set
# CONFIG_NFSD_V4 is not set
CONFIG_NFSD_TCP=y
CONFIG_ROOT_NFS=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
CONFIG_RPCSEC_GSS_KRB5=y
# 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
# CONFIG_9P_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 is not set

#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_855=m
CONFIG_NLS_CODEPAGE_857=m
CONFIG_NLS_CODEPAGE_860=m
CONFIG_NLS_CODEPAGE_861=m
CONFIG_NLS_CODEPAGE_862=m
CONFIG_NLS_CODEPAGE_863=m
CONFIG_NLS_CODEPAGE_864=m
CONFIG_NLS_CODEPAGE_865=m
CONFIG_NLS_CODEPAGE_866=m
CONFIG_NLS_CODEPAGE_869=m
CONFIG_NLS_CODEPAGE_936=m
CONFIG_NLS_CODEPAGE_950=m
CONFIG_NLS_CODEPAGE_932=m
CONFIG_NLS_CODEPAGE_949=m
CONFIG_NLS_CODEPAGE_874=m
CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_CODEPAGE_1250=m
CONFIG_NLS_CODEPAGE_1251=m
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=m
CONFIG_NLS_ISO8859_4=m
CONFIG_NLS_ISO8859_5=m
CONFIG_NLS_ISO8859_6=m
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
CONFIG_NLS_ISO8859_13=m
CONFIG_NLS_ISO8859_14=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_KOI8_R=m
CONFIG_NLS_KOI8_U=m
CONFIG_NLS_UTF8=m

#
# Distributed Lock Manager
#
CONFIG_DLM=m
# CONFIG_DLM_DEBUG is not set

#
# Instrumentation Support
#
# CONFIG_PROFILING is not set
# CONFIG_KPROBES is not set

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not set
# CONFIG_ENABLE_MUST_CHECK is not set
CONFIG_MAGIC_SYSRQ=y
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_KERNEL=y
CONFIG_LOG_BUF_SHIFT=17
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_RWSEMS=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
# CONFIG_DEBUG_LOCKDEP is not set
CONFIG_TRACE_IRQFLAGS=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_FS is not set
# CONFIG_DEBUG_VM is not set
CONFIG_DEBUG_LIST=y
CONFIG_FRAME_POINTER=y
CONFIG_UNWIND_INFO=y
CONFIG_STACK_UNWIND=y
CONFIG_FORCED_INLINING=y
# CONFIG_HEADERS_CHECK is not set
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_EARLY_PRINTK=y
CONFIG_DEBUG_STACKOVERFLOW=y
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_RODATA is not set
# CONFIG_4KSTACKS is not set
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
CONFIG_DOUBLEFAULT=y

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=m
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_ECB is not set
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_DES=y
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_TWOFISH_COMMON=m
# CONFIG_CRYPTO_TWOFISH_586 is not set
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_AES=m
# CONFIG_CRYPTO_AES_586 is not set
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
# CONFIG_CRYPTO_TEA is not set
CONFIG_CRYPTO_ARC4=m
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_MICHAEL_MIC=m
# CONFIG_CRYPTO_CRC32C is not set
CONFIG_CRYPTO_TEST=m

#
# Hardware crypto devices
#
# CONFIG_CRYPTO_DEV_PADLOCK is not set

#
# Library routines
#
CONFIG_CRC_CCITT=m
# CONFIG_CRC16 is not set
CONFIG_CRC32=y
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m
CONFIG_PLIST=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_X86_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_KTIME_SCALAR=y

Re: Linux 2.6.19-rc4

[Linus Torvalds]

On Mon, 30 Oct 2006, Andrew Morton wrote:
> 
> That didn't go so well.  I guess the below was intended, but I wonder if
> we actually merged the correct patch?

Gaah.

And I have SYSFS enabled, so I should have seen this warning.

But I've become innoculated against warnings, just because we have too 
many of the totally useless noise about deprecation and crud, and ppc has 
it's own set of bogus compiler-and-linker-generated warnings..

At some point we should get rid of all the "politeness" warnings, just 
because they can end up hiding the _real_ ones.

"pm_register is deprecated" etc - I get almost a hundred lines of warnings 
in my default build (and half of those are sadly due to powerpc binutils, 
that I can't do anythign about: "section .init.text exceeds stub group 
size" etc, which is harmless _other_ than the fact that it helped hide the 
real warnings just because I've grown too used to not looking too 
closely).

		Linus

Re: Linux 2.6.19-rc4

[Martin J. Bligh]

> But I've become innoculated against warnings, just because we have too 
> many of the totally useless noise about deprecation and crud, and ppc has 
> it's own set of bogus compiler-and-linker-generated warnings..
> 
> At some point we should get rid of all the "politeness" warnings, just 
> because they can end up hiding the _real_ ones.

Yay! Couldn't agree more. Does this mean you'll take patches for all the
uninitialized variable crap from gcc 4.x ?

> "pm_register is deprecated" etc - I get almost a hundred lines of warnings 
> in my default build (and half of those are sadly due to powerpc binutils, 
> that I can't do anythign about: "section .init.text exceeds stub group 
> size" etc, which is harmless _other_ than the fact that it helped hide the 
> real warnings just because I've grown too used to not looking too 
> closely).

Doesn't turning off CONFIG_PM_LEGACY fix those? it did for me.

M.

PS. I still think -Werror is a good plan. But I acknowledge that's
fairly extreme.

Re: Linux 2.6.19-rc4

[Ray Lee]

On 10/31/06, Martin J. Bligh <mbligh@google.com> wrote:
> > At some point we should get rid of all the "politeness" warnings, just
> > because they can end up hiding the _real_ ones.
>
> Yay! Couldn't agree more. Does this mean you'll take patches for all the
> uninitialized variable crap from gcc 4.x ?

What would be useful in the short term is a tool that shows only the
new warnings that didn't exist in the last point release.

Ray

Re: Linux 2.6.19-rc4

[Dave Jones]

On Tue, Oct 31, 2006 at 08:34:23AM -0800, Ray Lee wrote:
 > On 10/31/06, Martin J. Bligh <mbligh@google.com> wrote:
 > > > At some point we should get rid of all the "politeness" warnings, just
 > > > because they can end up hiding the _real_ ones.
 > >
 > > Yay! Couldn't agree more. Does this mean you'll take patches for all the
 > > uninitialized variable crap from gcc 4.x ?
 > 
 > What would be useful in the short term is a tool that shows only the
 > new warnings that didn't exist in the last point release.

git clone git://git.kernel.org/pub/scm/linux/kernel/git/viro/remapper.git

Daily snapshots available at http://www.codemonkey.org.uk/projects/git-snapshots/remapper/

	Dave


-- 
http://www.codemonkey.org.uk

Re: Linux 2.6.19-rc4

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 794 bytes --]

On Tue, 31 Oct 2006 11:51:33 EST, Dave Jones said:
> On Tue, Oct 31, 2006 at 08:34:23AM -0800, Ray Lee wrote:
>  > On 10/31/06, Martin J. Bligh <mbligh@google.com> wrote:
>  > > > At some point we should get rid of all the "politeness" warnings, just
>  > > > because they can end up hiding the _real_ ones.
>  > >
>  > > Yay! Couldn't agree more. Does this mean you'll take patches for all the
>  > > uninitialized variable crap from gcc 4.x ?
>  > 
>  > What would be useful in the short term is a tool that shows only the
>  > new warnings that didn't exist in the last point release.
> 
> git clone git://git.kernel.org/pub/scm/linux/kernel/git/viro/remapper.git

As somebody proves me wrong on the fact it's not easy.  Of course, it's
Al's git tree, which is probably saying something. :)

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Linux 2.6.19-rc4

[Al Viro]

On Tue, Oct 31, 2006 at 04:26:55PM -0500, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 31 Oct 2006 11:51:33 EST, Dave Jones said:
> > On Tue, Oct 31, 2006 at 08:34:23AM -0800, Ray Lee wrote:
> >  > On 10/31/06, Martin J. Bligh <mbligh@google.com> wrote:
> >  > > > At some point we should get rid of all the "politeness" warnings, just
> >  > > > because they can end up hiding the _real_ ones.
> >  > >
> >  > > Yay! Couldn't agree more. Does this mean you'll take patches for all the
> >  > > uninitialized variable crap from gcc 4.x ?
> >  > 
> >  > What would be useful in the short term is a tool that shows only the
> >  > new warnings that didn't exist in the last point release.
> > 
> > git clone git://git.kernel.org/pub/scm/linux/kernel/git/viro/remapper.git
> 
> As somebody proves me wrong on the fact it's not easy.  Of course, it's
> Al's git tree, which is probably saying something. :)

It is easy, actually.  Key observation: unidiff with 0 context lines contains
everything you need to find out which lines survive and where do they move;
just ignore the actual changes in the diff and look at @@... and diff headers.
There are two parts - one takes such diff and generates a fate map for lines
(basically, "this range gets shifted to this place, this range doesn't make it
at all" + file removals + file renames if diff has been generated by git-diff
and contains that information).  Another is a very simple filter; it takes
map file as argument, reads it and uses the map to massage lines it reads
from stdin.  When we see <affected pathname>:<number> in the beginning of the
line or after a space, see if that line is in surviving range; if it is,
replace pathname and shift line number, otherwise add a prefix ("O:" by
default).  That's it.  About 10K of sparse C - both filter and map generator.

	Two-clause BSD license, so feel free to use it in any way you want.
I don't think there will be serious changes down the road; I'll need to
sit down and turn a description of that puppy into a proper manpage, but
that's about it.

Re: Linux 2.6.19-rc4

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 444 bytes --]

On Tue, 31 Oct 2006 22:39:06 GMT, Al Viro said:
> It is easy, actually.

<technical explanation that boils down to "you can't just diff the messages,
you need to peek at the source" and leverages unidiff to do some of the heavy
lifting>

> default).  That's it.  About 10K of sparse C - both filter and map generator.

"10K of C code" easy is a tad different than a 4-line "diff the 2 compile logs"
easy, which is what I was sort of saying... 

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Linux 2.6.19-rc4

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 824 bytes --]

On Tue, 31 Oct 2006 08:34:23 PST, Ray Lee said:
> On 10/31/06, Martin J. Bligh <mbligh@google.com> wrote:
> > > At some point we should get rid of all the "politeness" warnings, just
> > > because they can end up hiding the _real_ ones.
> >
> > Yay! Couldn't agree more. Does this mean you'll take patches for all the
> > uninitialized variable crap from gcc 4.x ?
> 
> What would be useful in the short term is a tool that shows only the
> new warnings that didn't exist in the last point release.

Harder to do than you might think - it has to deal with the fact that
2.6.N might have a warning about 'used unintialized on line 430', and
in 2.6.N+1 you get two warnings, one on line 420 and one on 440.  Which
one is new and which one just moved 10 lines up or down?  Or did a patch
fix the one on 430 and add 2 new ones?

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Linux 2.6.19-rc4

[Al Viro]

On Tue, Oct 31, 2006 at 03:53:00PM -0500, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 31 Oct 2006 08:34:23 PST, Ray Lee said:
> > On 10/31/06, Martin J. Bligh <mbligh@google.com> wrote:
> > > > At some point we should get rid of all the "politeness" warnings, just
> > > > because they can end up hiding the _real_ ones.
> > >
> > > Yay! Couldn't agree more. Does this mean you'll take patches for all the
> > > uninitialized variable crap from gcc 4.x ?
> > 
> > What would be useful in the short term is a tool that shows only the
> > new warnings that didn't exist in the last point release.
> 
> Harder to do than you might think - it has to deal with the fact that
> 2.6.N might have a warning about 'used unintialized on line 430', and
> in 2.6.N+1 you get two warnings, one on line 420 and one on 440.  Which
> one is new and which one just moved 10 lines up or down?  Or did a patch
> fix the one on 430 and add 2 new ones?

So you take the old log and replace the line numbers with those of
corresponding lines in new tree.  Marking ones that do not survive
unchanged with recognisable prefix.  _Then_ you diff logs.

In reality (and I'd been doing that for ranges like 2.6.14 -> 2.6.19-rc1)
you get very little noise.

Again, see remapper mentioned in this thread; it really works.

Re: Linux 2.6.19-rc4

[Willy Tarreau]

On Tue, Oct 31, 2006 at 03:53:00PM -0500, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 31 Oct 2006 08:34:23 PST, Ray Lee said:
> > On 10/31/06, Martin J. Bligh <mbligh@google.com> wrote:
> > > > At some point we should get rid of all the "politeness" warnings, just
> > > > because they can end up hiding the _real_ ones.
> > >
> > > Yay! Couldn't agree more. Does this mean you'll take patches for all the
> > > uninitialized variable crap from gcc 4.x ?
> > 
> > What would be useful in the short term is a tool that shows only the
> > new warnings that didn't exist in the last point release.
> 
> Harder to do than you might think - it has to deal with the fact that
> 2.6.N might have a warning about 'used unintialized on line 430', and
> in 2.6.N+1 you get two warnings, one on line 420 and one on 440.  Which
> one is new and which one just moved 10 lines up or down?  Or did a patch
> fix the one on 430 and add 2 new ones?

Not necessarily harder. On a related topic, I maintain an own tree with
about 60-100 patches, added to about as much for the glue to resolve
conflicts. When I apply them in sequence, I get lots of rejects and
fuzzy matches. Initially, it was very hard to know which ones were
expected (and solved) and which ones were new. So I archived the stderr
of the "patch" command in a file named "apply.log". It just show the
patch name and its output if any. Now, when I make a new version, I don't
worry about the warnings or errors, I just diff the new result with the
previous one and quickly detect the patches which conflicts, or even
subtle changes such as fuzzy matches, or "2 hunks failed" instead of
"1 hunk failed".

Since diff's algorithm is very efficient at resynchronizing, you most
often detect only a few changes. From experience, the fact that some
warnings change from line 420 to 440 is very easy to process because
at a glance because you quickly detect that the line is not far away
from the old one, and the warning is exactly the same. So you don't
worry. When you have a doubt, you simply check the code.

The only situation I can imagine which would cause large amounts of
warnings is the ones caused by includes which will propagate to
all files.

I've not tried Al's remapper, but considering how he hates useless
warnings and hidden bugs, I can imagine he has attacked the problem
on the right side ;-)

Regards,
Willy

Re: Linux 2.6.19-rc4

[Guennadi Liakhovetski]

> > On Tue, 31 Oct 2006 08:34:23 PST, Ray Lee said:
> > > On 10/31/06, Martin J. Bligh <mbligh@google.com> wrote:
> > > > > At some point we should get rid of all the "politeness" warnings, just
> > > > > because they can end up hiding the _real_ ones.
> > > >
> > > > Yay! Couldn't agree more. Does this mean you'll take patches for all the
> > > > uninitialized variable crap from gcc 4.x ?
> > > 
> > > What would be useful in the short term is a tool that shows only the
> > > new warnings that didn't exist in the last point release.

Would it be possible to create a new verbosity level like V=2 to hide 
those "politeness" warnings so that by default everybody still would see 
all of them, but those needing to track regressions could use it and only 
see severe ones?

Thanks
Guennadi
---
Guennadi Liakhovetski

Re: Linux 2.6.19-rc4

[Sam Ravnborg]

On Wed, Nov 01, 2006 at 09:26:13PM +0100, Guennadi Liakhovetski wrote:
> > > On Tue, 31 Oct 2006 08:34:23 PST, Ray Lee said:
> > > > On 10/31/06, Martin J. Bligh <mbligh@google.com> wrote:
> > > > > > At some point we should get rid of all the "politeness" warnings, just
> > > > > > because they can end up hiding the _real_ ones.
> > > > >
> > > > > Yay! Couldn't agree more. Does this mean you'll take patches for all the
> > > > > uninitialized variable crap from gcc 4.x ?
> > > > 
> > > > What would be useful in the short term is a tool that shows only the
> > > > new warnings that didn't exist in the last point release.
> 
> Would it be possible to create a new verbosity level like V=2 to hide 
> those "politeness" warnings so that by default everybody still would see 
> all of them, but those needing to track regressions could use it and only 
> see severe ones?

I suggest you try out make V=2 one day.
It does not compress warnings but tells you why something got rebuild.

	Sam

Re: Linux 2.6.19-rc4

[Guennadi Liakhovetski]

On Wed, 1 Nov 2006, Sam Ravnborg wrote:

> On Wed, Nov 01, 2006 at 09:26:13PM +0100, Guennadi Liakhovetski wrote:
> > Would it be possible to create a new verbosity level like V=2 to hide 
> > those "politeness" warnings so that by default everybody still would see 
> > all of them, but those needing to track regressions could use it and only 
> > see severe ones?
> 
> I suggest you try out make V=2 one day.
> It does not compress warnings but tells you why something got rebuild.

Ok, take V=-1, it is more logical as it reduces verbosity and, hopefully, 
not taken yet:-)

Thanks
Guennadi
---
Guennadi Liakhovetski

Re: Linux 2.6.19-rc4

[Adrian Bunk]

On Tue, Oct 31, 2006 at 08:14:32AM -0800, Martin J. Bligh wrote:
>...
> PS. I still think -Werror is a good plan. But I acknowledge that's
> fairly extreme.

Note that this would imply options like -Wno-unused-function and
-Wno-unused-variable (unless you _really_ want to add a few thousand 
#ifdef's to the kernel).

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Linux 2.6.19-rc4

[Martin Bligh]

Adrian Bunk wrote:
> On Tue, Oct 31, 2006 at 08:14:32AM -0800, Martin J. Bligh wrote:
> 
>>...
>>PS. I still think -Werror is a good plan. But I acknowledge that's
>>fairly extreme.
> 
> 
> Note that this would imply options like -Wno-unused-function and
> -Wno-unused-variable (unless you _really_ want to add a few thousand 
> #ifdef's to the kernel).

I don't think so. We already do this inside Google, and it works fine.
I just had about 20 stupid warnings to fix up for 2.6.18. Might depend
which gcc it was, but 4.1 seemed to work OK with that, at least.

M.

Re: Linux 2.6.19-rc4

[Adrian Bunk]

On Tue, Oct 31, 2006 at 10:36:59AM -0800, Martin Bligh wrote:
> Adrian Bunk wrote:
> >On Tue, Oct 31, 2006 at 08:14:32AM -0800, Martin J. Bligh wrote:
> >
> >>...
> >>PS. I still think -Werror is a good plan. But I acknowledge that's
> >>fairly extreme.
> >
> >
> >Note that this would imply options like -Wno-unused-function and
> >-Wno-unused-variable (unless you _really_ want to add a few thousand 
> >#ifdef's to the kernel).
> 
> I don't think so. We already do this inside Google, and it works fine.
> I just had about 20 stupid warnings to fix up for 2.6.18. Might depend
> which gcc it was, but 4.1 seemed to work OK with that, at least.

This might be true if you are only using typical configurations that are 
already low on warnings.

The fun begins if you use settings like CONFIG_PCI=n or
CONFIG_PROC_FS=n .

> M.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Linux 2.6.19-rc4

[Adrian Bunk]

On Tue, Oct 31, 2006 at 08:14:32AM -0800, Martin J. Bligh wrote:
> >But I've become innoculated against warnings, just because we have too 
> >many of the totally useless noise about deprecation and crud, and ppc has 
> >it's own set of bogus compiler-and-linker-generated warnings..
> >
> >At some point we should get rid of all the "politeness" warnings, just 
> >because they can end up hiding the _real_ ones.
> 
> Yay! Couldn't agree more. Does this mean you'll take patches for all the
> uninitialized variable crap from gcc 4.x ?
>...

Another approach might be to get the gcc -Wuninitialized option splitted 
into two different options ("is used uninitialized" and
"might be used uninitialized") and disable the latter.

> M.
>...

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Linux 2.6.19-rc4

[Russell King]

On Tue, Oct 31, 2006 at 08:14:32AM -0800, Martin J. Bligh wrote:
> >But I've become innoculated against warnings, just because we have too 
> >many of the totally useless noise about deprecation and crud, and ppc has 
> >it's own set of bogus compiler-and-linker-generated warnings..
> >
> >At some point we should get rid of all the "politeness" warnings, just 
> >because they can end up hiding the _real_ ones.
> 
> Yay! Couldn't agree more. Does this mean you'll take patches for all the
> uninitialized variable crap from gcc 4.x ?

Why not apply pressure to gcc people to fix their compiler warning bugs
instead?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: Linux 2.6.19-rc4

[Martin Bligh]

Russell King wrote:
> On Tue, Oct 31, 2006 at 08:14:32AM -0800, Martin J. Bligh wrote:
> 
>>>But I've become innoculated against warnings, just because we have too 
>>>many of the totally useless noise about deprecation and crud, and ppc has 
>>>it's own set of bogus compiler-and-linker-generated warnings..
>>>
>>>At some point we should get rid of all the "politeness" warnings, just 
>>>because they can end up hiding the _real_ ones.
>>
>>Yay! Couldn't agree more. Does this mean you'll take patches for all the
>>uninitialized variable crap from gcc 4.x ?
> 
> 
> Why not apply pressure to gcc people to fix their compiler warning bugs
> instead?

I did. They didn't. Reality is a bitch.

To be fair, it says "variable *may* be uninitialised", which is correct,
in that it's not able to follow through functions. likely / unlikely
also broke it, but they fixed that in 4.2.x

M.

CONFIG_USB_USBNET and mii_* (was Re: Linux 2.6.19-rc4)

[Athanasius]

[-- Attachment #1: Type: text/plain, Size: 1695 bytes --]

On Mon, Oct 30, 2006 at 08:27:17PM -0800, Linus Torvalds wrote:
> Before I forget, I'd like to thank Adrian Bunk for his regressions 
> listings, and ask people who are involved with those (both on the blamer 
> and blamee sides) to follow them, and keep making sure that we get them 
> resolved - if only by reminding people about the issues, and testing that 
> things that are claimed to be resolved really are.

  In that light, although it's not being counted as a regression, my
report about CONFIG_USB_USBNET stuff starting to make use of mii_* stuff
in 19-rc3, without making SURE it's available is still outstanding,
unfixed, in 19-rc4 (checked just now by untarring a fresh 2.6.18 copy,
applying the rc4 patch, copying in the known-broken .config from rc3,
make oldconfig, then my usual make bzImage && make modules).
  I've pootled around 'make menuconfig' as well, 'N' and then re-Y/M'ing
USBNET things and it has no effect on the PHYLIB stuff.

  I know patches were flying around in the discussion, have none of them
been shaken down sufficiently for inclusion or has the final patch
simply not been pushed to/seen by Linus yet?

  'Ironically' I don't actually _use_ the usbnet stuff, I'd only enabled
it in case my gf pestered me to test her bluetooth dongle for some
reason.  Thus I'm only likely to keep tabs on this if I specifically
think to, it won't show up in my normal usage patterns.

-Ath
-- 
- Athanasius = Athanasius(at)miggy.org / http://www.miggy.org/
                  Finger athan(at)fysh.org for PGP key
	   "And it's me who is my enemy. Me who beats me up.
Me who makes the monsters. Me who strips my confidence." Paula Cole - ME

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: CONFIG_USB_USBNET and mii_* (was Re: Linux 2.6.19-rc4)

[Randy Dunlap]

On Tue, 31 Oct 2006 17:02:09 +0000 Athanasius wrote:

> On Mon, Oct 30, 2006 at 08:27:17PM -0800, Linus Torvalds wrote:
> > Before I forget, I'd like to thank Adrian Bunk for his regressions 
> > listings, and ask people who are involved with those (both on the blamer 
> > and blamee sides) to follow them, and keep making sure that we get them 
> > resolved - if only by reminding people about the issues, and testing that 
> > things that are claimed to be resolved really are.
> 
>   In that light, although it's not being counted as a regression, my
> report about CONFIG_USB_USBNET stuff starting to make use of mii_* stuff
> in 19-rc3, without making SURE it's available is still outstanding,
> unfixed, in 19-rc4 (checked just now by untarring a fresh 2.6.18 copy,
> applying the rc4 patch, copying in the known-broken .config from rc3,
> make oldconfig, then my usual make bzImage && make modules).
>   I've pootled around 'make menuconfig' as well, 'N' and then re-Y/M'ing
> USBNET things and it has no effect on the PHYLIB stuff.

It's actually CONFIG_MII, not PHYLIB.

Probably David B. needs to resend patch 2/2.
They seem to have been lost in the noise^W recent travel.

Patch 1/2 is below.


>   I know patches were flying around in the discussion, have none of them
> been shaken down sufficiently for inclusion or has the final patch
> simply not been pushed to/seen by Linus yet?
> 
>   'Ironically' I don't actually _use_ the usbnet stuff, I'd only enabled
> it in case my gf pestered me to test her bluetooth dongle for some
> reason.  Thus I'm only likely to keep tabs on this if I specifically
> think to, it won't show up in my normal usage patterns.

---
From: Randy Dunlap <randy.dunlap@oracle.com>

pegasus and mcs7830 drivers use MII interfaces and should
select MII in the same way that drivers/net/ drivers do.

However, the MII config symbol should not be in the 10/100 Ethernet
menu, so that other drivers can use (enable) it or so that users
can enable it without needing to enable 10/100 Ethernet.

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
 drivers/net/Kconfig     |   15 +++++++--------
 drivers/usb/net/Kconfig |    2 ++
 2 files changed, 9 insertions(+), 8 deletions(-)

--- linux-2619-rc3-pv.orig/drivers/usb/net/Kconfig
+++ linux-2619-rc3-pv/drivers/usb/net/Kconfig
@@ -84,6 +84,7 @@ config USB_PEGASUS
 config USB_RTL8150
 	tristate "USB RTL8150 based ethernet device support (EXPERIMENTAL)"
 	depends on EXPERIMENTAL
+	select MII
 	help
 	  Say Y here if you have RTL8150 based usb-ethernet adapter.
 	  Send me <petkan@users.sourceforge.net> any comments you may have.
@@ -210,6 +211,7 @@ config USB_NET_PLUSB
 config USB_NET_MCS7830
 	tristate "MosChip MCS7830 based Ethernet adapters"
 	depends on USB_USBNET
+	select MII
 	help
 	  Choose this option if you're using a 10/100 Ethernet USB2
 	  adapter based on the MosChip 7830 controller. This includes
--- linux-2619-rc3-pv.orig/drivers/net/Kconfig
+++ linux-2619-rc3-pv/drivers/net/Kconfig
@@ -145,6 +145,13 @@ config NET_SB1000
 
 source "drivers/net/arcnet/Kconfig"
 
+config MII
+	tristate "Generic Media Independent Interface device support"
+	help
+	  Most ethernet controllers have MII transceiver either as an external
+	  or internal device.  It is safe to say Y or M here even if your
+	  ethernet card lacks MII.
+
 source "drivers/net/phy/Kconfig"
 
 #
@@ -180,14 +187,6 @@ config NET_ETHERNET
 	  kernel: saying N will just cause the configurator to skip all
 	  the questions about Ethernet network cards. If unsure, say N.
 
-config MII
-	tristate "Generic Media Independent Interface device support"
-	depends on NET_ETHERNET
-	help
-	  Most ethernet controllers have MII transceiver either as an external
-	  or internal device.  It is safe to say Y or M here even if your
-	  ethernet card lack MII.
-
 source "drivers/net/arm/Kconfig"
 
 config MACE

2.6.19-rc4: known unfixed regressions

[Adrian Bunk]

This email lists some known regressions in 2.6.19-rc4 compared to 2.6.18
that are not yet fixed in Linus' tree.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : PCI: MMCONFIG breakage
References : http://lkml.org/lkml/2006/10/27/251
Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
Status     : unknown, both BIOS and Direct work


Subject    : x86_64: oprofile doesn't work
References : http://lkml.org/lkml/2006/10/27/3
Submitter  : Prakash Punnoor <prakash@punnoor.de>
Status     : unknown


Subject    : T43p/T60/X60s: lose ACPI events after suspend/resume
References : http://lkml.org/lkml/2006/10/10/39
             http://lkml.org/lkml/2006/10/4/425
             http://lkml.org/lkml/2006/10/16/262
             http://bugzilla.kernel.org/show_bug.cgi?id=7408
             http://lkml.org/lkml/2006/10/30/251
Submitter  : Martin Lorenz <martin@lorenz.eu.org>
             "Michael S. Tsirkin" <mst@mellanox.co.il>
             Hugh Dickins <hugh@veritas.com>
Status     : unknown


Subject    : sata-via doesn't detect anymore disks attached to VIA vt6421
References : http://bugzilla.kernel.org/show_bug.cgi?id=7255
Submitter  : Thierry Vignaud <tvignaud@mandriva.com>
Status     : unknown


Subject    : unable to rip cd
References : http://lkml.org/lkml/2006/10/13/100
Submitter  : Alex Romosan <romosan@sycorax.lbl.gov>
Status     : unknown


Subject    : cpufreq not working on AMD K8
References : http://lkml.org/lkml/2006/10/10/114
Submitter  : Christian <christiand59@web.de>
Status     : unknown


Subject    : SMP kernel can not generate ISA irq properly
References : http://lkml.org/lkml/2006/10/22/15
Submitter  : Komuro <komurojun-mbn@nifty.com>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Status     : Thomas will investigate


Subject    : USB net drivers: missing MII select's
References : http://lkml.org/lkml/2006/10/25/209
Submitter  : Randy Dunlap <randy.dunlap@oracle.com>
Caused-By  : Arnd Bergmann <arnd@arndb.de>
             commit c41286fd42f3545513f8de9f61028120b6d38e89
Handled-By : Randy Dunlap <randy.dunlap@oracle.com>
             David Brownell <david-b@pacbell.net>
Status     : patches are being discussed

Re: 2.6.19-rc4: known unfixed regressions

[Greg KH]

On Tue, Oct 31, 2006 at 08:56:54PM +0100, Adrian Bunk wrote:
> This email lists some known regressions in 2.6.19-rc4 compared to 2.6.18
> that are not yet fixed in Linus' tree.
> 
> If you find your name in the Cc header, you are either submitter of one
> of the bugs, maintainer of an affectected subsystem or driver, a patch
> of you caused a breakage or I'm considering you in any other way possibly
> involved with one or more of these issues.
> 
> Due to the huge amount of recipients, please trim the Cc when answering.
> 
> 
> Subject    : PCI: MMCONFIG breakage
> References : http://lkml.org/lkml/2006/10/27/251
> Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
> Status     : unknown, both BIOS and Direct work

This seems to be now fixed by using the proper pci config accesses.

thanks,

greg k-h

Re: 2.6.19-rc4: known unfixed regressions

[Adrian Bunk]

On Tue, Oct 31, 2006 at 12:11:11PM -0800, Greg KH wrote:
> On Tue, Oct 31, 2006 at 08:56:54PM +0100, Adrian Bunk wrote:
> > This email lists some known regressions in 2.6.19-rc4 compared to 2.6.18
> > that are not yet fixed in Linus' tree.
> > 
> > If you find your name in the Cc header, you are either submitter of one
> > of the bugs, maintainer of an affectected subsystem or driver, a patch
> > of you caused a breakage or I'm considering you in any other way possibly
> > involved with one or more of these issues.
> > 
> > Due to the huge amount of recipients, please trim the Cc when answering.
> > 
> > 
> > Subject    : PCI: MMCONFIG breakage
> > References : http://lkml.org/lkml/2006/10/27/251
> > Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
> > Status     : unknown, both BIOS and Direct work
> 
> This seems to be now fixed by using the proper pci config accesses.

Jeff, can you confirm MMCONFIG that is working again?

> thanks,
> 
> greg k-h

TIA
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.19-rc4: known unfixed regressions

[Arjan van de Ven]

On Tue, 2006-10-31 at 20:56 +0100, Adrian Bunk wrote:
> This email lists some known regressions in 2.6.19-rc4 compared to 2.6.18
> that are not yet fixed in Linus' tree.
> 
> If you find your name in the Cc header, you are either submitter of one
> of the bugs, maintainer of an affectected subsystem or driver, a patch
> of you caused a breakage or I'm considering you in any other way possibly
> involved with one or more of these issues.
> 
> Due to the huge amount of recipients, please trim the Cc when answering.
> 
> 
> Subject    : PCI: MMCONFIG breakage
> References : http://lkml.org/lkml/2006/10/27/251
> Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
> Status     : unknown, both BIOS and Direct work
> 


hmm I see nothing MMCONFIG related here much....

Re: 2.6.19-rc4: known unfixed regressions

[Adrian Bunk]

On Tue, Oct 31, 2006 at 09:12:17PM +0100, Arjan van de Ven wrote:
> On Tue, 2006-10-31 at 20:56 +0100, Adrian Bunk wrote:
> > This email lists some known regressions in 2.6.19-rc4 compared to 2.6.18
> > that are not yet fixed in Linus' tree.
> > 
> > If you find your name in the Cc header, you are either submitter of one
> > of the bugs, maintainer of an affectected subsystem or driver, a patch
> > of you caused a breakage or I'm considering you in any other way possibly
> > involved with one or more of these issues.
> > 
> > Due to the huge amount of recipients, please trim the Cc when answering.
> > 
> > 
> > Subject    : PCI: MMCONFIG breakage
> > References : http://lkml.org/lkml/2006/10/27/251
> > Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
> > Status     : unknown, both BIOS and Direct work
> 
> hmm I see nothing MMCONFIG related here much....

The "both BIOS and Direct work" is a result of the discussion in the 
later emails of the thread, leaving MMCONFIG.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.19-rc4: known unfixed regressions

[Rafael J. Wysocki]

Hi,

On Tuesday, 31 October 2006 20:56, you wrote:
> This email lists some known regressions in 2.6.19-rc4 compared to 2.6.18
> that are not yet fixed in Linus' tree.

Can we please add the following two to the list of known regressions:

http://bugzilla.kernel.org/show_bug.cgi?id=7082
http://bugzilla.kernel.org/show_bug.cgi?id=7207

They are regressions with respect to 2.6.17.x kernels, but still.

In both cases the commits that cause or trigger the problem have been
identified.  Moreover in the first case everyone involved seems to agree that
the commit should be reverted (at least temporarily).

Greetings,
Rafael

Re: 2.6.19-rc4: known unfixed regressions

[Andrew Morton]

On Thu, 2 Nov 2006 21:02:01 +0100
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:

> Hi,
> 
> On Tuesday, 31 October 2006 20:56, you wrote:
> > This email lists some known regressions in 2.6.19-rc4 compared to 2.6.18
> > that are not yet fixed in Linus' tree.
> 
> Can we please add the following two to the list of known regressions:

Balls are being dropped.

> http://bugzilla.kernel.org/show_bug.cgi?id=7082

So this was a good patch but because of a bug in ne2k-pci which nobody is
fixing we need to drop it?

> http://bugzilla.kernel.org/show_bug.cgi?id=7207

Auke, Jesse - can you please opine on this?

> They are regressions with respect to 2.6.17.x kernels, but still.
> 
> In both cases the commits that cause or trigger the problem have been
> identified.  Moreover in the first case everyone involved seems to agree that
> the commit should be reverted (at least temporarily).
> 
> Greetings,
> Rafael

Re: 2.6.19-rc4: known unfixed regressions

[Auke Kok]

Andrew Morton wrote:
> On Thu, 2 Nov 2006 21:02:01 +0100
> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> 
>> Hi,
>>
>> On Tuesday, 31 October 2006 20:56, you wrote:
>>> This email lists some known regressions in 2.6.19-rc4 compared to 2.6.18
>>> that are not yet fixed in Linus' tree.
>> Can we please add the following two to the list of known regressions:
> 
> Balls are being dropped.
> 
>> http://bugzilla.kernel.org/show_bug.cgi?id=7082
> 
> So this was a good patch but because of a bug in ne2k-pci which nobody is
> fixing we need to drop it?
> 
>> http://bugzilla.kernel.org/show_bug.cgi?id=7207
> 
> Auke, Jesse - can you please opine on this?

I have been looking at this already but not identified the real issue. There are other 
things wrong with suspend/resume and the adapter stats are garbled too after resume 
(ethtool -s ethX shows). This appeared in 2.6.18 somehow

I'll make it high priority and carve into old revisions asap.

Auke

Re: 2.6.19-rc4: known unfixed regressions

[Alan Cox]

Ar Iau, 2006-11-02 am 12:10 -0800, ysgrifennodd Andrew Morton:
> Balls are being dropped.
> 
> > http://bugzilla.kernel.org/show_bug.cgi?id=7082
> 
> So this was a good patch but because of a bug in ne2k-pci which nobody is
> fixing we need to drop it?

I believe the patch is fundamentally wrong. We don't *need* to drop the
IO decode in this case. We don't want to drop it when the BIOS lacks the
brains to put it back. We will also kill some machines doing it as they
have devices we attach drivers to which are not just managing the
function Linux knows about but also many other things. Take the CS5520
for example, generically disable the I/O on that because we have an IDE
driver attached to it and you kill the box stone dead, as its also the
video and a few other things behind the scenes. That is not atypical.

IFF someone has a device that actually needs to disable I/O cycles, well
they can do it themselves.

Alan

Re: 2.6.19-rc4: known unfixed regressions

[Linus Torvalds]

On Thu, 2 Nov 2006, Rafael J. Wysocki wrote:

> Can we please add the following two to the list of known regressions:
> 
> http://bugzilla.kernel.org/show_bug.cgi?id=7082

Ok, I think I'll just revert it.

Decoding the PCI IO range is fine - even if a driver has detached, the 
kernel knows where the PCI devices are, and won't re-use the range. So 
while the patch that triggers the problem seems valid in itself, it's 
probably not worth the pain to apply it at this point. So I think I'll 
revert it - the rationale for the patch was fairly weak.

Greg, or would you prefer to do the honors?

> http://bugzilla.kernel.org/show_bug.cgi?id=7207

This one is apparently purely an e1000 driver problem. Can't help you with 
that one. Although I find it suspicious that the "e1000_resume()" path 
doesn't seem to be calling "e1000_power_up_phy()" before e1000_up().

		Linus

Re: 2.6.19-rc4: known unfixed regressions

[Greg KH]

On Thu, Nov 02, 2006 at 12:54:02PM -0800, Linus Torvalds wrote:
> 
> 
> On Thu, 2 Nov 2006, Rafael J. Wysocki wrote:
> 
> > Can we please add the following two to the list of known regressions:
> > 
> > http://bugzilla.kernel.org/show_bug.cgi?id=7082
> 
> Ok, I think I'll just revert it.
> 
> Decoding the PCI IO range is fine - even if a driver has detached, the 
> kernel knows where the PCI devices are, and won't re-use the range. So 
> while the patch that triggers the problem seems valid in itself, it's 
> probably not worth the pain to apply it at this point. So I think I'll 
> revert it - the rationale for the patch was fairly weak.
> 
> Greg, or would you prefer to do the honors?

I'll queue it up.

thanks,

greg k-h

Re: 2.6.19-rc4: known unfixed regressions

[Adrian Bunk]

On Thu, Nov 02, 2006 at 09:02:01PM +0100, Rafael J. Wysocki wrote:
> Hi,

Ji Rafael,

> On Tuesday, 31 October 2006 20:56, you wrote:
> > This email lists some known regressions in 2.6.19-rc4 compared to 2.6.18
> > that are not yet fixed in Linus' tree.
> 
> Can we please add the following two to the list of known regressions:
> 
> http://bugzilla.kernel.org/show_bug.cgi?id=7082
> http://bugzilla.kernel.org/show_bug.cgi?id=7207
> 
> They are regressions with respect to 2.6.17.x kernels, but still.
>...

I'm sorry, but I'm only tracking regressions since 2.6.18 - "regressions 
since the latest stable kernel" is a clear border, and the number of 
post-2.6.18 regressions is high enough that adding even more 
regressions to my list wouldn't make sense.

> Greetings,
> Rafael

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.19-rc4: known unfixed regressions

[Rafael J. Wysocki]

On Thursday, 2 November 2006 22:26, Adrian Bunk wrote:
> On Thu, Nov 02, 2006 at 09:02:01PM +0100, Rafael J. Wysocki wrote:
> > Hi,
> 
> Ji Rafael,
> 
> > On Tuesday, 31 October 2006 20:56, you wrote:
> > > This email lists some known regressions in 2.6.19-rc4 compared to 2.6.18
> > > that are not yet fixed in Linus' tree.
> > 
> > Can we please add the following two to the list of known regressions:
> > 
> > http://bugzilla.kernel.org/show_bug.cgi?id=7082
> > http://bugzilla.kernel.org/show_bug.cgi?id=7207
> > 
> > They are regressions with respect to 2.6.17.x kernels, but still.
> >...
> 
> I'm sorry, but I'm only tracking regressions since 2.6.18 - "regressions 
> since the latest stable kernel" is a clear border, and the number of 
> post-2.6.18 regressions is high enough that adding even more 
> regressions to my list wouldn't make sense.

Fair enough.

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller

2.6.19-rc4: known regressions with patches

[Adrian Bunk]

This email lists some known regressions in 2.6.19-rc4 compared to 2.6.18
with patches available.

If you find your name in the Cc header, you are either submitter of one 
of the bugs, maintainer of an affectected subsystem or driver, a patch 
of you caused a breakage or I'm considering you in any other way 
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : s390: DCSS support breakage
References : http://lkml.org/lkml/2006/10/27/89
Submitter  : Carsten Otte <cotte@de.ibm.com>
Caused-By  : Heiko Carstens <heiko.carstens@de.ibm.com>
             commit 7676bef9c183fd573822cac9992927ef596d584c
Handled-By : Heiko Carstens <heiko.carstens@de.ibm.com>
Patch      : http://lkml.org/lkml/2006/10/27/89
Status     : patch to revert the commit available


Subject    : DVB frontend selection causes compile errors
References : http://lkml.org/lkml/2006/10/8/244
Submitter  : Adrian Bunk <bunk@stusta.de>
Caused-By  : "Andrew de Quincey" <adq_dvb@lidskialf.net>
             commit 176ac9da4f09820a43fd48f0e74b1486fc3603ba
Handled-By : Trent Piepho <xyzzy@speakeasy.org>
Patch      : http://lkml.org/lkml/2006/10/14/157
Status     : patch available


Subject    : swsusp initialized after SATA (CONFIG_PCI_MULTITHREAD_PROBE)
References : http://lkml.org/lkml/2006/10/14/31
Submitter  : Pavel Machek <pavel@ucw.cz>
Handled-By : Greg KH <greg@kroah.com>
Status     : CONFIG_PCI_MULTITHREAD_PROBE will be disabled in 2.6.19


Subject    : MSI errors during boot (CONFIG_PCI_MULTITHREAD_PROBE)
References : http://lkml.org/lkml/2006/10/16/291
Submitter  : Stephen Hemminger <shemminger@osdl.org>
Handled-By : Greg KH <greg@kroah.com>
Status     : CONFIG_PCI_MULTITHREAD_PROBE will be disabled in 2.6.19

Re: [discuss] Linux 2.6.19-rc4: known unfixed regressions (v2)

[Dave Jones]

On Fri, Nov 03, 2006 at 03:41:32AM +0100, Adrian Bunk wrote:
 > This email lists some known regressions in 2.6.19-rc4 compared to 2.6.18
 > that are not yet fixed in Linus' tree.
 > 
 > If you find your name in the Cc header, you are either submitter of one
 > of the bugs, maintainer of an affectected subsystem or driver, a patch
 > of you caused a breakage or I'm considering you in any other way possibly
 > involved with one or more of these issues.
 > 
 > Due to the huge amount of recipients, please trim the Cc when answering.
 > 
 > Subject    : cpufreq not working on AMD K8
 > References : http://lkml.org/lkml/2006/10/10/114
 > Submitter  : Christian <christiand59@web.de>
 > Status     : unknown

As Mark mentioned in his followup, powernow-k8 didn't change in .19 at all.
I'm suspecting an ACPI change meant that we no longer find the PST tables
correctly.

Christian, can you post the full dmesg's from the working/broken kernels.
It may be useful to enable CONFIG_ACPI_DEBUG too.

	Dave

-- 
http://www.codemonkey.org.uk

Re: [discuss] Linux 2.6.19-rc4: known unfixed regressions (v2)

[Alexey Starikovskiy]

Could this be a problem?
--------------------
...
CONFIG_ACPI_PROCESSOR=m
...
CONFIG_X86_POWERNOW_K8=y
...

Regards,
	Alex.

Dave Jones wrote:
> On Fri, Nov 03, 2006 at 03:41:32AM +0100, Adrian Bunk wrote:
>  > This email lists some known regressions in 2.6.19-rc4 compared to 2.6.18
>  > that are not yet fixed in Linus' tree.
>  > 
>  > If you find your name in the Cc header, you are either submitter of one
>  > of the bugs, maintainer of an affectected subsystem or driver, a patch
>  > of you caused a breakage or I'm considering you in any other way possibly
>  > involved with one or more of these issues.
>  > 
>  > Due to the huge amount of recipients, please trim the Cc when answering.
>  > 
>  > Subject    : cpufreq not working on AMD K8
>  > References : http://lkml.org/lkml/2006/10/10/114
>  > Submitter  : Christian <christiand59@web.de>
>  > Status     : unknown
> 
> As Mark mentioned in his followup, powernow-k8 didn't change in .19 at all.
> I'm suspecting an ACPI change meant that we no longer find the PST tables
> correctly.
> 
> Christian, can you post the full dmesg's from the working/broken kernels.
> It may be useful to enable CONFIG_ACPI_DEBUG too.
> 
> 	Dave
> 

Re: [discuss] Linux 2.6.19-rc4: known unfixed regressions (v2)

[Dave Jones]

On Fri, Nov 03, 2006 at 11:25:37AM +0300, Alexey Starikovskiy wrote:
 > Could this be a problem?
 > --------------------
 > ...
 > CONFIG_ACPI_PROCESSOR=m
 > ...
 > CONFIG_X86_POWERNOW_K8=y

Hmm, possibly.  Christian, does it work again if you set them both to =y ?

	Dave

-- 
http://www.codemonkey.org.uk

Re: [discuss] Linux 2.6.19-rc4: known unfixed regressions (v2)

[Christian]

Am Freitag, 3. November 2006 16:56 schrieb Dave Jones:
> On Fri, Nov 03, 2006 at 11:25:37AM +0300, Alexey Starikovskiy wrote:
>  > Could this be a problem?
>  > --------------------
>  > ...
>  > CONFIG_ACPI_PROCESSOR=m
>  > ...
>  > CONFIG_X86_POWERNOW_K8=y
>
> Hmm, possibly.  Christian, does it work again if you set them both to =y ?

Yes, it works now! Only the change to CONFIG_ACPI_PROCESSOR=y made it work 
again!

Nice catch ;-)

Thank you very much!
-Christian

Re: [discuss] Linux 2.6.19-rc4: known unfixed regressions (v2)

[Dave Jones]

On Sun, Nov 05, 2006 at 06:32:12PM +0100, Christian wrote:
 > Am Freitag, 3. November 2006 16:56 schrieb Dave Jones:
 > > On Fri, Nov 03, 2006 at 11:25:37AM +0300, Alexey Starikovskiy wrote:
 > >  > Could this be a problem?
 > >  > --------------------
 > >  > ...
 > >  > CONFIG_ACPI_PROCESSOR=m
 > >  > ...
 > >  > CONFIG_X86_POWERNOW_K8=y
 > >
 > > Hmm, possibly.  Christian, does it work again if you set them both to =y ?
 > 
 > Yes, it works now! Only the change to CONFIG_ACPI_PROCESSOR=y made it work 
 > again!

So, the reasoning behind this, is that we have this construct..

config X86_POWERNOW_K8_ACPI
    bool
    depends on X86_POWERNOW_K8 && ACPI_PROCESSOR
    depends on !(X86_POWERNOW_K8 = y && ACPI_PROCESSOR = m)
    default y


Which makes us use the ACPI stuff if it's there, otherwise not,
and in your case, it seems your system _needs_ this enabled
to make powernow work.

Thing is, this was there in 2.6.18 too, so strictly speaking,
we haven't regressed here, and you're getting exactly what you asked for.
The problem is that it's completely silent as to why it then fails.

I'm open to improvements, but I'm not sure what the right thing to do
here is.. opinions ?

	Dave

-- 
http://www.codemonkey.org.uk

Re: [discuss] Linux 2.6.19-rc4: known unfixed regressions (v2)

[Adrian Bunk]

On Sun, Nov 05, 2006 at 03:04:48PM -0500, Dave Jones wrote:
> On Sun, Nov 05, 2006 at 06:32:12PM +0100, Christian wrote:
>  > Am Freitag, 3. November 2006 16:56 schrieb Dave Jones:
>  > > On Fri, Nov 03, 2006 at 11:25:37AM +0300, Alexey Starikovskiy wrote:
>  > >  > Could this be a problem?
>  > >  > --------------------
>  > >  > ...
>  > >  > CONFIG_ACPI_PROCESSOR=m
>  > >  > ...
>  > >  > CONFIG_X86_POWERNOW_K8=y
>  > >
>  > > Hmm, possibly.  Christian, does it work again if you set them both to =y ?
>  > 
>  > Yes, it works now! Only the change to CONFIG_ACPI_PROCESSOR=y made it work 
>  > again!
> 
> So, the reasoning behind this, is that we have this construct..
> 
> config X86_POWERNOW_K8_ACPI
>     bool
>     depends on X86_POWERNOW_K8 && ACPI_PROCESSOR
>     depends on !(X86_POWERNOW_K8 = y && ACPI_PROCESSOR = m)
>     default y
> 
> 
> Which makes us use the ACPI stuff if it's there, otherwise not,
> and in your case, it seems your system _needs_ this enabled
> to make powernow work.
> 
> Thing is, this was there in 2.6.18 too, so strictly speaking,
> we haven't regressed here, and you're getting exactly what you asked for.
> The problem is that it's completely silent as to why it then fails.
> 
> I'm open to improvements, but I'm not sure what the right thing to do
> here is.. opinions ?

The extreme solution would be

config X86_POWERNOW_K8
        tristate "AMD Opteron/Athlon64 PowerNow!"
        select CPU_FREQ_TABLE
        depends ACPI_PROCESSOR

A medium solution might be

config X86_POWERNOW_K8
        tristate "AMD Opteron/Athlon64 PowerNow!"
        select CPU_FREQ_TABLE
	depends (ACPI_PROCESSOR || ACPI_PROCESSOR=n)

But in the end, the best solution depends on how many percent of the 
X86_POWERNOW_K8 users have Christian's problem of requiring 
ACPI_PROCESSOR. If there are only very few people with this problem, I'd 
say leave it as it is.

> 	Dave

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [discuss] Linux 2.6.19-rc4: known unfixed regressions (v2)

[Dave Jones]

On Mon, Nov 06, 2006 at 06:35:28PM +0100, Adrian Bunk wrote:
 
 > config X86_POWERNOW_K8
 >         tristate "AMD Opteron/Athlon64 PowerNow!"
 >         select CPU_FREQ_TABLE
 > 	depends (ACPI_PROCESSOR || ACPI_PROCESSOR=n)
 > 
 > But in the end, the best solution depends on how many percent of the 
 > X86_POWERNOW_K8 users have Christian's problem of requiring 
 > ACPI_PROCESSOR. If there are only very few people with this problem, I'd 
 > say leave it as it is.

Well, it's been this way for a while, and only recently this has come up.
There was a similar report for powernow-k7, which has a similar construct.

	Dave

-- 
http://www.codemonkey.org.uk

Re: [discuss] Linux 2.6.19-rc4: known unfixed regressions (v2)

[Adrian Bunk]

On Sun, Nov 05, 2006 at 06:32:12PM +0100, Christian wrote:
> Am Freitag, 3. November 2006 16:56 schrieb Dave Jones:
> > On Fri, Nov 03, 2006 at 11:25:37AM +0300, Alexey Starikovskiy wrote:
> >  > Could this be a problem?
> >  > --------------------
> >  > ...
> >  > CONFIG_ACPI_PROCESSOR=m
> >  > ...
> >  > CONFIG_X86_POWERNOW_K8=y
> >
> > Hmm, possibly.  Christian, does it work again if you set them both to =y ?
> 
> Yes, it works now! Only the change to CONFIG_ACPI_PROCESSOR=y made it work 
> again!

You said 2.6.18 worked for you.

Did you have CONFIG_ACPI_PROCESSOR=y in 2.6.18, or did
CONFIG_ACPI_PROCESSOR=m, CONFIG_X86_POWERNOW_K8=y work for you in 2.6.18?

> Nice catch ;-)
> 
> Thank you very much!
> -Christian

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [discuss] Linux 2.6.19-rc4: known unfixed regressions (v2)

[Christian]

Am Montag, 6. November 2006 07:00 schrieb Adrian Bunk:
> On Sun, Nov 05, 2006 at 06:32:12PM +0100, Christian wrote:
> > Am Freitag, 3. November 2006 16:56 schrieb Dave Jones:
> > > On Fri, Nov 03, 2006 at 11:25:37AM +0300, Alexey Starikovskiy wrote:
> > >  > Could this be a problem?
> > >  > --------------------
> > >  > ...
> > >  > CONFIG_ACPI_PROCESSOR=m
> > >  > ...
> > >  > CONFIG_X86_POWERNOW_K8=y
> > >
> > > Hmm, possibly.  Christian, does it work again if you set them both to
> > > =y ?
> >
> > Yes, it works now! Only the change to CONFIG_ACPI_PROCESSOR=y made it
> > work again!
>
> You said 2.6.18 worked for you.
>
> Did you have CONFIG_ACPI_PROCESSOR=y in 2.6.18, or did
> CONFIG_ACPI_PROCESSOR=m, CONFIG_X86_POWERNOW_K8=y work for you in 2.6.18?

It worked with CONFIG_ACPI_PROCESSOR=m in 2.6.18-rc7. Since 2.6.19-rc1 it 
doesn't work anymore with CONFIG_ACPI_PROCESSOR=m.

user@ubuntu:~/Projekte/linux-2.6.18-rc7$ uname -a
Linux ubuntu.localnet 2.6.18-rc7 #2 SMP Wed Sep 13 11:28:41 CEST 2006 x86_64 
GNU/Linux

user@ubuntu:~/Projekte/linux-2.6.18-rc7$ lsmod | grep -Ei "processor|acpi|
power"
powernow_k8            16096  1
freq_table              6848  2 powernow_k8,cpufreq_stats
cpufreq_powersave       3584  0
asus_acpi              20644  0
processor              36872  2 powernow_k8,thermal


user@ubuntu:~/Projekte/linux-2.6.18-rc7$ grep -i 
ACPI_PROCESSOR /boot/config-2.6.18-rc7
CONFIG_ACPI_PROCESSOR=m

user@ubuntu:~/Projekte/linux-2.6.18-rc7$ 
grep -Ei "POWERNOW_K8" /boot/config-2.6.18-rc7
CONFIG_X86_POWERNOW_K8=m
CONFIG_X86_POWERNOW_K8_ACPI=y

+++ There's a difference in 2.6.19! CONFIG_X86_POWERNOW_K8_ACPI is gone +++

user@ubuntu:~/Projekte/linux-2.6.18-rc7$ 
grep -Ei "POWERNOW_K8" /boot/config-2.6.19-rc1
CONFIG_X86_POWERNOW_K8=y

user@ubuntu:~/Projekte/linux-2.6.18-rc7$ grep -Ei "CPUFREQ|
CPU_FREQ" /boot/config-2.6.18-rc7
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=m
# CONFIG_CPU_FREQ_DEBUG is not set
CONFIG_CPU_FREQ_STAT=m
CONFIG_CPU_FREQ_STAT_DETAILS=y
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE 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=m
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m
# CPUFreq processor drivers
CONFIG_X86_ACPI_CPUFREQ=m
# CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set

-Christian

Re: [discuss] Linux 2.6.19-rc4: known unfixed regressions (v2)

[Dave Jones]

On Mon, Nov 06, 2006 at 04:43:13PM +0100, Christian wrote:

 > > Did you have CONFIG_ACPI_PROCESSOR=y in 2.6.18, or did
 > > CONFIG_ACPI_PROCESSOR=m, CONFIG_X86_POWERNOW_K8=y work for you in 2.6.18?
 > 
 > It worked with CONFIG_ACPI_PROCESSOR=m in 2.6.18-rc7. Since 2.6.19-rc1 it 
 > doesn't work anymore with CONFIG_ACPI_PROCESSOR=m.
 > 
 > user@ubuntu:~/Projekte/linux-2.6.18-rc7$ grep -i ACPI_PROCESSOR /boot/config-2.6.18-rc7
 > CONFIG_ACPI_PROCESSOR=m
 > 
 > user@ubuntu:~/Projekte/linux-2.6.18-rc7$ 
 > grep -Ei "POWERNOW_K8" /boot/config-2.6.18-rc7
 > CONFIG_X86_POWERNOW_K8=m
 > CONFIG_X86_POWERNOW_K8_ACPI=y
 > 
 > +++ There's a difference in 2.6.19! CONFIG_X86_POWERNOW_K8_ACPI is gone +++

I don't understand how this was allowed. Because when I try this
with a 2.6.18 tree..  (nothing changed between -rc7 and final for cpufreq)

<editted a .config to match your config>

$ grep ACPI_PROCESSOR .config
CONFIG_ACPI_PROCESSOR=m
$ grep POWERNOW_K8 .config
CONFIG_X86_POWERNOW_K8=y
CONFIG_X86_POWERNOW_K8_ACPI=y

and then after a make oldconfig the CONFIG_X86_POWERNOW_K8_ACPI is removed
as it isn't valid.

Did you edit your .config by hand ?

	Dave

-- 
http://www.codemonkey.org.uk

Re: [discuss] Linux 2.6.19-rc4: known unfixed regressions (v2)

[Adrian Bunk]

On Mon, Nov 06, 2006 at 12:20:49PM -0500, Dave Jones wrote:
> On Mon, Nov 06, 2006 at 04:43:13PM +0100, Christian wrote:
> 
>  > > Did you have CONFIG_ACPI_PROCESSOR=y in 2.6.18, or did
>  > > CONFIG_ACPI_PROCESSOR=m, CONFIG_X86_POWERNOW_K8=y work for you in 2.6.18?
>  > 
>  > It worked with CONFIG_ACPI_PROCESSOR=m in 2.6.18-rc7. Since 2.6.19-rc1 it 
>  > doesn't work anymore with CONFIG_ACPI_PROCESSOR=m.
>  > 
>  > user@ubuntu:~/Projekte/linux-2.6.18-rc7$ grep -i ACPI_PROCESSOR /boot/config-2.6.18-rc7
>  > CONFIG_ACPI_PROCESSOR=m
>  > 
>  > user@ubuntu:~/Projekte/linux-2.6.18-rc7$ 
>  > grep -Ei "POWERNOW_K8" /boot/config-2.6.18-rc7
>  > CONFIG_X86_POWERNOW_K8=m
>  > CONFIG_X86_POWERNOW_K8_ACPI=y
>  > 
>  > +++ There's a difference in 2.6.19! CONFIG_X86_POWERNOW_K8_ACPI is gone +++
> 
> I don't understand how this was allowed. Because when I try this
> with a 2.6.18 tree..  (nothing changed between -rc7 and final for cpufreq)
> 
> <editted a .config to match your config>
> 
> $ grep ACPI_PROCESSOR .config
> CONFIG_ACPI_PROCESSOR=m
> $ grep POWERNOW_K8 .config
> CONFIG_X86_POWERNOW_K8=y
> CONFIG_X86_POWERNOW_K8_ACPI=y
> 
> and then after a make oldconfig the CONFIG_X86_POWERNOW_K8_ACPI is removed
> as it isn't valid.
> 
> Did you edit your .config by hand ?

Look closer, his linux-2.6.18-rc7 .config contains 
CONFIG_ACPI_PROCESSOR=m, CONFIG_X86_POWERNOW_K8=m.

> 	Dave

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [discuss] Linux 2.6.19-rc4: known unfixed regressions (v2)

[Adrian Bunk]

On Mon, Nov 06, 2006 at 04:43:13PM +0100, Christian wrote:
> Am Montag, 6. November 2006 07:00 schrieb Adrian Bunk:
> > On Sun, Nov 05, 2006 at 06:32:12PM +0100, Christian wrote:
> > > Am Freitag, 3. November 2006 16:56 schrieb Dave Jones:
> > > > On Fri, Nov 03, 2006 at 11:25:37AM +0300, Alexey Starikovskiy wrote:
> > > >  > Could this be a problem?
> > > >  > --------------------
> > > >  > ...
> > > >  > CONFIG_ACPI_PROCESSOR=m
> > > >  > ...
> > > >  > CONFIG_X86_POWERNOW_K8=y
> > > >
> > > > Hmm, possibly.  Christian, does it work again if you set them both to
> > > > =y ?
> > >
> > > Yes, it works now! Only the change to CONFIG_ACPI_PROCESSOR=y made it
> > > work again!
> >
> > You said 2.6.18 worked for you.
> >
> > Did you have CONFIG_ACPI_PROCESSOR=y in 2.6.18, or did
> > CONFIG_ACPI_PROCESSOR=m, CONFIG_X86_POWERNOW_K8=y work for you in 2.6.18?
> 
> It worked with CONFIG_ACPI_PROCESSOR=m in 2.6.18-rc7. Since 2.6.19-rc1 it 
> doesn't work anymore with CONFIG_ACPI_PROCESSOR=m.
> 
> user@ubuntu:~/Projekte/linux-2.6.18-rc7$ uname -a
> Linux ubuntu.localnet 2.6.18-rc7 #2 SMP Wed Sep 13 11:28:41 CEST 2006 x86_64 
> GNU/Linux
> 
> user@ubuntu:~/Projekte/linux-2.6.18-rc7$ lsmod | grep -Ei "processor|acpi|
> power"
> powernow_k8            16096  1
> freq_table              6848  2 powernow_k8,cpufreq_stats
> cpufreq_powersave       3584  0
> asus_acpi              20644  0
> processor              36872  2 powernow_k8,thermal
> 
> 
> user@ubuntu:~/Projekte/linux-2.6.18-rc7$ grep -i 
> ACPI_PROCESSOR /boot/config-2.6.18-rc7
> CONFIG_ACPI_PROCESSOR=m
> 
> user@ubuntu:~/Projekte/linux-2.6.18-rc7$ 
> grep -Ei "POWERNOW_K8" /boot/config-2.6.18-rc7
> CONFIG_X86_POWERNOW_K8=m
> CONFIG_X86_POWERNOW_K8_ACPI=y
> 
> +++ There's a difference in 2.6.19! CONFIG_X86_POWERNOW_K8_ACPI is gone +++
> 
> user@ubuntu:~/Projekte/linux-2.6.18-rc7$ 
> grep -Ei "POWERNOW_K8" /boot/config-2.6.19-rc1
> CONFIG_X86_POWERNOW_K8=y
>....

It's gone because you changed CONFIG_X86_POWERNOW_K8 from m to y.

> -Christian

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [linux-usb-devel] Linux 2.6.19-rc4: known unfixed regressions (v2)

[Greg KH]

On Fri, Nov 03, 2006 at 03:41:32AM +0100, Adrian Bunk wrote:
> Subject    : USB net drivers: missing MII select's
> References : http://lkml.org/lkml/2006/10/25/209
> Submitter  : Randy Dunlap <randy.dunlap@oracle.com>
> Caused-By  : Arnd Bergmann <arnd@arndb.de>
>              commit c41286fd42f3545513f8de9f61028120b6d38e89
> Handled-By : Randy Dunlap <randy.dunlap@oracle.com>
>              David Brownell <david-b@pacbell.net>
> Status     : patches are being discussed

This is fixed in Linus's tree already.  If it's somehow insufficient,
please let me know.

thanks,

greg k-h

Re: 2.6.19-rc4: known unfixed regressions (v3)

[Michael S. Tsirkin]

Quoting r. Adrian Bunk <bunk@stusta.de>:
> Subject    : ThinkPad T60/X60: lose ACPI events after suspend/resume
> References : http://lkml.org/lkml/2006/10/10/39
>              http://lkml.org/lkml/2006/10/4/425
>              http://lkml.org/lkml/2006/10/16/262
>              http://bugzilla.kernel.org/show_bug.cgi?id=7408
>              http://lkml.org/lkml/2006/10/30/251
>              http://lkml.org/lkml/2006/11/3/244
> Submitter  : Martin Lorenz <martin@lorenz.eu.org>
>              "Michael S. Tsirkin" <mst@mellanox.co.il>
> Status     : problem is being debugged

Add to that
http://lkml.org/lkml/2006/11/1/84
and a patch in
http://lkml.org/lkml/2006/11/1/294

I have been running f9dadfa71bc594df09044da61d1c72701121d802 which hs this patch
for several days now and this issue seem to be fixed.

I plan to re-test on -rc5 when that's out.

-- 
MST

Re: 2.6.19-rc4: known unfixed regressions (v3)

[Adrian Bunk]

On Sun, Nov 05, 2006 at 03:26:07PM +0200, Michael S. Tsirkin wrote:
> Quoting r. Adrian Bunk <bunk@stusta.de>:
> > Subject    : ThinkPad T60/X60: lose ACPI events after suspend/resume
> > References : http://lkml.org/lkml/2006/10/10/39
> >              http://lkml.org/lkml/2006/10/4/425
> >              http://lkml.org/lkml/2006/10/16/262
> >              http://bugzilla.kernel.org/show_bug.cgi?id=7408
> >              http://lkml.org/lkml/2006/10/30/251
> >              http://lkml.org/lkml/2006/11/3/244
> > Submitter  : Martin Lorenz <martin@lorenz.eu.org>
> >              "Michael S. Tsirkin" <mst@mellanox.co.il>
> > Status     : problem is being debugged
> 
> Add to that
> http://lkml.org/lkml/2006/11/1/84
> and a patch in
> http://lkml.org/lkml/2006/11/1/294
> 
> I have been running f9dadfa71bc594df09044da61d1c72701121d802 which hs this patch
> for several days now and this issue seem to be fixed.
> 
> I plan to re-test on -rc5 when that's out.

Thanks for this information, unless you'll tell the opposite I'll assume 
your problems are fixed.

Martin, are your problems also fixed in the latest -git?

> MST

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.19-rc4: known unfixed regressions (v3)

[Eric W. Biederman]

Adrian Bunk <bunk@stusta.de> writes:

> This email lists some known regressions in 2.6.19-rc4 compared to 2.6.18
> that are not yet fixed in Linus' tree.
>
> If you find your name in the Cc header, you are either submitter of one
> of the bugs, maintainer of an affectected subsystem or driver, a patch
> of you caused a breakage or I'm considering you in any other way possibly
> involved with one or more of these issues.
>
> Due to the huge amount of recipients, please trim the Cc when answering.
>
>
> Subject    : ipath driver MCEs system on load when HT chip present
> References : http://bugzilla.kernel.org/show_bug.cgi?id=7455
> Submitter  : Bryan O'Sullivan <bos@serpentine.com>
> Caused-By  : Eric W. Biederman <ebiederm@xmission.com>
> Status     : unknown

Status in problem is being debugged. I have posted some infrastructure
patches that should allow Bryan to fix his driver cleanly.  

I did not cause this. The ipath HTX card driver's irq handling has
never been anything but a hack.  It has never worked correctly even in
the instances it worked.  It only worked on i386 or x86_64 when
CONFIG_PCI_MSI was enabled but did not use MSI.  It was relying on the
implementation detail that the architecture specific vector number was
placed in the dev->irq.  dev->irq is actually meaningless on this card
as it doesn't have any ordinary pci interrupts.

So while I am happy to take credit for flushing this bug out I did not
introduce it.

Eric

Re: 2.6.19-rc4: known unfixed regressions (v3)

[Adrian Bunk]

On Sun, Nov 05, 2006 at 08:17:53AM -0700, Eric W. Biederman wrote:
> Adrian Bunk <bunk@stusta.de> writes:
> 
> > This email lists some known regressions in 2.6.19-rc4 compared to 2.6.18
> > that are not yet fixed in Linus' tree.
> >
> > If you find your name in the Cc header, you are either submitter of one
> > of the bugs, maintainer of an affectected subsystem or driver, a patch
> > of you caused a breakage or I'm considering you in any other way possibly
> > involved with one or more of these issues.
> >
> > Due to the huge amount of recipients, please trim the Cc when answering.
> >
> >
> > Subject    : ipath driver MCEs system on load when HT chip present
> > References : http://bugzilla.kernel.org/show_bug.cgi?id=7455
> > Submitter  : Bryan O'Sullivan <bos@serpentine.com>
> > Caused-By  : Eric W. Biederman <ebiederm@xmission.com>
> > Status     : unknown
> 
> Status in problem is being debugged. I have posted some infrastructure
> patches that should allow Bryan to fix his driver cleanly.  
> 
> I did not cause this. The ipath HTX card driver's irq handling has
> never been anything but a hack.  It has never worked correctly even in
> the instances it worked.  It only worked on i386 or x86_64 when
> CONFIG_PCI_MSI was enabled but did not use MSI.  It was relying on the
> implementation detail that the architecture specific vector number was
> placed in the dev->irq.  dev->irq is actually meaningless on this card
> as it doesn't have any ordinary pci interrupts.
> 
> So while I am happy to take credit for flushing this bug out I did not
> introduce it.

My notion of "regression" is from a user's perspective.

Therefore, if a hack that worked at least for some users no longer 
works, that's a regression. That's independent of the technical question 
whose fault it actually was.

We should either get this fixed before 2.6.19 or at least make it clear 
for users that support for this hardware won't be back before 2.6.20.

> Eric

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.19-rc4: known unfixed regressions (v3)

[Bryan O'Sullivan]

Adrian Bunk wrote:

> We should either get this fixed before 2.6.19 or at least make it clear 
> for users that support for this hardware won't be back before 2.6.20.

Eric and I are working on patches for this.

	<b

Re: 2.6.19-rc4: known unfixed regressions (v3)

[Eric W. Biederman]

"Bryan O'Sullivan" <bos@serpentine.com> writes:

> Adrian Bunk wrote:
>
>> We should either get this fixed before 2.6.19 or at least make it clear for
>> users that support for this hardware won't be back before 2.6.20.
>
> Eric and I are working on patches for this.

How comes the driver fixes in the context of my patches?

Eric

Re: 2.6.19-rc4: known unfixed regressions (v3)

[Bryan O'Sullivan]

Eric W. Biederman wrote:

> How comes the driver fixes in the context of my patches?

The fix is simple enough, it's just not as clean as I'd like.  I have to 
pull apart the contents of the ht_irq_msg that the new update hook is 
getting passed, in order to get the vector out, so that I can reprogram 
the offending chip register after I've done the config space writes. 
It's a pretty roundabout way to do the job.

	<b

Re: 2.6.19-rc4: known unfixed regressions (v3)

[Eric W. Biederman]

"Bryan O'Sullivan" <bos@serpentine.com> writes:

> Eric W. Biederman wrote:
>
>> How comes the driver fixes in the context of my patches?
>
> The fix is simple enough, it's just not as clean as I'd like.  I have to pull
> apart the contents of the ht_irq_msg that the new update hook is getting passed,
> in order to get the vector out, so that I can reprogram the offending chip
> register after I've done the config space writes. It's a pretty roundabout way
> to do the job.

Huh?  As I read the ipath code I am passing you the value that needs to go
into ipath->int_config and thus into dd->ipath_kregs->kr_interrupt_config.

Sure it is coming as 2 32bit words instead of a one big 64 bit one, but
that is simple to fix.

If your card doesn't pay attention to configuration space access cycles then
there should be no reason to write the value there.   If your card does pay
attention to the configuration space access cycles it should be trivial to
make this work.

Please stop getting stuck on your existing hack that only put in the vector
number and didn't put in any of the other interrupt routing information.

If you really need to write to both the config space registers and your
magic shadow copy of the register I can certainly do the config space
writes for you.  I just figured it would be more efficient not to.

Eric

Re: 2.6.19-rc4: known unfixed regressions (v3)

[Dave Olson]

On Tue, 7 Nov 2006, Eric W. Biederman wrote:
| Huh?  As I read the ipath code I am passing you the value that needs to go
| into ipath->int_config and thus into dd->ipath_kregs->kr_interrupt_config.

Yes.

| Sure it is coming as 2 32bit words instead of a one big 64 bit one, but
| that is simple to fix.

It would be cleaner, but not absolutely necessary.

| If your card doesn't pay attention to configuration space access cycles then
| there should be no reason to write the value there.   If your card does pay
| attention to the configuration space access cycles it should be trivial to
| make this work.

The card does pay attention, and other programs such as lspci and the
like also look at the config space.  They should definitely be kept
in sync, and config writes are fairly cheap, anyway.

| If you really need to write to both the config space registers and your
| magic shadow copy of the register I can certainly do the config space
| writes for you.  I just figured it would be more efficient not to.

The HT layer should always do the config updates, since you are trying
to clean up that layer.  Only the "extra" stuff (if any) should be done by
the callback.

Dave Olson
dave.olson@qlogic.com

Re: 2.6.19-rc4: known unfixed regressions (v3)

[Eric W. Biederman]

Dave Olson <olson@pathscale.com> writes:

> On Tue, 7 Nov 2006, Eric W. Biederman wrote:
> | Huh?  As I read the ipath code I am passing you the value that needs to go
> | into ipath->int_config and thus into dd->ipath_kregs->kr_interrupt_config.
>
> Yes.
>
> | Sure it is coming as 2 32bit words instead of a one big 64 bit one, but
> | that is simple to fix.
>
> It would be cleaner, but not absolutely necessary.
>
> | If your card doesn't pay attention to configuration space access cycles then
> | there should be no reason to write the value there.   If your card does pay
> | attention to the configuration space access cycles it should be trivial to
> | make this work.
>
> The card does pay attention, and other programs such as lspci and the
> like also look at the config space.  They should definitely be kept
> in sync, and config writes are fairly cheap, anyway.

Well this is a rathole so it really isn't safe for lspci to play with
(races with the kernel accessing it)

This hole concept of you having the register but not connecting it up on
the card is rather bizarre.

> | If you really need to write to both the config space registers and your
> | magic shadow copy of the register I can certainly do the config space
> | writes for you.  I just figured it would be more efficient not to.
>
> The HT layer should always do the config updates, since you are trying
> to clean up that layer.  Only the "extra" stuff (if any) should be done by
> the callback.

Fine by me.  That's why the patch was up for review.  That is just moving
the if statement I currently have.  So it should be trivial.  If that
won't break your card that is good enough for me.

Eric

Re: 2.6.19-rc4: known unfixed regressions (v3)

[Dave Olson]

On Tue, 7 Nov 2006, Eric W. Biederman wrote:
| > | If your card doesn't pay attention to configuration space access cycles then
| > | there should be no reason to write the value there.   If your card does pay
| > | attention to the configuration space access cycles it should be trivial to
| > | make this work.
| >
| > The card does pay attention, and other programs such as lspci and the
| > like also look at the config space.  They should definitely be kept
| > in sync, and config writes are fairly cheap, anyway.
| 
| Well this is a rathole so it really isn't safe for lspci to play with
| (races with the kernel accessing it)

Displaying something that might change is a fact of life, and no
different than the PCI world.  It's still best to keep things as
correct as possible.

| This hole concept of you having the register but not connecting it up on
| the card is rather bizarre.

The HT core we use made it extremely difficult, unfortunately.   One of
those things in hardware you sometimes just have to live with.

| > The HT layer should always do the config updates, since you are trying
| > to clean up that layer.  Only the "extra" stuff (if any) should be done by
| > the callback.
| 
| Fine by me.  That's why the patch was up for review.  That is just moving
| the if statement I currently have.  So it should be trivial.  If that
| won't break your card that is good enough for me.

Thanks,

Dave Olson
dave.olson@qlogic.com

Re: 2.6.19-rc4: known unfixed regressions (v3)

[Eric W. Biederman]

Dave Olson <olson@pathscale.com> writes:

> On Tue, 7 Nov 2006, Eric W. Biederman wrote:
> | > | If your card doesn't pay attention to configuration space access cycles
> then
> | > | there should be no reason to write the value there.  If your card does pay
> | > | attention to the configuration space access cycles it should be trivial to
> | > | make this work.
> | >
> | > The card does pay attention, and other programs such as lspci and the
> | > like also look at the config space.  They should definitely be kept
> | > in sync, and config writes are fairly cheap, anyway.
> | 
> | Well this is a rathole so it really isn't safe for lspci to play with
> | (races with the kernel accessing it)
>
> Displaying something that might change is a fact of life, and no
> different than the PCI world.  It's still best to keep things as
> correct as possible.

No.  I was thinking of the rat hole in pci config space you have to
access to read these registers.  You have to actively write a pci
config value to select which register you are going to read.

So by default it is not safe to touch this value from user space,
because you could mess up the kernel, if the kernel is updating the
value.

Eric

Re: 2.6.19-rc4: known unfixed regressions (v3)

[Dave Olson]

On Tue, 7 Nov 2006, Eric W. Biederman wrote:
| > Displaying something that might change is a fact of life, and no
| > different than the PCI world.  It's still best to keep things as
| > correct as possible.
| 
| No.  I was thinking of the rat hole in pci config space you have to
| access to read these registers.  You have to actively write a pci
| config value to select which register you are going to read.
| 
| So by default it is not safe to touch this value from user space,
| because you could mess up the kernel, if the kernel is updating the
| value.

Nonetheless, as root, lspci already does that (it displays the MSI
interrupt info).  I  wasn't talking about fixing that, just saying
that having the data being as correct as possible, is highly
desirable.   We can't know everything that everybody is doing with
the data.

Improvements in the pciutils library and locking with respect to the
kernel may well be desirable, but are an independent issue from
correctness.

Dave Olson
dave.olson@qlogic.com

Re: 2.6.19-rc4: known unfixed regressions (v3)

[Eric W. Biederman]

Dave Olson <olson@pathscale.com> writes:

> On Tue, 7 Nov 2006, Eric W. Biederman wrote:
> | > Displaying something that might change is a fact of life, and no
> | > different than the PCI world.  It's still best to keep things as
> | > correct as possible.
> | 
> | No.  I was thinking of the rat hole in pci config space you have to
> | access to read these registers.  You have to actively write a pci
> | config value to select which register you are going to read.
> | 
> | So by default it is not safe to touch this value from user space,
> | because you could mess up the kernel, if the kernel is updating the
> | value.
>
> Nonetheless, as root, lspci already does that (it displays the MSI
> interrupt info).  I  wasn't talking about fixing that, just saying
> that having the data being as correct as possible, is highly
> desirable.   We can't know everything that everybody is doing with
> the data.

I think we are talking past each other.  I think it is fine but silly
to set a standard register that isn't actually used.  It probably makes
debugging a little easier but it might also make things a little more
confusing because we are doing something totally unnecessary.

The pci capability is fine.  The issue with the hyptertrasnport interrupt
capability is that it is 8 bytes long and controls up to 1024 bytes of data.
It is not nor can I ever it image it being safe for lspci to write the
window address register to read back the interrupt routing register.
Someone poking at this with setpci and lspci is fine.

In general reads of random registers are racy but harmless.  Writes of
registers that the kernel needs to have a specific value should never
ever be done by default, because bad nasty things may happen.  It is
a very good way to shoot yourself in the foot.

> Improvements in the pciutils library and locking with respect to the
> kernel may well be desirable, but are an independent issue from
> correctness.

This is not a race issue this is a true correctness issue.  There
is an address register and a data register.  It will never be correct
for any user space program to write to the address register without
first proving that the kernel does not care what value that register
takes on, or the user has sufficient privileges and says do it anyway
I know what I am doing.

These are not ordinary pci config space registers, although they are standard
registers for hypertransport devices.


Eric

Re: 2.6.19-rc4: known unfixed regressions (v3)

[Dave Olson]

On Tue, 7 Nov 2006, Eric W. Biederman wrote:
| I think we are talking past each other.  I think it is fine but silly
| to set a standard register that isn't actually used.  It probably makes
| debugging a little easier but it might also make things a little more
| confusing because we are doing something totally unnecessary.

I think we are saying exactly the same thing, so I'll leave it at that.

Dave Olson
dave.olson@qlogic.com

Re: 2.6.19-rc4: known unfixed regressions (v3)

[Eric W. Biederman]

Dave Olson <olson@pathscale.com> writes:

> On Tue, 7 Nov 2006, Eric W. Biederman wrote:
> | I think we are talking past each other.  I think it is fine but silly
> | to set a standard register that isn't actually used.  It probably makes
> | debugging a little easier but it might also make things a little more
> | confusing because we are doing something totally unnecessary.
>
> I think we are saying exactly the same thing, so I'll leave it at that.

Ok.  I wish it was clear to me that you understood my concerns but you aren't
writing a patch for lspci so it really doesn't matter.

Eric

Re: 2.6.19-rc4: known unfixed regressions (v3)

[Bryan O'Sullivan]

Eric W. Biederman wrote:

> If you really need to write to both the config space registers and your
> magic shadow copy of the register I can certainly do the config space
> writes for you.  I just figured it would be more efficient not to.

Yes, we need to do both.

I've got code that refactors your patch a little as I try to get the 
driver happy, but so far it's not seeing any interrupts.  I'll keep you 
posted.

	<b

Re: 2.6.19-rc4: known unfixed regressions (v3)

[Eric W. Biederman]

"Bryan O'Sullivan" <bos@serpentine.com> writes:

> Eric W. Biederman wrote:
>
>> If you really need to write to both the config space registers and your
>> magic shadow copy of the register I can certainly do the config space
>> writes for you.  I just figured it would be more efficient not to.
>
> Yes, we need to do both.
>
> I've got code that refactors your patch a little as I try to get the driver
> happy, but so far it's not seeing any interrupts.  I'll keep you posted.

Ok.  Thanks.

Eric

Re: 2.6.19-rc4: known unfixed regressions (v3)

[Bryan O'Sullivan]

[-- Attachment #1: Type: text/plain, Size: 600 bytes --]

Eric W. Biederman wrote:

> If you really need to write to both the config space registers and your
> magic shadow copy of the register I can certainly do the config space
> writes for you.

Here's an updated copy of your second patch that does just that.

I've also included a preview of the ipath patch that depends on this. 
With your original patch, my rework of your second patch, and the new 
ipath patch, the driver is back to working happily for me on top of 
current -git.

I need to test the ipath patch on powerpc before I consider it cooked, 
but I won't have time to do that today.

	<b

[-- Attachment #2: htirq-allow-buggy-drivers-of-buggy-hardware-to-write-the-registers.patch --]
[-- Type: text/x-patch, Size: 3617 bytes --]

From: ebiederm@xmission.com (Eric W. Biederman)

This patch adds a variant of ht_create_irq, __ht_create_irq, that takes
an additional parameter, update, that is a function that is called after
we have updated a driver's htirq configuration registers.

This is needed to support the ipath_iba6110, which has an interrupt
config register that is not connected to the hardware that controls
interrupt delivery.

Signed-off-by: Bryan O'Sullivan <bryan.osullivan@qlogic.com>
Cc: Dave Olson <dave.olson@qlogic.com>

diff -r 5f5c47730ce4 drivers/pci/htirq.c
--- a/drivers/pci/htirq.c	Tue Nov 07 07:45:59 2006 -0800
+++ b/drivers/pci/htirq.c	Tue Nov 07 11:33:27 2006 -0800
@@ -25,6 +25,8 @@ static DEFINE_SPINLOCK(ht_irq_lock);
 
 struct ht_irq_cfg {
 	struct pci_dev *dev;
+	 /* Update callback used to cope with buggy hardware */
+	ht_irq_update_t *update;
 	unsigned pos;
 	unsigned idx;
 	struct ht_irq_msg msg;
@@ -44,6 +46,8 @@ void write_ht_irq_msg(unsigned int irq, 
 		pci_write_config_byte(cfg->dev, cfg->pos + 2, cfg->idx + 1);
 		pci_write_config_dword(cfg->dev, cfg->pos + 4, msg->address_hi);
 	}
+	if (cfg->update)
+		cfg->update(cfg->dev, irq, msg);
 	spin_unlock_irqrestore(&ht_irq_lock, flags);
 	cfg->msg = *msg;
 }
@@ -79,16 +83,14 @@ void unmask_ht_irq(unsigned int irq)
 }
 
 /**
- * ht_create_irq - create an irq and attach it to a device.
+ * __ht_create_irq - create an irq and attach it to a device.
  * @dev: The hypertransport device to find the irq capability on.
  * @idx: Which of the possible irqs to attach to.
- *
- * ht_create_irq is needs to be called for all hypertransport devices
- * that generate irqs.
+ * @update: Function to be called when changing the htirq message
  *
  * The irq number of the new irq or a negative error value is returned.
  */
-int ht_create_irq(struct pci_dev *dev, int idx)
+int __ht_create_irq(struct pci_dev *dev, int idx, ht_irq_update_t *update)
 {
 	struct ht_irq_cfg *cfg;
 	unsigned long flags;
@@ -123,6 +125,7 @@ int ht_create_irq(struct pci_dev *dev, i
 		return -ENOMEM;
 
 	cfg->dev = dev;
+	cfg->update = update;
 	cfg->pos = pos;
 	cfg->idx = 0x10 + (idx * 2);
 	/* Initialize msg to a value that will never match the first write. */
@@ -145,6 +148,21 @@ int ht_create_irq(struct pci_dev *dev, i
 }
 
 /**
+ * ht_create_irq - create an irq and attach it to a device.
+ * @dev: The hypertransport device to find the irq capability on.
+ * @idx: Which of the possible irqs to attach to.
+ *
+ * ht_create_irq needs to be called for all hypertransport devices
+ * that generate irqs.
+ *
+ * The irq number of the new irq or a negative error value is returned.
+ */
+int ht_create_irq(struct pci_dev *dev, int idx)
+{
+	return __ht_create_irq(dev, idx, NULL);
+}
+
+/**
  * ht_destroy_irq - destroy an irq created with ht_create_irq
  *
  * This reverses ht_create_irq removing the specified irq from
@@ -162,5 +180,6 @@ void ht_destroy_irq(unsigned int irq)
 	kfree(cfg);
 }
 
+EXPORT_SYMBOL(__ht_create_irq);
 EXPORT_SYMBOL(ht_create_irq);
 EXPORT_SYMBOL(ht_destroy_irq);
diff -r 5f5c47730ce4 include/linux/htirq.h
--- a/include/linux/htirq.h	Tue Nov 07 07:45:59 2006 -0800
+++ b/include/linux/htirq.h	Tue Nov 07 11:33:34 2006 -0800
@@ -15,4 +15,9 @@ void unmask_ht_irq(unsigned int irq);
 /* The arch hook for getting things started */
 int arch_setup_ht_irq(unsigned int irq, struct pci_dev *dev);
 
+/* For drivers of buggy hardware */
+typedef void (ht_irq_update_t)(struct pci_dev *dev, int irq,
+			       struct ht_irq_msg *msg);
+int __ht_create_irq(struct pci_dev *dev, int idx, ht_irq_update_t *update);
+
 #endif /* LINUX_HTIRQ_H */

[-- Attachment #3: ipath-htirq.patch --]
[-- Type: text/x-patch, Size: 6676 bytes --]

IB/ipath - program interrupt control register using new htirq hook

Eric's changes to the htirq infrastructure require corresponding
modifications to the ipath HT driver code so that interrupts are still
delivered properly.

Signed-off-by: Bryan O'Sullivan <bryan.osullivan@qlogic.com>
Cc: Eric W. Biedermann <ebiederm@xmission.com>

diff -r bb12c8d85f7c drivers/infiniband/hw/ipath/ipath_driver.c
--- a/drivers/infiniband/hw/ipath/ipath_driver.c	Tue Nov 07 11:35:24 2006 -0800
+++ b/drivers/infiniband/hw/ipath/ipath_driver.c	Tue Nov 07 11:44:23 2006 -0800
@@ -467,15 +467,15 @@ static int __devinit ipath_init_one(stru
 	 * check 0 irq after we return from chip-specific bus setup, since
 	 * that can affect this due to setup
 	 */
-	if (!pdev->irq)
+	if (!dd->ipath_irq)
 		ipath_dev_err(dd, "irq is 0, BIOS error?  Interrupts won't "
 			      "work\n");
 	else {
-		ret = request_irq(pdev->irq, ipath_intr, IRQF_SHARED,
+		ret = request_irq(dd->ipath_irq, ipath_intr, IRQF_SHARED,
 				  IPATH_DRV_NAME, dd);
 		if (ret) {
 			ipath_dev_err(dd, "Couldn't setup irq handler, "
-				      "irq=%u: %d\n", pdev->irq, ret);
+				      "irq=%d: %d\n", dd->ipath_irq, ret);
 			goto bail_iounmap;
 		}
 	}
@@ -615,12 +615,15 @@ static void __devexit ipath_remove_one(s
 static void __devexit ipath_remove_one(struct pci_dev *pdev)
 {
 	struct ipath_devdata *dd = pci_get_drvdata(pdev);
+	int irq;
 
 	ipath_cdbg(VERBOSE, "removing, pdev=%p, dd=%p\n", pdev, dd);
 
 	if (dd->verbs_dev)
 		ipath_unregister_ib_device(dd->verbs_dev);
 
+	irq = dd->ipath_irq;
+	
 	ipath_diag_remove(dd);
 	ipath_user_remove(dd);
 	ipathfs_remove_device(dd);
@@ -637,11 +640,11 @@ static void __devexit ipath_remove_one(s
 	 * free up port 0 (kernel) rcvhdr, egr bufs, and eventually tid bufs
 	 * for all versions of the driver, if they were allocated
 	 */
-	if (pdev->irq) {
+	if (irq) {
 		ipath_cdbg(VERBOSE,
-			   "unit %u free_irq of irq %x\n",
-			   dd->ipath_unit, pdev->irq);
-		free_irq(pdev->irq, dd);
+			   "unit %u free_irq of irq %d\n",
+			   dd->ipath_unit, irq);
+		free_irq(irq, dd);
 	} else
 		ipath_dbg("irq is 0, not doing free_irq "
 			  "for unit %u\n", dd->ipath_unit);
diff -r bb12c8d85f7c drivers/infiniband/hw/ipath/ipath_iba6110.c
--- a/drivers/infiniband/hw/ipath/ipath_iba6110.c	Tue Nov 07 11:35:24 2006 -0800
+++ b/drivers/infiniband/hw/ipath/ipath_iba6110.c	Tue Nov 07 11:44:23 2006 -0800
@@ -38,6 +38,7 @@
 
 #include <linux/pci.h>
 #include <linux/delay.h>
+#include <linux/htirq.h>
 
 #include "ipath_kernel.h"
 #include "ipath_registers.h"
@@ -913,49 +914,13 @@ static void slave_or_pri_blk(struct ipat
 	}
 }
 
-static int set_int_handler(struct ipath_devdata *dd, struct pci_dev *pdev,
-			    int pos)
-{
-	u32 int_handler_addr_lower;
-	u32 int_handler_addr_upper;
-	u64 ihandler;
-	u32 intvec;
-
-	/* use indirection register to get the intr handler */
-	pci_write_config_byte(pdev, pos + HT_INTR_REG_INDEX, 0x10);
-	pci_read_config_dword(pdev, pos + 4, &int_handler_addr_lower);
-	pci_write_config_byte(pdev, pos + HT_INTR_REG_INDEX, 0x11);
-	pci_read_config_dword(pdev, pos + 4, &int_handler_addr_upper);
-
-	ihandler = (u64) int_handler_addr_lower |
-		((u64) int_handler_addr_upper << 32);
-
-	/*
-	 * kernels with CONFIG_PCI_MSI set the vector in the irq field of
-	 * struct pci_device, so we use that to program the internal
-	 * interrupt register (not config space) with that value. The BIOS
-	 * must still have done the basic MSI setup.
-	 */
-	intvec = pdev->irq;
-	/*
-	 * clear any vector bits there; normally not set but we'll overload
-	 * this for some debug purposes (setting the HTC debug register
-	 * value from software, rather than GPIOs), so it might be set on a
-	 * driver reload.
-	 */
-	ihandler &= ~0xff0000;
-	/* x86 vector goes in intrinfo[23:16] */
-	ihandler |= intvec << 16;
-	ipath_cdbg(VERBOSE, "ihandler lower %x, upper %x, intvec %x, "
-		   "interruptconfig %llx\n", int_handler_addr_lower,
-		   int_handler_addr_upper, intvec,
-		   (unsigned long long) ihandler);
-
-	/* can't program yet, so save for interrupt setup */
-	dd->ipath_intconfig = ihandler;
-	/* keep going, so we find link control stuff also */
-
-	return ihandler != 0;
+static void ipath_ht_irq_update(struct pci_dev *dev, int irq,
+				struct ht_irq_msg *msg)
+{
+	struct ipath_devdata *dd = pci_get_drvdata(dev);
+
+	dd->ipath_intconfig = msg->address_lo;
+	dd->ipath_intconfig |= ((u64) msg->address_hi) << 32;
 }
 
 /**
@@ -971,12 +936,19 @@ static int ipath_setup_ht_config(struct 
 static int ipath_setup_ht_config(struct ipath_devdata *dd,
 				 struct pci_dev *pdev)
 {
-	int pos, ret = 0;
-	int ihandler = 0;
-
-	/*
-	 * Read the capability info to find the interrupt info, and also
-	 * handle clearing CRC errors in linkctrl register if necessary.  We
+	int pos, ret;
+
+	ret = __ht_create_irq(pdev, 0, ipath_ht_irq_update);
+	if (ret < 0) {
+		ipath_dev_err(dd, "Couldn't create interrupt handler: "
+			      "err %d\n", ret);
+		goto bail;
+	}
+	dd->ipath_irq = ret;
+	ret = 0;
+
+	/*
+	 * Handle clearing CRC errors in linkctrl register if necessary.  We
 	 * do this early, before we ever enable errors or hardware errors,
 	 * mostly to avoid causing the chip to enter freeze mode.
 	 */
@@ -1000,16 +972,8 @@ static int ipath_setup_ht_config(struct 
 		}
 		if (!(cap_type & 0xE0))
 			slave_or_pri_blk(dd, pdev, pos, cap_type);
-		else if (cap_type == HT_INTR_DISC_CONFIG)
-			ihandler = set_int_handler(dd, pdev, pos);
 	} while ((pos = pci_find_next_capability(pdev, pos,
 						 PCI_CAP_ID_HT)));
-
-	if (!ihandler) {
-		ipath_dev_err(dd, "Couldn't find interrupt handler in "
-			      "config space\n");
-		ret = -ENODEV;
-	}
 
 bail:
 	return ret;
diff -r bb12c8d85f7c drivers/infiniband/hw/ipath/ipath_iba6120.c
--- a/drivers/infiniband/hw/ipath/ipath_iba6120.c	Tue Nov 07 11:35:24 2006 -0800
+++ b/drivers/infiniband/hw/ipath/ipath_iba6120.c	Tue Nov 07 11:45:00 2006 -0800
@@ -851,6 +851,7 @@ static int ipath_setup_pe_config(struct 
 	int pos, ret;
 
 	dd->ipath_msi_lo = 0;	/* used as a flag during reset processing */
+	dd->ipath_irq = pdev->irq;
 	ret = pci_enable_msi(dd->pcidev);
 	if (ret)
 		ipath_dev_err(dd, "pci_enable_msi failed: %d, "
diff -r bb12c8d85f7c drivers/infiniband/hw/ipath/ipath_kernel.h
--- a/drivers/infiniband/hw/ipath/ipath_kernel.h	Tue Nov 07 11:35:24 2006 -0800
+++ b/drivers/infiniband/hw/ipath/ipath_kernel.h	Tue Nov 07 11:44:23 2006 -0800
@@ -328,6 +328,7 @@ struct ipath_devdata {
 	/* so we can rewrite it after a chip reset */
 	u32 ipath_pcibar1;
 
+	int ipath_irq;
 	/* HT/PCI Vendor ID (here for NodeInfo) */
 	u16 ipath_vendorid;
 	/* HT/PCI Device ID (here for NodeInfo) */

Re: 2.6.19-rc4: known unfixed regressions (v3)

[Eric W. Biederman]

"Bryan O'Sullivan" <bos@serpentine.com> writes:

> Eric W. Biederman wrote:
>
>> If you really need to write to both the config space registers and your
>> magic shadow copy of the register I can certainly do the config space
>> writes for you.
>
> Here's an updated copy of your second patch that does just that.
>
> I've also included a preview of the ipath patch that depends on this. With your
> original patch, my rework of your second patch, and the new ipath patch, the
> driver is back to working happily for me on top of current -git.
>
> I need to test the ipath patch on powerpc before I consider it cooked, but I
> won't have time to do that today.

Ok.  It looks good except you aren't calling ht_destroy_irq on driver unload.
Which is a small resource leak.

Cool looks like we have got this one.

Eric

Re: 2.6.19-rc4: known unfixed regressions (v3)

[Bryan O'Sullivan]

Eric W. Biederman wrote:

> Ok.  It looks good except you aren't calling ht_destroy_irq on driver unload.
> Which is a small resource leak.

Yeah, I'm also not reprogramming that register if the interrupt routing 
changes.  Ran out of time today.  I'll fix those tomorrow.

	<b

Re: 2.6.19-rc4: known unfixed regressions (v3)

[Eric W. Biederman]

"Bryan O'Sullivan" <bos@serpentine.com> writes:

> Eric W. Biederman wrote:
>
>> Ok.  It looks good except you aren't calling ht_destroy_irq on driver unload.
>> Which is a small resource leak.
>
> Yeah, I'm also not reprogramming that register if the interrupt routing changes.
> Ran out of time today.  I'll fix those tomorrow.

Good point.  You generate the value and then never put it anywhere...
Anyway Andrew appears to have the rest of the fixes so this should be
easy to finish.

Eric

Re: 2.6.19-rc4: known unfixed regressions (v3)

[Eric W. Biederman]

Adrian Bunk <bunk@stusta.de> writes:

>
> Subject    : x86_64: NR_IRQ increase causes 11.5% slowdown
>                      in lmbench's fork benchmark
> References : http://lkml.org/lkml/2006/11/2/192
> Submitter  : Tim Chen <tim.c.chen@linux.intel.com>
> Caused-By  : Eric W. Biederman <ebiederm@xmission.com>
>              commit 550f2299ac8ffaba943cf211380d3a8d3fa75301
> Handled-By : Eric W. Biederman <ebiederm@xmission.com>
>              Andi Kleen <ak@suse.de>
> Status     : problem is being debugged

Currently I'm at a loss why the cross cpu fork lm_bench numbers should get
worse when you simply double NR_IRQS.  As far as I can determine nothing
on that code path is directly affected by that change.

Eric

2.6.19-rc4: known regressions with patches (v2)

[Adrian Bunk]

Both of the patches below were already available when 2.6.19-rc4 was 
released.

The DVB patch was was sent as part of a DVB update Linus didn't pull for 
unknown reasons.

The s390 patch seems to await being forwarded by the s390 maintainers.


This email lists some known regressions in 2.6.19-rc4 compared to 2.6.18
with patches available.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : s390: DCSS support breakage
References : http://lkml.org/lkml/2006/10/27/89
Submitter  : Carsten Otte <cotte@de.ibm.com>
Caused-By  : Heiko Carstens <heiko.carstens@de.ibm.com>
             commit 7676bef9c183fd573822cac9992927ef596d584c
Handled-By : Heiko Carstens <heiko.carstens@de.ibm.com>
Patch      : http://lkml.org/lkml/2006/10/27/89
Status     : patch to revert the commit available


Subject    : DVB frontend selection causes compile errors
References : http://lkml.org/lkml/2006/10/8/244
Submitter  : Adrian Bunk <bunk@stusta.de>
Caused-By  : "Andrew de Quincey" <adq_dvb@lidskialf.net>
             commit 176ac9da4f09820a43fd48f0e74b1486fc3603ba
Handled-By : Trent Piepho <xyzzy@speakeasy.org>
Patch      : http://lkml.org/lkml/2006/10/14/157
Status     : patch available

2.6.19-rc4: known unfixed regressions (v4)

[Adrian Bunk]

This email lists some known regressions in 2.6.19-rc compared to 2.6.18
that are not yet fixed in Linus' tree.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : ThinkPad R50p: boot fail with (lapic && on_battery)
References : http://lkml.org/lkml/2006/10/31/333
Submitter  : Ernst Herzberg <earny@net4u.de>
Handled-By : Len Brown <len.brown@intel.com>
Status     : problem is being debugged


Subject    : ThinkPad T60: no screen after resume
References : http://mail.matrix.de/pipermail/linux-thinkpad/2006-November/037011.html
Submitter  : Martin Lorenz <martin@lorenz.eu.org>
Status     : unknown


Subject    : ThinkPad T60: lose ACPI events after suspend/resume
References : http://lkml.org/lkml/2006/10/10/39
             http://bugzilla.kernel.org/show_bug.cgi?id=7408
Submitter  : Martin Lorenz <martin@lorenz.eu.org>
Status     : problem might be fixed by
             commit f9dadfa71bc594df09044da61d1c72701121d802


Subject    : i386: more DWARFs and strange messages
References : http://lkml.org/lkml/2006/10/29/127
Submitter  : Martin Lorenz <martin@lorenz.eu.org>
Status     : should be fixed by
             commit 4b96b1a10cb00c867103b21f0f2a6c91b705db11


Subject    : BUG: scheduling while atomic: events/0/0x00000001/4, etc..
References : http://lkml.org/lkml/2006/11/2/209
Submitter  : Paolo Ornati <ornati@fastwebnet.it>
Status     : unknown


Subject    : sata-via doesn't detect anymore disks attached to VIA vt6421
References : http://bugzilla.kernel.org/show_bug.cgi?id=7255
Submitter  : Thierry Vignaud <tvignaud@mandriva.com>
Status     : unknown


Subject    : unable to rip cd
References : http://lkml.org/lkml/2006/10/13/100
Submitter  : Alex Romosan <romosan@sycorax.lbl.gov>
Status     : unknown


Subject    : x86_64: oprofile doesn't work
References : http://lkml.org/lkml/2006/10/27/3
Submitter  : Prakash Punnoor <prakash@punnoor.de>
Status     : unknown


Subject    : x86_64: NR_IRQ increase causes 11.5% slowdown
                     in lmbench's fork benchmark
References : http://lkml.org/lkml/2006/11/2/192
Submitter  : Tim Chen <tim.c.chen@linux.intel.com>
Caused-By  : Eric W. Biederman <ebiederm@xmission.com>
             commit 550f2299ac8ffaba943cf211380d3a8d3fa75301
Status     : unknown


Subject    : PCI: MMCONFIG breakage
References : http://lkml.org/lkml/2006/10/27/251
Submitter  : Jeff Chua <jeff.chua.linux@gmail.com>
Handled-By : Andi Kleen <ak@suse.de>
Status     : Andi is investigating, both BIOS and Direct work


Subject    : SMP kernel can not generate ISA irq properly
References : http://lkml.org/lkml/2006/10/22/15
Submitter  : Komuro <komurojun-mbn@nifty.com>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Status     : Thomas is investigating


Subject    : ipath driver MCEs system on load when HT chip present
References : http://bugzilla.kernel.org/show_bug.cgi?id=7455
Submitter  : Bryan O'Sullivan <bos@serpentine.com>
Caused-By  : Eric W. Biederman <ebiederm@xmission.com>
Handled-By : Bryan O'Sullivan <bos@serpentine.com>
             Eric W. Biederman <ebiederm@xmission.com>
Status     : Bryan and Eric are working on fixing the ipath driver


Subject    : boot hang in the microcode driver
References : http://lkml.org/lkml/2006/11/6/117
Submitter  : Arjan van de Ven <arjan@linux.intel.com>
Caused-By  : Shaohua Li <shaohua.li@intel.com>
             commit a30a6a2cb0fdc2c9701d6ddfb21affeb8146c038
Handled-By : Arjan van de Ven <arjan@linux.intel.com>
Patch      : http://lkml.org/lkml/2006/11/6/117
Status     : workaround-patch available

Re: [linux-pm] 2.6.19-rc4: known unfixed regressions (v3)

[Adrian Bunk]

On Tue, Nov 07, 2006 at 09:05:36PM +0100, Ernst Herzberg wrote:
> On Tuesday 07 November 2006 06:41, Len Brown wrote:
> > On Monday 06 November 2006 21:17, Ernst Herzberg wrote:
> > > On Sunday 05 November 2006 07:48, Adrian Bunk wrote:
> > > > ...
> > > > Subject    : ThinkPad R50p: boot fail with (lapic && on_battery)
> > > > References : http://lkml.org/lkml/2006/10/31/333
> > > > Submitter  : Ernst Herzberg <earny@net4u.de>
> > > > Status     : problem is being debugged
> 
> First i made shure again that 2.6.18.2 works..... damn shure.
> 
> >
> > Please test if booting with "processor.max_cstate=1" makes any
> > difference
> 
> --> NO.
> 
> > Please test if building with CONFIG_CPU_FREQ=n makes any difference.
> 
> --> NO.
> 
> > Also, please make sure that booting with "apm=off" makes no difference
> > -- there is a bug where the APM code is not currently disabled in ACPI
> > mode, and who knows what effect that may have...
> 
> Ahem. All previous tests was done with CONFIG_APM=n. So i tested with 
> CONFIG_APM=y. Does not help. It makes no difference booting with "apm=off" 
> or not.
> 
> Another check:
> 
> The laptop muste be powered on on_battery to trigger the problem. If i 
> disconnect AC at the grub-prompt the problem does _not_ occur.
> 
> The laptop has two batteries. The utraybay battery is nearly dead now, but 
> it makes no difference if removed.
> 
> This problem is not very important for me, i just wondering why is only 
> occurs if running on battery. I would be happy, if someone can explain 
> this;-) 
> 
> The laptop itself is rock stable (if he boots), never seen any glitch or 
> instability (with lapic). I don't know exactly when i started using lapic. 
> Its a long time ago (last year?), i have read the message that i can 
> enable this so i did. No problems until 2.6.19-rc1....
> 
> If nobody can reproduce this, i don't care about the problem. There is also 
> a life without lapic:) But maybe it shows a problem anywhere else, timing 
> or whatever, so i'm willing to test everything against.


There's exactly the important point:
It's interesting to work out (e.g. by a successfull bisecting) _what_ 
broke it.

"OK, we understand what's going on, and it's a surprise that lapic ever 
worked for you." is a possible result.

But it's also possible that it's only one symptom of some serious 
problem - a buggy part of Andi's APIC cleanups has just been fixed, and 
Martin seems to run from one problem into the next on his ThinkPad, 
so getting your problem debugged might also help other people.


> So if someone is interesting to reproduce the problem, i repeat the 
> conditions that must be met:
> 
> 1.: Laptop must be powered on with AC removed (on battery)
> 
> 2.: BIOS-Setting must be
>   power --> Intel Speedstep --> Mode on Battery --> "Max Battery"
> 
> 3.: Kernel command line must have "lapci"
> 
> 4.: Kernel must be >= 2.6.19-rc1
> 
> dmidecode: (maybe that helps?)
> 
> # dmidecode 2.8
> SMBIOS 2.33 present.
> 61 structures occupying 2127 bytes.
> Table at 0x000E0010.
> 
> Handle 0x0000, DMI type 0, 20 bytes
> BIOS Information
> 	Vendor: IBM
> 	Version: 1RETDPWW (3.21 )
> 	Release Date: 06/02/2006
> 	Address: 0xDC000
> 	Runtime Size: 144 kB
> 	ROM Size: 1024 kB
> 	Characteristics:
> 		PCI is supported
> 		PC Card (PCMCIA) is supported
> 		PNP is supported
> 		APM is supported
> 		BIOS is upgradeable
> 		BIOS shadowing is allowed
> 		ESCD support is available
> 		Boot from CD is supported
> 		Selectable boot is supported
> 		EDD is supported
> 		3.5"/720 KB floppy services are supported (int 13h)
> 		Print screen service is supported (int 5h)
> 		8042 keyboard services are supported (int 9h)
> 		Serial services are supported (int 14h)
> 		Printer services are supported (int 17h)
> 		CGA/mono video services are supported (int 10h)
> 		ACPI is supported
> 		USB legacy is supported
> 		AGP is supported
> 		BIOS boot specification is supported
> 
> Handle 0x0001, DMI type 1, 25 bytes
> System Information
> 	Manufacturer: IBM
> 	Product Name: 183222G
> 	Version: ThinkPad R50p
> 	Serial Number: 99DR993
> 	UUID: 5532DC80-466C-11CB-B373-95CD80E5548B
> 	Wake-up Type: Power Switch
> 
> Handle 0x0002, DMI type 2, 8 bytes
> Base Board Information
> 	Manufacturer: IBM
> 	Product Name: 183222G
> 	Version: Not Available
> 	Serial Number: J1V9545B13X
> 
> Handle 0x0003, DMI type 3, 17 bytes
> Chassis Information
> 	Manufacturer: IBM
> 	Type: Notebook
> 	Lock: Not Present
> 	Version: Not Available
> 	Serial Number: Not Available
> 	Asset Tag: No Asset Information
> 	Boot-up State: Unknown
> 	Power Supply State: Unknown
> 	Thermal State: Unknown
> 	Security Status: Unknown
> 	OEM Information: 0x00000000
> 
> Handle 0x0004, DMI type 126, 17 bytes
> Inactive
> 
> Handle 0x0005, DMI type 126, 17 bytes
> Inactive
> 
> Handle 0x0006, DMI type 4, 35 bytes
> Processor Information
> 	Socket Designation: None
> 	Type: Central Processor
> 	Family: Pentium M
> 	Manufacturer: GenuineIntel
> 	ID: 95 06 00 00 BF F9 E9 A7
> 	Signature: Type 0, Family 6, Model 9, Stepping 5
> 	Flags:
> 		FPU (Floating-point unit on-chip)
> 		VME (Virtual mode extension)
> 		DE (Debugging extension)
> 		PSE (Page size extension)
> 		TSC (Time stamp counter)
> 		MSR (Model specific registers)
> 		MCE (Machine check exception)
> 		CX8 (CMPXCHG8 instruction supported)
> 		SEP (Fast system call)
> 		MTRR (Memory type range registers)
> 		PGE (Page global enable)
> 		MCA (Machine check architecture)
> 		CMOV (Conditional move instruction supported)
> 		PAT (Page attribute table)
> 		CLFSH (CLFLUSH instruction supported)
> 		DS (Debug store)
> 		ACPI (ACPI supported)
> 		MMX (MMX technology supported)
> 		FXSR (Fast floating-point save and restore)
> 		SSE (Streaming SIMD extensions)
> 		SSE2 (Streaming SIMD extensions 2)
> 		TM (Thermal monitor supported)
> 		PBE (Pending break enabled)
> 	Version: Intel(R) Pentium(R) M processor
> 	Voltage: 1.5 V
> 	External Clock: 400 MHz
> 	Max Speed: 1700 MHz
> 	Current Speed: 1700 MHz
> 	Status: Populated, Enabled
> 	Upgrade: None
> 	L1 Cache Handle: 0x000A
> 	L2 Cache Handle: 0x000B
> 	L3 Cache Handle: Not Provided
> 	Serial Number: Not Specified
> 	Asset Tag: Not Specified
> 	Part Number: Not Specified
> 
> Handle 0x0007, DMI type 5, 20 bytes
> Memory Controller Information
> 	Error Detecting Method: None
> 	Error Correcting Capabilities:
> 		None
> 	Supported Interleave: One-way Interleave
> 	Current Interleave: One-way Interleave
> 	Maximum Memory Module Size: 1024 MB
> 	Maximum Total Memory Size: 2048 MB
> 	Supported Speeds:
> 		Other
> 	Supported Memory Types:
> 		DIMM
> 		SDRAM
> 	Memory Module Voltage: 2.9 V
> 	Associated Memory Slots: 2
> 		0x0008
> 		0x0009
> 	Enabled Error Correcting Capabilities:
> 		None
> 
> Handle 0x0008, DMI type 6, 12 bytes
> Memory Module Information
> 	Socket Designation: DIMM Slot 1
> 	Bank Connections: 0 1
> 	Current Speed: Unknown
> 	Type: DIMM SDRAM
> 	Installed Size: 512 MB (Double-bank Connection)
> 	Enabled Size: 512 MB (Double-bank Connection)
> 	Error Status: OK
> 
> Handle 0x0009, DMI type 6, 12 bytes
> Memory Module Information
> 	Socket Designation: DIMM Slot 2
> 	Bank Connections: 2 3
> 	Current Speed: Unknown
> 	Type: DIMM SDRAM
> 	Installed Size: 512 MB (Double-bank Connection)
> 	Enabled Size: 512 MB (Double-bank Connection)
> 	Error Status: OK
> 
> Handle 0x000A, DMI type 7, 19 bytes
> Cache Information
> 	Socket Designation: Internal L1 Cache
> 	Configuration: Enabled, Socketed, Level 1
> 	Operational Mode: Write Back
> 	Location: Internal
> 	Installed Size: 32 KB
> 	Maximum Size: 32 KB
> 	Supported SRAM Types:
> 		Synchronous
> 	Installed SRAM Type: Synchronous
> 	Speed: Unknown
> 	Error Correction Type: Unknown
> 	System Type: Other
> 	Associativity: 8-way Set-associative
> 
> Handle 0x000B, DMI type 7, 19 bytes
> Cache Information
> 	Socket Designation: Internal L2 Cache
> 	Configuration: Enabled, Socketed, Level 2
> 	Operational Mode: Write Back
> 	Location: Internal
> 	Installed Size: 1024 KB
> 	Maximum Size: 1024 KB
> 	Supported SRAM Types:
> 		Burst
> 	Installed SRAM Type: Burst
> 	Speed: Unknown
> 	Error Correction Type: Multi-bit ECC
> 	System Type: Unified
> 	Associativity: 8-way Set-associative
> 
> Handle 0x000C, DMI type 126, 9 bytes
> Inactive
> 
> Handle 0x000D, DMI type 8, 9 bytes
> Port Connector Information
> 	Internal Reference Designator: Not Available
> 	Internal Connector Type: None
> 	External Reference Designator: Infrared
> 	External Connector Type: Infrared
> 	Port Type: Other
> 
> Handle 0x000E, DMI type 8, 9 bytes
> Port Connector Information
> 	Internal Reference Designator: Not Available
> 	Internal Connector Type: None
> 	External Reference Designator: Parallel
> 	External Connector Type: DB-25 female
> 	Port Type: Parallel Port ECP/EPP
> 
> Handle 0x000F, DMI type 8, 9 bytes
> Port Connector Information
> 	Internal Reference Designator: Not Available
> 	Internal Connector Type: None
> 	External Reference Designator: External Monitor
> 	External Connector Type: DB-15 female
> 	Port Type: Video Port
> 
> Handle 0x0010, DMI type 126, 9 bytes
> Inactive
> 
> Handle 0x0011, DMI type 126, 9 bytes
> Inactive
> 
> Handle 0x0012, DMI type 126, 9 bytes
> Inactive
> 
> Handle 0x0013, DMI type 126, 9 bytes
> Inactive
> 
> Handle 0x0014, DMI type 126, 9 bytes
> Inactive
> 
> Handle 0x0015, DMI type 8, 9 bytes
> Port Connector Information
> 	Internal Reference Designator: Not Available
> 	Internal Connector Type: None
> 	External Reference Designator: Microphone Jack
> 	External Connector Type: Mini Jack (headphones)
> 	Port Type: Audio Port
> 
> Handle 0x0016, DMI type 8, 9 bytes
> Port Connector Information
> 	Internal Reference Designator: Not Available
> 	Internal Connector Type: None
> 	External Reference Designator: Headphone Jack
> 	External Connector Type: Mini Jack (headphones)
> 	Port Type: Audio Port
> 
> Handle 0x0017, DMI type 8, 9 bytes
> Port Connector Information
> 	Internal Reference Designator: Not Available
> 	Internal Connector Type: None
> 	External Reference Designator: S-Video-Out
> 	External Connector Type: Other
> 	Port Type: Video Port
> 
> Handle 0x0018, DMI type 126, 9 bytes
> Inactive
> 
> Handle 0x0019, DMI type 8, 9 bytes
> Port Connector Information
> 	Internal Reference Designator: Not Available
> 	Internal Connector Type: None
> 	External Reference Designator: Modem
> 	External Connector Type: RJ-11
> 	Port Type: Modem Port
> 
> Handle 0x001A, DMI type 8, 9 bytes
> Port Connector Information
> 	Internal Reference Designator: Not Available
> 	Internal Connector Type: None
> 	External Reference Designator: Ethernet
> 	External Connector Type: RJ-45
> 	Port Type: Network Port
> 
> Handle 0x001B, DMI type 8, 9 bytes
> Port Connector Information
> 	Internal Reference Designator: Not Available
> 	Internal Connector Type: None
> 	External Reference Designator: USB 1
> 	External Connector Type: Access Bus (USB)
> 	Port Type: USB
> 
> Handle 0x001C, DMI type 8, 9 bytes
> Port Connector Information
> 	Internal Reference Designator: Not Available
> 	Internal Connector Type: None
> 	External Reference Designator: USB 2
> 	External Connector Type: Access Bus (USB)
> 	Port Type: USB
> 
> Handle 0x001D, DMI type 126, 9 bytes
> Inactive
> 
> Handle 0x001E, DMI type 126, 9 bytes
> Inactive
> 
> Handle 0x001F, DMI type 126, 9 bytes
> Inactive
> 
> Handle 0x0020, DMI type 126, 9 bytes
> Inactive
> 
> Handle 0x0021, DMI type 126, 9 bytes
> Inactive
> 
> Handle 0x0022, DMI type 9, 13 bytes
> System Slot Information
> 	Designation: CardBus Slot 1
> 	Type: 32-bit PC Card (PCMCIA)
> 	Current Usage: Available
> 	Length: Other
> 	ID: Adapter 0, Socket 0
> 	Characteristics:
> 		5.0 V is provided
> 		3.3 V is provided
> 		PC Card-16 is supported
> 		Cardbus is supported
> 		Zoom Video is supported
> 		Modem ring resume is supported
> 		PME signal is supported
> 		Hot-plug devices are supported
> 
> Handle 0x0023, DMI type 9, 13 bytes
> System Slot Information
> 	Designation: CardBus Slot 2
> 	Type: 32-bit PC Card (PCMCIA)
> 	Current Usage: Available
> 	Length: Other
> 	ID: Adapter 1, Socket 0
> 	Characteristics:
> 		5.0 V is provided
> 		3.3 V is provided
> 		PC Card-16 is supported
> 		Cardbus is supported
> 		Zoom Video is supported
> 		Modem ring resume is supported
> 		PME signal is supported
> 		Hot-plug devices are supported
> 
> Handle 0x0024, DMI type 126, 13 bytes
> Inactive
> 
> Handle 0x0025, DMI type 126, 13 bytes
> Inactive
> 
> Handle 0x0026, DMI type 9, 13 bytes
> System Slot Information
> 	Designation: Mini-PCI Slot 1
> 	Type: 32-bit PCI
> 	Current Usage: Available
> 	Length: Other
> 	ID: 1
> 	Characteristics:
> 		5.0 V is provided
> 		3.3 V is provided
> 		PME signal is supported
> 		SMBus signal is supported
> 
> Handle 0x0027, DMI type 126, 13 bytes
> Inactive
> 
> Handle 0x0028, DMI type 10, 6 bytes
> On Board Device Information
> 	Type: Other
> 	Status: Enabled
> 	Description: IBM Embedded Security hardware
> 
> Handle 0x0029, DMI type 11, 5 bytes
> OEM Strings
> 	String 1: IBM ThinkPad Embedded Controller -[1RHT71WW-3.04    ]-
> 
> Handle 0x002A, DMI type 13, 22 bytes
> BIOS Language Information
> 	Installable Languages: 1
> 		enUS
> 	Currently Installed Language: enUS
> 
> Handle 0x002B, DMI type 15, 25 bytes
> System Event Log
> 	Area Length: 0 bytes
> 	Header Start Offset: 0x0000
> 	Header Length: 16 bytes
> 	Data Start Offset: 0x0010
> 	Access Method: General-purpose non-volatile data functions
> 	Access Address: 0x0000
> 	Status: Invalid, Not Full
> 	Change Token: 0x00000004
> 	Header Format: Type 1
> 	Supported Log Type Descriptors: 1
> 	Descriptor 1: POST error
> 	Data Format 1: POST results bitmap
> 
> Handle 0x002C, DMI type 16, 15 bytes
> Physical Memory Array
> 	Location: System Board Or Motherboard
> 	Use: System Memory
> 	Error Correction Type: None
> 	Maximum Capacity: 1 GB
> 	Error Information Handle: Not Provided
> 	Number Of Devices: 2
> 
> Handle 0x002D, DMI type 17, 27 bytes
> Memory Device
> 	Array Handle: 0x002C
> 	Error Information Handle: No Error
> 	Total Width: 64 bits
> 	Data Width: 64 bits
> 	Size: 512 MB
> 	Form Factor: SODIMM
> 	Set: None
> 	Locator: DIMM 1
> 	Bank Locator: Bank 0/1
> 	Type: DDR
> 	Type Detail: Synchronous
> 	Speed: Unknown
> 	Manufacturer: Not Specified
> 	Serial Number: Not Specified
> 	Asset Tag: Not Specified
> 	Part Number: Not Specified
> 
> Handle 0x002E, DMI type 17, 27 bytes
> Memory Device
> 	Array Handle: 0x002C
> 	Error Information Handle: No Error
> 	Total Width: 64 bits
> 	Data Width: 64 bits
> 	Size: 512 MB
> 	Form Factor: SODIMM
> 	Set: None
> 	Locator: DIMM 2
> 	Bank Locator: Bank 2/3
> 	Type: DDR
> 	Type Detail: Synchronous
> 	Speed: Unknown
> 	Manufacturer: Not Specified
> 	Serial Number: Not Specified
> 	Asset Tag: Not Specified
> 	Part Number: Not Specified
> 
> Handle 0x002F, DMI type 18, 23 bytes
> 32-bit Memory Error Information
> 	Type: OK
> 	Granularity: Unknown
> 	Operation: Unknown
> 	Vendor Syndrome: Unknown
> 	Memory Array Address: Unknown
> 	Device Address: Unknown
> 	Resolution: Unknown
> 
> Handle 0x0030, DMI type 19, 15 bytes
> Memory Array Mapped Address
> 	Starting Address: 0x00000000000
> 	Ending Address: 0x0003FFFFFFF
> 	Range Size: 1 GB
> 	Physical Array Handle: 0x002C
> 	Partition Width: 0
> 
> Handle 0x0031, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00000000000
> 	Ending Address: 0x0001FFFFFFF
> 	Range Size: 512 MB
> 	Physical Device Handle: 0x002D
> 	Memory Array Mapped Address Handle: 0x0030
> 	Partition Row Position: 1
> 
> Handle 0x0032, DMI type 20, 19 bytes
> Memory Device Mapped Address
> 	Starting Address: 0x00020000000
> 	Ending Address: 0x0003FFFFFFF
> 	Range Size: 512 MB
> 	Physical Device Handle: 0x002E
> 	Memory Array Mapped Address Handle: 0x0030
> 	Partition Row Position: 1
> 
> Handle 0x0033, DMI type 21, 7 bytes
> Built-in Pointing Device
> 	Type: Track Point
> 	Interface: PS/2
> 	Buttons: 3
> 
> Handle 0x0034, DMI type 21, 7 bytes
> Built-in Pointing Device
> 	Type: Touch Pad
> 	Interface: PS/2
> 	Buttons: 0
> 
> Handle 0x0035, DMI type 24, 5 bytes
> Hardware Security
> 	Power-On Password Status: Disabled
> 	Keyboard Password Status: Disabled
> 	Administrator Password Status: Disabled
> 	Front Panel Reset Status: Unknown
> 
> Handle 0x0036, DMI type 32, 11 bytes
> System Boot Information
> 	Status: No errors detected
> 
> Handle 0x0037, DMI type 131, 102 bytes
> OEM-specific Type
> 	Header and Data:
> 		83 66 37 00 01 00 00 00 00 01 72 03 40 00 AE 80
> 		00 02 00 00 00 00 00 2A 00 40 2A 00 00 00 00 00
> 		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 		00 00 00 00 00 00 00 00 00 00 16 00 80 16 00 00
> 		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 		00 00 00 00 00 00
> 	Strings:
> 		IBMCFGDATA
> 
> Handle 0x0038, DMI type 131, 17 bytes
> OEM-specific Type
> 	Header and Data:
> 		83 11 38 00 01 02 03 FF FF 1F 00 00 00 00 00 02
> 		00
> 	Strings:
> 		BOOTINF 20h
> 		BOOTDEV 21h
> 		KEYPTRS 23h
> 
> Handle 0x0039, DMI type 132, 7 bytes
> OEM-specific Type
> 	Header and Data:
> 		84 07 39 00 01 D8 36
> 
> Handle 0x003A, DMI type 133, 5 bytes
> OEM-specific Type
> 	Header and Data:
> 		85 05 3A 00 01
> 	Strings:
> 		KHOIHGIUCCHHII
> 
> Handle 0x003B, DMI type 126, 13 bytes
> Inactive
> 
> Handle 0x003C, DMI type 127, 4 bytes
> End Of Table
> 
> ------
> 
> Thx,
> 
> <earny>

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed