* "buggy cmd640" message followed by soft lockup
@ 2007-11-22 19:07 Frans Pop
[not found] ` <200711241904.13132.bzolnier@gmail.com>
0 siblings, 1 reply; 22+ messages in thread
From: Frans Pop @ 2007-11-22 19:07 UTC (permalink / raw)
To: linux-ide; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1675 bytes --]
During boot of i386 2.6.24 kernels with CONFIG_BLK_DEV_CMD640 set on
VirtualBox 1.5.2, I get the following failure:
<snip>
@@: buggy cmd640<3>BUG soft lockup - CPU#0 stuck for 11s! [modprobe:572]
Pid: 572, comm: modprobe Not tainted (2.6.24-rc2 #1)
EIP: 0060:[<c02a3546>] EFLAGS: 00000286 CPU: 0
EIP is at _spin_lock_irqsave+0x11/0x27
EAX: d0be66b4 EBX: d0bb0b74 ECX: c039a760 EDX: 00000246
ESI: 00000000 EDI: 00000052 EBP: d0be6840 ESP: cec13df0
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069
CR0: 8005003b CR2: ffffffff CR3: 0ec3b000 CR4: 000006d0
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: 00000000 DR7: 00000000
[<d0bd7ef2>} put_cmd640_reg+0x11/0x30 [ide_core]
[<d081aa00>] ide_probe_for_cmd640x+0x2bd/0x450 [ide_core]
[<c01980e4>] create_proc_entry+0x72/0x86
[<d081a6a0>] init_module+0x577/0x586 [ide_core]
[<c011d46b>] default_wake_function+0x0/0x8
[<c014120b>] sys_init_module+0x1672/0x172a
[<c01d0f44>] rb_insert_color+0x4c/0xd
[<c014c540>] disable_irq+0x0/0x25
[<c0103e36>] syscall_call+0x7/0xb
==================
</snip>
After some time the "BUG soft lockup" repeats.
The first 2 characters on the first line (where I put "@@") look to be
unicode characters 2630 and 2665 (hex). The code that prints the message is
in drivers/ide/pci/cmd640.c (762):
printk("%s: buggy cmd640%c interface on %s, config=0x%02x\n",
cmd_hwif0->name, 'a' + cmd640_chip_version - 1, bus_type, cfr);
Note that the message is not printed completely.
The BUG does not occur if I boot with 2.6.22 or 2.6.23 and disappears if I
compile 2.6.24 with CONFIG_BLK_DEV_CMD640 unset.
VirtualBox does not have CMD64x, but ATA_PIIX.
Cheers,
FJP
[-- Attachment #2: config-2.6.24-rc2 --]
[-- Type: text/plain, Size: 59271 bytes --]
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.24-rc2
# Tue Nov 13 22:49:31 2007
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
# CONFIG_X86_64 is not set
CONFIG_X86=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_QUICKLIST=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_CALIBRATE_DELAY=y
# CONFIG_GENERIC_TIME_VSYSCALL is not set
# CONFIG_ZONE_DMA32 is not set
CONFIG_ARCH_POPULATES_NODE_MAP=y
# CONFIG_AUDIT_ARCH is not set
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
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
# CONFIG_TASKSTATS is not set
# CONFIG_USER_NS is not set
CONFIG_AUDIT=y
# CONFIG_AUDITSYSCALL is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=15
# CONFIG_CGROUPS is not set
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_FAIR_USER_SCHED=y
# CONFIG_FAIR_CGROUP_SCHED is not set
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
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
CONFIG_BLOCK=y
CONFIG_LBD=y
# CONFIG_BLK_DEV_IO_TRACE is not set
CONFIG_LSF=y
# CONFIG_BLK_DEV_BSG 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_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_SMP=y
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_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_X86_VSMP is not set
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
# CONFIG_PARAVIRT_GUEST 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=y
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_GENERIC_CPU is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_XADD=y
CONFIG_X86_PPRO_FENCE=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=4
CONFIG_HPET_TIMER=y
CONFIG_NR_CPUS=8
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# 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=m
CONFIG_X86_MCE_P4THERMAL=y
CONFIG_VM86=y
CONFIG_TOSHIBA=m
# 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
# 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_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_SPARSEMEM_VMEMMAP_ENABLE is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not set
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_NR_QUICK=1
CONFIG_VIRT_TO_BUS=y
# CONFIG_HIGHPTE is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_EFI=y
# CONFIG_IRQBALANCE is not set
CONFIG_BOOT_IOREMAP=y
# CONFIG_SECCOMP is not set
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_KEXEC=y
# CONFIG_CRASH_DUMP is not set
CONFIG_PHYSICAL_START=0x100000
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=0x100000
CONFIG_HOTPLUG_CPU=y
CONFIG_COMPAT_VDSO=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
#
# Power management options
#
CONFIG_PM=y
CONFIG_PM_LEGACY=y
# CONFIG_PM_DEBUG is not set
CONFIG_PM_SLEEP_SMP=y
CONFIG_PM_SLEEP=y
CONFIG_SUSPEND_SMP_POSSIBLE=y
CONFIG_SUSPEND=y
CONFIG_HIBERNATION_SMP_POSSIBLE=y
CONFIG_HIBERNATION=y
CONFIG_PM_STD_PARTITION=""
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_PROC_EVENT=y
CONFIG_ACPI_AC=m
CONFIG_ACPI_BATTERY=m
CONFIG_ACPI_BUTTON=m
CONFIG_ACPI_VIDEO=m
CONFIG_ACPI_FAN=m
CONFIG_ACPI_DOCK=m
CONFIG_ACPI_BAY=m
CONFIG_ACPI_PROCESSOR=m
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_THERMAL=m
# CONFIG_ACPI_ASUS is not set
CONFIG_ACPI_TOSHIBA=m
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=m
# CONFIG_ACPI_SBS is not set
# 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=m
# CONFIG_CPU_FREQ_STAT_DETAILS is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=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=m
CONFIG_X86_POWERNOW_K7=m
CONFIG_X86_POWERNOW_K7_ACPI=y
CONFIG_X86_POWERNOW_K8=m
CONFIG_X86_POWERNOW_K8_ACPI=y
CONFIG_X86_GX_SUSPMOD=m
CONFIG_X86_SPEEDSTEP_CENTRINO=m
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=m
CONFIG_X86_LONGRUN=m
CONFIG_X86_LONGHAUL=m
CONFIG_X86_E_POWERSAVER=m
#
# shared options
#
# CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set
CONFIG_X86_SPEEDSTEP_LIB=m
CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK=y
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y
#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
# CONFIG_PCI_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_PCI_DOMAINS=y
# CONFIG_PCIEPORTBUS is not set
CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_PCI_MSI=y
CONFIG_PCI_LEGACY=y
# CONFIG_PCI_DEBUG is not set
CONFIG_HT_IRQ=y
CONFIG_ISA_DMA_API=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
CONFIG_PCCARD=m
# CONFIG_PCMCIA_DEBUG is not set
CONFIG_PCMCIA=m
CONFIG_PCMCIA_LOAD_CIS=y
CONFIG_PCMCIA_IOCTL=y
CONFIG_CARDBUS=y
#
# PC-card bridges
#
CONFIG_YENTA=m
CONFIG_YENTA_O2=y
CONFIG_YENTA_RICOH=y
CONFIG_YENTA_TI=y
CONFIG_YENTA_ENE_TUNE=y
CONFIG_YENTA_TOSHIBA=y
CONFIG_PD6729=m
CONFIG_I82092=m
CONFIG_I82365=m
CONFIG_TCIC=m
CONFIG_PCMCIA_PROBE=y
CONFIG_PCCARD_NONSTATIC=m
CONFIG_HOTPLUG_PCI=m
CONFIG_HOTPLUG_PCI_FAKE=m
CONFIG_HOTPLUG_PCI_COMPAQ=m
# CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM is not set
CONFIG_HOTPLUG_PCI_IBM=m
CONFIG_HOTPLUG_PCI_ACPI=m
CONFIG_HOTPLUG_PCI_ACPI_IBM=m
CONFIG_HOTPLUG_PCI_CPCI=y
CONFIG_HOTPLUG_PCI_CPCI_ZT5550=m
CONFIG_HOTPLUG_PCI_CPCI_GENERIC=m
CONFIG_HOTPLUG_PCI_SHPC=m
#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_MISC=m
#
# Networking
#
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=m
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
CONFIG_NET_KEY=m
# CONFIG_NET_KEY_MIGRATE is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_VERBOSE=y
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=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=m
CONFIG_INET_XFRM_MODE_TUNNEL=m
CONFIG_INET_XFRM_MODE_BEET=m
CONFIG_INET_LRO=m
CONFIG_INET_DIAG=m
CONFIG_INET_TCP_DIAG=m
CONFIG_TCP_CONG_ADVANCED=y
CONFIG_TCP_CONG_BIC=y
CONFIG_TCP_CONG_CUBIC=m
CONFIG_TCP_CONG_WESTWOOD=m
CONFIG_TCP_CONG_HTCP=m
CONFIG_TCP_CONG_HSTCP=m
CONFIG_TCP_CONG_HYBLA=m
CONFIG_TCP_CONG_VEGAS=m
CONFIG_TCP_CONG_SCALABLE=m
CONFIG_TCP_CONG_LP=m
CONFIG_TCP_CONG_VENO=m
CONFIG_TCP_CONG_YEAH=m
CONFIG_TCP_CONG_ILLINOIS=m
CONFIG_DEFAULT_BIC=y
# CONFIG_DEFAULT_CUBIC is not set
# CONFIG_DEFAULT_HTCP is not set
# CONFIG_DEFAULT_VEGAS is not set
# CONFIG_DEFAULT_WESTWOOD is not set
# CONFIG_DEFAULT_RENO is not set
CONFIG_DEFAULT_TCP_CONG="bic"
# CONFIG_TCP_MD5SIG is not set
CONFIG_IP_VS=m
# CONFIG_IP_VS_DEBUG is not set
CONFIG_IP_VS_TAB_BITS=12
#
# IPVS transport protocol load balancing support
#
CONFIG_IP_VS_PROTO_TCP=y
CONFIG_IP_VS_PROTO_UDP=y
CONFIG_IP_VS_PROTO_ESP=y
CONFIG_IP_VS_PROTO_AH=y
#
# IPVS scheduler
#
CONFIG_IP_VS_RR=m
CONFIG_IP_VS_WRR=m
CONFIG_IP_VS_LC=m
CONFIG_IP_VS_WLC=m
CONFIG_IP_VS_LBLC=m
CONFIG_IP_VS_LBLCR=m
CONFIG_IP_VS_DH=m
CONFIG_IP_VS_SH=m
CONFIG_IP_VS_SED=m
CONFIG_IP_VS_NQ=m
#
# IPVS application helper
#
CONFIG_IP_VS_FTP=m
CONFIG_IPV6=m
CONFIG_IPV6_PRIVACY=y
# CONFIG_IPV6_ROUTER_PREF is not set
# CONFIG_IPV6_OPTIMISTIC_DAD is not set
CONFIG_INET6_AH=m
CONFIG_INET6_ESP=m
CONFIG_INET6_IPCOMP=m
# CONFIG_IPV6_MIP6 is not set
CONFIG_INET6_XFRM_TUNNEL=m
CONFIG_INET6_TUNNEL=m
CONFIG_INET6_XFRM_MODE_TRANSPORT=m
CONFIG_INET6_XFRM_MODE_TUNNEL=m
CONFIG_INET6_XFRM_MODE_BEET=m
CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=m
CONFIG_IPV6_SIT=m
CONFIG_IPV6_TUNNEL=m
# CONFIG_IPV6_MULTIPLE_TABLES is not set
# CONFIG_NETLABEL is not set
CONFIG_NETWORK_SECMARK=y
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_BRIDGE_NETFILTER=y
#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=m
CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NETFILTER_NETLINK_LOG=m
CONFIG_NF_CONNTRACK_ENABLED=m
CONFIG_NF_CONNTRACK=m
CONFIG_NF_CT_ACCT=y
CONFIG_NF_CONNTRACK_MARK=y
CONFIG_NF_CONNTRACK_SECMARK=y
CONFIG_NF_CONNTRACK_EVENTS=y
CONFIG_NF_CT_PROTO_GRE=m
CONFIG_NF_CT_PROTO_SCTP=m
# CONFIG_NF_CT_PROTO_UDPLITE is not set
CONFIG_NF_CONNTRACK_AMANDA=m
CONFIG_NF_CONNTRACK_FTP=m
CONFIG_NF_CONNTRACK_H323=m
CONFIG_NF_CONNTRACK_IRC=m
CONFIG_NF_CONNTRACK_NETBIOS_NS=m
CONFIG_NF_CONNTRACK_PPTP=m
CONFIG_NF_CONNTRACK_SANE=m
CONFIG_NF_CONNTRACK_SIP=m
CONFIG_NF_CONNTRACK_TFTP=m
CONFIG_NF_CT_NETLINK=m
CONFIG_NETFILTER_XTABLES=m
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
CONFIG_NETFILTER_XT_TARGET_CONNMARK=m
CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
# CONFIG_NETFILTER_XT_TARGET_TRACE is not set
CONFIG_NETFILTER_XT_TARGET_SECMARK=m
CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_MATCH_COMMENT=m
CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m
# CONFIG_NETFILTER_XT_MATCH_CONNLIMIT is not set
CONFIG_NETFILTER_XT_MATCH_CONNMARK=m
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m
CONFIG_NETFILTER_XT_MATCH_DCCP=m
CONFIG_NETFILTER_XT_MATCH_DSCP=m
CONFIG_NETFILTER_XT_MATCH_ESP=m
CONFIG_NETFILTER_XT_MATCH_HELPER=m
CONFIG_NETFILTER_XT_MATCH_LENGTH=m
CONFIG_NETFILTER_XT_MATCH_LIMIT=m
CONFIG_NETFILTER_XT_MATCH_MAC=m
CONFIG_NETFILTER_XT_MATCH_MARK=m
CONFIG_NETFILTER_XT_MATCH_POLICY=m
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m
CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m
CONFIG_NETFILTER_XT_MATCH_QUOTA=m
CONFIG_NETFILTER_XT_MATCH_REALM=m
CONFIG_NETFILTER_XT_MATCH_SCTP=m
CONFIG_NETFILTER_XT_MATCH_STATE=m
CONFIG_NETFILTER_XT_MATCH_STATISTIC=m
CONFIG_NETFILTER_XT_MATCH_STRING=m
CONFIG_NETFILTER_XT_MATCH_TCPMSS=m
CONFIG_NETFILTER_XT_MATCH_TIME=m
# CONFIG_NETFILTER_XT_MATCH_U32 is not set
CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m
#
# IP: Netfilter Configuration
#
CONFIG_NF_CONNTRACK_IPV4=m
CONFIG_NF_CONNTRACK_PROC_COMPAT=y
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_IPRANGE=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_AH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_NF_NAT=m
CONFIG_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_SAME=m
CONFIG_NF_NAT_SNMP_BASIC=m
CONFIG_NF_NAT_PROTO_GRE=m
CONFIG_NF_NAT_FTP=m
CONFIG_NF_NAT_IRC=m
CONFIG_NF_NAT_TFTP=m
CONFIG_NF_NAT_AMANDA=m
CONFIG_NF_NAT_PPTP=m
CONFIG_NF_NAT_H323=m
CONFIG_NF_NAT_SIP=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_TTL=m
CONFIG_IP_NF_TARGET_CLUSTERIP=m
CONFIG_IP_NF_RAW=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
#
# IPv6: Netfilter Configuration (EXPERIMENTAL)
#
CONFIG_NF_CONNTRACK_IPV6=m
CONFIG_IP6_NF_QUEUE=m
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_RT=m
CONFIG_IP6_NF_MATCH_OPTS=m
CONFIG_IP6_NF_MATCH_FRAG=m
CONFIG_IP6_NF_MATCH_HL=m
CONFIG_IP6_NF_MATCH_OWNER=m
CONFIG_IP6_NF_MATCH_IPV6HEADER=m
CONFIG_IP6_NF_MATCH_AH=m
CONFIG_IP6_NF_MATCH_MH=m
CONFIG_IP6_NF_MATCH_EUI64=m
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_LOG=m
CONFIG_IP6_NF_TARGET_REJECT=m
CONFIG_IP6_NF_MANGLE=m
CONFIG_IP6_NF_TARGET_HL=m
CONFIG_IP6_NF_RAW=m
#
# Bridge: Netfilter Configuration
#
CONFIG_BRIDGE_NF_EBTABLES=m
CONFIG_BRIDGE_EBT_BROUTE=m
CONFIG_BRIDGE_EBT_T_FILTER=m
CONFIG_BRIDGE_EBT_T_NAT=m
CONFIG_BRIDGE_EBT_802_3=m
CONFIG_BRIDGE_EBT_AMONG=m
CONFIG_BRIDGE_EBT_ARP=m
CONFIG_BRIDGE_EBT_IP=m
CONFIG_BRIDGE_EBT_LIMIT=m
CONFIG_BRIDGE_EBT_MARK=m
CONFIG_BRIDGE_EBT_PKTTYPE=m
CONFIG_BRIDGE_EBT_STP=m
CONFIG_BRIDGE_EBT_VLAN=m
CONFIG_BRIDGE_EBT_ARPREPLY=m
CONFIG_BRIDGE_EBT_DNAT=m
CONFIG_BRIDGE_EBT_MARK_T=m
CONFIG_BRIDGE_EBT_REDIRECT=m
CONFIG_BRIDGE_EBT_SNAT=m
CONFIG_BRIDGE_EBT_LOG=m
CONFIG_BRIDGE_EBT_ULOG=m
# CONFIG_IP_DCCP is not set
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
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
CONFIG_BRIDGE=m
CONFIG_VLAN_8021Q=m
# 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
CONFIG_NET_SCHED=y
#
# Queueing/Scheduling
#
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_HFSC=m
CONFIG_NET_SCH_PRIO=m
# CONFIG_NET_SCH_RR is not set
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_SCH_NETEM=m
CONFIG_NET_SCH_INGRESS=m
#
# Classification
#
CONFIG_NET_CLS=y
CONFIG_NET_CLS_BASIC=m
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
CONFIG_CLS_U32_PERF=y
CONFIG_CLS_U32_MARK=y
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
CONFIG_NET_EMATCH=y
CONFIG_NET_EMATCH_STACK=32
CONFIG_NET_EMATCH_CMP=m
CONFIG_NET_EMATCH_NBYTE=m
CONFIG_NET_EMATCH_U32=m
CONFIG_NET_EMATCH_META=m
CONFIG_NET_EMATCH_TEXT=m
CONFIG_NET_CLS_ACT=y
CONFIG_NET_ACT_POLICE=m
CONFIG_NET_ACT_GACT=m
CONFIG_GACT_PROB=y
CONFIG_NET_ACT_MIRRED=m
CONFIG_NET_ACT_IPT=m
CONFIG_NET_ACT_NAT=m
CONFIG_NET_ACT_PEDIT=m
CONFIG_NET_ACT_SIMP=m
# CONFIG_NET_CLS_POLICE is not set
CONFIG_NET_CLS_IND=y
CONFIG_NET_SCH_FIFO=y
#
# Network testing
#
CONFIG_NET_PKTGEN=m
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
CONFIG_AF_RXRPC=m
# CONFIG_AF_RXRPC_DEBUG is not set
CONFIG_RXKAD=m
CONFIG_FIB_RULES=y
#
# Wireless
#
# CONFIG_CFG80211 is not set
# CONFIG_WIRELESS_EXT is not set
# CONFIG_MAC80211 is not set
# CONFIG_IEEE80211 is not set
CONFIG_RFKILL=m
CONFIG_RFKILL_INPUT=m
# CONFIG_NET_9P is not set
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
CONFIG_CONNECTOR=m
CONFIG_MTD=m
# CONFIG_MTD_DEBUG is not set
CONFIG_MTD_CONCAT=m
CONFIG_MTD_PARTITIONS=y
CONFIG_MTD_REDBOOT_PARTS=m
CONFIG_MTD_REDBOOT_DIRECTORY_BLOCK=-1
# CONFIG_MTD_REDBOOT_PARTS_UNALLOCATED is not set
# CONFIG_MTD_REDBOOT_PARTS_READONLY is not set
#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=m
CONFIG_MTD_BLKDEVS=m
CONFIG_MTD_BLOCK=m
CONFIG_MTD_BLOCK_RO=m
CONFIG_FTL=m
CONFIG_NFTL=m
CONFIG_NFTL_RW=y
CONFIG_INFTL=m
CONFIG_RFD_FTL=m
CONFIG_SSFDC=m
# CONFIG_MTD_OOPS is not set
#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=m
CONFIG_MTD_JEDECPROBE=m
CONFIG_MTD_GEN_PROBE=m
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
CONFIG_MTD_CFI_INTELEXT=m
CONFIG_MTD_CFI_AMDSTD=m
CONFIG_MTD_CFI_STAA=m
CONFIG_MTD_CFI_UTIL=m
CONFIG_MTD_RAM=m
CONFIG_MTD_ROM=m
CONFIG_MTD_ABSENT=m
#
# Mapping drivers for chip access
#
CONFIG_MTD_COMPLEX_MAPPINGS=y
CONFIG_MTD_PHYSMAP=m
CONFIG_MTD_PHYSMAP_START=0x8000000
CONFIG_MTD_PHYSMAP_LEN=0x4000000
CONFIG_MTD_PHYSMAP_BANKWIDTH=2
CONFIG_MTD_PNC2000=m
CONFIG_MTD_SC520CDP=m
CONFIG_MTD_NETSC520=m
CONFIG_MTD_TS5500=m
CONFIG_MTD_SBC_GXX=m
# CONFIG_MTD_AMD76XROM is not set
# CONFIG_MTD_ICHXROM is not set
# CONFIG_MTD_ESB2ROM is not set
# CONFIG_MTD_CK804XROM is not set
# CONFIG_MTD_SCB2_FLASH is not set
CONFIG_MTD_NETtel=m
CONFIG_MTD_DILNETPC=m
CONFIG_MTD_DILNETPC_BOOTSIZE=0x80000
# CONFIG_MTD_L440GX is not set
CONFIG_MTD_PCI=m
# CONFIG_MTD_INTEL_VR_NOR is not set
CONFIG_MTD_PLATRAM=m
#
# Self-contained MTD device drivers
#
CONFIG_MTD_PMC551=m
# CONFIG_MTD_PMC551_BUGFIX is not set
# CONFIG_MTD_PMC551_DEBUG is not set
CONFIG_MTD_SLRAM=m
CONFIG_MTD_PHRAM=m
CONFIG_MTD_MTDRAM=m
CONFIG_MTDRAM_TOTAL_SIZE=4096
CONFIG_MTDRAM_ERASE_SIZE=128
CONFIG_MTD_BLOCK2MTD=m
#
# Disk-On-Chip Device Drivers
#
CONFIG_MTD_DOC2000=m
CONFIG_MTD_DOC2001=m
CONFIG_MTD_DOC2001PLUS=m
CONFIG_MTD_DOCPROBE=m
CONFIG_MTD_DOCECC=m
# CONFIG_MTD_DOCPROBE_ADVANCED is not set
CONFIG_MTD_DOCPROBE_ADDRESS=0
CONFIG_MTD_NAND=m
# CONFIG_MTD_NAND_VERIFY_WRITE is not set
# CONFIG_MTD_NAND_ECC_SMC is not set
# CONFIG_MTD_NAND_MUSEUM_IDS is not set
CONFIG_MTD_NAND_IDS=m
CONFIG_MTD_NAND_DISKONCHIP=m
# CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADVANCED is not set
CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADDRESS=0
# CONFIG_MTD_NAND_DISKONCHIP_BBTWRITE is not set
CONFIG_MTD_NAND_CAFE=m
CONFIG_MTD_NAND_CS553X=m
# CONFIG_MTD_NAND_NANDSIM is not set
CONFIG_MTD_NAND_PLATFORM=m
# CONFIG_MTD_ALAUDA is not set
CONFIG_MTD_ONENAND=m
CONFIG_MTD_ONENAND_VERIFY_WRITE=y
# CONFIG_MTD_ONENAND_OTP is not set
# CONFIG_MTD_ONENAND_2X_PROGRAM is not set
# CONFIG_MTD_ONENAND_SIM is not set
#
# UBI - Unsorted block images
#
CONFIG_MTD_UBI=m
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_RESERVE=1
# CONFIG_MTD_UBI_GLUEBI is not set
#
# UBI debugging options
#
# CONFIG_MTD_UBI_DEBUG is not set
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_SERIAL=m
CONFIG_PARPORT_PC_FIFO=y
# CONFIG_PARPORT_PC_SUPERIO is not set
CONFIG_PARPORT_PC_PCMCIA=m
# CONFIG_PARPORT_GSC is not set
CONFIG_PARPORT_AX88796=m
CONFIG_PARPORT_1284=y
CONFIG_PARPORT_NOT_PC=y
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set
#
# Protocols
#
CONFIG_ISAPNP=y
CONFIG_PNPBIOS=y
CONFIG_PNPBIOS_PROC_FS=y
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_FD=m
CONFIG_BLK_DEV_XD=m
# CONFIG_PARIDE 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=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=8192
CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_MISC_DEVICES is not set
CONFIG_IDE=m
CONFIG_BLK_DEV_IDE=m
#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=m
# CONFIG_IDEDISK_MULTI_MODE is not set
# CONFIG_BLK_DEV_IDECS is not set
CONFIG_BLK_DEV_DELKIN=m
CONFIG_BLK_DEV_IDECD=m
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_BLK_DEV_IDEACPI is not set
# CONFIG_IDE_TASK_IOCTL is not set
CONFIG_IDE_PROC_FS=y
#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=m
CONFIG_BLK_DEV_PLATFORM=m
CONFIG_BLK_DEV_CMD640=y
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
CONFIG_BLK_DEV_IDEPNP=y
#
# PCI IDE chipsets support
#
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_IDEPCI_PCIBUS_ORDER is not set
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=m
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_CS5535 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_JMICRON is not set
# CONFIG_BLK_DEV_SC1200 is not set
CONFIG_BLK_DEV_PIIX=m
# CONFIG_BLK_DEV_IT8213 is not set
# CONFIG_BLK_DEV_IT821X is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_BLK_DEV_TC86C001 is not set
# CONFIG_IDE_ARM is not set
#
# Other IDE chipsets support
#
#
# Note: most of these also require special kernel boot parameters
#
# CONFIG_BLK_DEV_4DRIVES is not set
# CONFIG_BLK_DEV_ALI14XX is not set
# CONFIG_BLK_DEV_DTC2278 is not set
# CONFIG_BLK_DEV_HT6560B is not set
# CONFIG_BLK_DEV_QD65XX is not set
# CONFIG_BLK_DEV_UMC8672 is not set
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDE_ARCH_OBSOLETE_INIT=y
# CONFIG_BLK_DEV_HD is not set
#
# SCSI device support
#
CONFIG_RAID_ATTRS=m
CONFIG_SCSI=m
CONFIG_SCSI_DMA=y
CONFIG_SCSI_TGT=m
CONFIG_SCSI_NETLINK=y
CONFIG_SCSI_PROC_FS=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=m
CONFIG_CHR_DEV_SCH=m
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_SCAN_ASYNC=y
CONFIG_SCSI_WAIT_SCAN=m
#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=m
CONFIG_SCSI_FC_ATTRS=m
# CONFIG_SCSI_FC_TGT_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
CONFIG_SCSI_SAS_ATTRS=m
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
# CONFIG_SCSI_LOWLEVEL is not set
# CONFIG_SCSI_LOWLEVEL_PCMCIA is not set
CONFIG_ATA=m
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_ACPI=y
CONFIG_SATA_AHCI=m
# CONFIG_SATA_SVW is not set
CONFIG_ATA_PIIX=m
# 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_SATA_INIC162X is not set
# CONFIG_PATA_ACPI 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_CMD640_PCI is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CS5535 is not set
# CONFIG_PATA_CS5536 is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
CONFIG_ATA_GENERIC=m
# 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=m
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_JMICRON is not set
CONFIG_PATA_LEGACY=m
# CONFIG_PATA_TRIFLEX is not set
CONFIG_PATA_MARVELL=m
# 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_NS87415 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PCMCIA is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_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
# CONFIG_PATA_WINBOND_VLB is not set
CONFIG_MD=y
CONFIG_BLK_DEV_MD=m
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=m
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
# CONFIG_DM_MULTIPATH_RDAC is not set
# CONFIG_DM_MULTIPATH_HP is not set
CONFIG_DM_DELAY=m
# CONFIG_DM_UEVENT is not set
CONFIG_FUSION=y
CONFIG_FUSION_SPI=m
CONFIG_FUSION_FC=m
CONFIG_FUSION_SAS=m
CONFIG_FUSION_MAX_SGE=40
CONFIG_FUSION_CTL=m
# CONFIG_FUSION_LOGGING is not set
#
# IEEE 1394 (FireWire) support
#
CONFIG_FIREWIRE=m
CONFIG_FIREWIRE_OHCI=m
CONFIG_FIREWIRE_SBP2=m
# CONFIG_IEEE1394 is not set
CONFIG_I2O=m
CONFIG_I2O_LCT_NOTIFY_ON_CHANGES=y
CONFIG_I2O_EXT_ADAPTEC=y
CONFIG_I2O_CONFIG=m
CONFIG_I2O_CONFIG_OLD_IOCTL=y
CONFIG_I2O_BUS=m
CONFIG_I2O_BLOCK=m
CONFIG_I2O_SCSI=m
CONFIG_I2O_PROC=m
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
# CONFIG_NETDEVICES_MULTIQUEUE is not set
CONFIG_IFB=m
CONFIG_DUMMY=m
CONFIG_BONDING=m
# CONFIG_MACVLAN is not set
CONFIG_EQUALIZER=m
CONFIG_TUN=m
CONFIG_VETH=m
# CONFIG_NET_SB1000 is not set
# CONFIG_IP1000 is not set
# CONFIG_ARCNET is not set
# CONFIG_PHYLIB is not set
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
# 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_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
CONFIG_NET_PCI=y
CONFIG_PCNET32=m
# CONFIG_PCNET32_NAPI is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_CS89x0 is not set
# CONFIG_EEPRO100 is not set
CONFIG_E100=y
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_SC92031 is not set
# CONFIG_NET_POCKET is not set
# CONFIG_NETDEV_1000 is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_TR is not set
#
# Wireless LAN
#
# CONFIG_WLAN_PRE80211 is not set
# CONFIG_WLAN_80211 is not set
#
# 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_DM9601=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_KC2190=y
CONFIG_USB_NET_ZAURUS=m
# CONFIG_NET_PCMCIA is not set
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PLIP=m
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPP_MPPE=m
CONFIG_PPPOE=m
# CONFIG_PPPOL2TP is not set
CONFIG_SLIP=m
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLHC=m
CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y
# CONFIG_NET_FC is not set
CONFIG_SHAPER=m
CONFIG_NETCONSOLE=y
CONFIG_NETCONSOLE_DYNAMIC=y
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_FF_MEMLESS=m
CONFIG_INPUT_POLLDEV=m
#
# 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=m
CONFIG_INPUT_EVDEV=m
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
CONFIG_KEYBOARD_SUNKBD=m
CONFIG_KEYBOARD_LKKBD=m
CONFIG_KEYBOARD_XTKBD=m
CONFIG_KEYBOARD_NEWTON=m
CONFIG_KEYBOARD_STOWAWAY=m
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=m
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
CONFIG_MOUSE_SERIAL=m
CONFIG_MOUSE_APPLETOUCH=m
CONFIG_MOUSE_INPORT=m
# CONFIG_MOUSE_ATIXL is not set
CONFIG_MOUSE_LOGIBM=m
CONFIG_MOUSE_PC110PAD=m
CONFIG_MOUSE_VSXXXAA=m
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=y
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=m
CONFIG_JOYSTICK_DB9=m
CONFIG_JOYSTICK_GAMECON=m
CONFIG_JOYSTICK_TURBOGRAFX=m
CONFIG_JOYSTICK_JOYDUMP=m
CONFIG_JOYSTICK_XPAD=m
# CONFIG_JOYSTICK_XPAD_FF is not set
# CONFIG_JOYSTICK_XPAD_LEDS is not set
CONFIG_INPUT_TABLET=y
CONFIG_TABLET_USB_ACECAD=m
CONFIG_TABLET_USB_AIPTEK=m
CONFIG_TABLET_USB_GTCO=m
CONFIG_TABLET_USB_KBTAB=m
CONFIG_TABLET_USB_WACOM=m
CONFIG_INPUT_TOUCHSCREEN=y
# CONFIG_TOUCHSCREEN_FUJITSU is not set
CONFIG_TOUCHSCREEN_GUNZE=m
CONFIG_TOUCHSCREEN_ELO=m
CONFIG_TOUCHSCREEN_MTOUCH=m
CONFIG_TOUCHSCREEN_MK712=m
CONFIG_TOUCHSCREEN_PENMOUNT=m
CONFIG_TOUCHSCREEN_TOUCHRIGHT=m
CONFIG_TOUCHSCREEN_TOUCHWIN=m
CONFIG_TOUCHSCREEN_UCB1400=m
CONFIG_TOUCHSCREEN_USB_COMPOSITE=m
CONFIG_TOUCHSCREEN_USB_EGALAX=y
CONFIG_TOUCHSCREEN_USB_PANJIT=y
CONFIG_TOUCHSCREEN_USB_3M=y
CONFIG_TOUCHSCREEN_USB_ITM=y
CONFIG_TOUCHSCREEN_USB_ETURBO=y
CONFIG_TOUCHSCREEN_USB_GUNZE=y
CONFIG_TOUCHSCREEN_USB_DMC_TSC10=y
CONFIG_TOUCHSCREEN_USB_IRTOUCH=y
CONFIG_TOUCHSCREEN_USB_IDEALTEK=y
CONFIG_TOUCHSCREEN_USB_GENERAL_TOUCH=y
CONFIG_TOUCHSCREEN_USB_GOTOP=y
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=m
CONFIG_INPUT_WISTRON_BTNS=m
CONFIG_INPUT_ATLAS_BTNS=m
CONFIG_INPUT_ATI_REMOTE=m
CONFIG_INPUT_ATI_REMOTE2=m
CONFIG_INPUT_KEYSPAN_REMOTE=m
CONFIG_INPUT_POWERMATE=m
CONFIG_INPUT_YEALINK=m
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_PARKBD=m
CONFIG_SERIO_PCIPS2=m
CONFIG_SERIO_LIBPS2=y
CONFIG_SERIO_RAW=m
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=y
# CONFIG_COMPUTONE is not set
# CONFIG_ROCKETPORT is not set
# CONFIG_CYCLADES is not set
# CONFIG_DIGIEPCA is not set
# CONFIG_ESPSERIAL is not set
# CONFIG_MOXA_INTELLIO is not set
# CONFIG_MOXA_SMARTIO is not set
# CONFIG_MOXA_SMARTIO_NEW is not set
# CONFIG_ISI is not set
# CONFIG_SYNCLINK is not set
# CONFIG_SYNCLINKMP is not set
# CONFIG_SYNCLINK_GT is not set
# CONFIG_N_HDLC is not set
# CONFIG_SPECIALIX is not set
# CONFIG_SX is not set
# CONFIG_RIO is not set
# CONFIG_STALDRV is not set
#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_CS=m
CONFIG_SERIAL_8250_NR_UARTS=16
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_FOURPORT=m
CONFIG_SERIAL_8250_ACCENT=m
CONFIG_SERIAL_8250_BOCA=m
CONFIG_SERIAL_8250_EXAR_ST16C554=m
CONFIG_SERIAL_8250_HUB6=m
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
CONFIG_SERIAL_8250_RSA=y
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_JSM=m
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_PRINTER=m
# CONFIG_LP_CONSOLE is not set
CONFIG_PPDEV=m
# CONFIG_TIPAR is not set
CONFIG_IPMI_HANDLER=m
# CONFIG_IPMI_PANIC_EVENT is not set
CONFIG_IPMI_DEVICE_INTERFACE=m
CONFIG_IPMI_SI=m
CONFIG_IPMI_WATCHDOG=m
CONFIG_IPMI_POWEROFF=m
CONFIG_HW_RANDOM=y
CONFIG_HW_RANDOM_INTEL=m
CONFIG_HW_RANDOM_AMD=m
CONFIG_HW_RANDOM_GEODE=m
CONFIG_HW_RANDOM_VIA=m
CONFIG_NVRAM=m
CONFIG_RTC=m
CONFIG_GEN_RTC=m
CONFIG_GEN_RTC_X=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
CONFIG_APPLICOM=m
# CONFIG_SONYPI is not set
#
# PCMCIA character devices
#
# CONFIG_SYNCLINK_CS is not set
# CONFIG_CARDMAN_4000 is not set
# CONFIG_CARDMAN_4040 is not set
# CONFIG_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
# CONFIG_NSC_GPIO is not set
# CONFIG_CS5535_GPIO is not set
CONFIG_RAW_DRIVER=m
CONFIG_MAX_RAW_DEVS=256
CONFIG_HPET=y
# CONFIG_HPET_RTC_IRQ is not set
CONFIG_HPET_MMAP=y
CONFIG_HANGCHECK_TIMER=m
# CONFIG_TCG_TPM is not set
CONFIG_TELCLOCK=m
CONFIG_DEVPORT=y
CONFIG_I2C=m
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_CHARDEV=m
#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ALGOPCA=m
#
# I2C Hardware Bus support
#
CONFIG_I2C_ALI1535=m
CONFIG_I2C_ALI1563=m
CONFIG_I2C_ALI15X3=m
CONFIG_I2C_AMD756=m
CONFIG_I2C_AMD756_S4882=m
CONFIG_I2C_AMD8111=m
CONFIG_I2C_I801=m
CONFIG_I2C_I810=m
CONFIG_I2C_PIIX4=m
CONFIG_I2C_NFORCE2=m
CONFIG_I2C_OCORES=m
CONFIG_I2C_PARPORT=m
CONFIG_I2C_PARPORT_LIGHT=m
CONFIG_I2C_PROSAVAGE=m
CONFIG_I2C_SAVAGE4=m
CONFIG_I2C_SIMTEC=m
CONFIG_SCx200_ACB=m
CONFIG_I2C_SIS5595=m
CONFIG_I2C_SIS630=m
CONFIG_I2C_SIS96X=m
# CONFIG_I2C_TAOS_EVM is not set
CONFIG_I2C_STUB=m
CONFIG_I2C_TINY_USB=m
CONFIG_I2C_VIA=m
CONFIG_I2C_VIAPRO=m
CONFIG_I2C_VOODOO3=m
CONFIG_I2C_PCA_ISA=m
#
# Miscellaneous I2C Chip support
#
CONFIG_SENSORS_DS1337=m
CONFIG_SENSORS_DS1374=m
# CONFIG_DS1682 is not set
CONFIG_SENSORS_EEPROM=m
CONFIG_SENSORS_PCF8574=m
CONFIG_SENSORS_PCA9539=m
CONFIG_SENSORS_PCF8591=m
CONFIG_SENSORS_MAX6875=m
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set
#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set
# CONFIG_W1 is not set
CONFIG_POWER_SUPPLY=m
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_BATTERY_DS2760 is not set
CONFIG_HWMON=y
CONFIG_HWMON_VID=m
CONFIG_SENSORS_ABITUGURU=m
# CONFIG_SENSORS_ABITUGURU3 is not set
CONFIG_SENSORS_AD7418=m
CONFIG_SENSORS_ADM1021=m
CONFIG_SENSORS_ADM1025=m
CONFIG_SENSORS_ADM1026=m
CONFIG_SENSORS_ADM1029=m
CONFIG_SENSORS_ADM1031=m
CONFIG_SENSORS_ADM9240=m
CONFIG_SENSORS_ADT7470=m
CONFIG_SENSORS_K8TEMP=m
CONFIG_SENSORS_ASB100=m
CONFIG_SENSORS_ATXP1=m
CONFIG_SENSORS_DS1621=m
CONFIG_SENSORS_I5K_AMB=m
CONFIG_SENSORS_F71805F=m
CONFIG_SENSORS_F71882FG=m
CONFIG_SENSORS_F75375S=m
CONFIG_SENSORS_FSCHER=m
CONFIG_SENSORS_FSCPOS=m
CONFIG_SENSORS_FSCHMD=m
CONFIG_SENSORS_GL518SM=m
CONFIG_SENSORS_GL520SM=m
CONFIG_SENSORS_CORETEMP=m
CONFIG_SENSORS_IBMPEX=m
CONFIG_SENSORS_IT87=m
CONFIG_SENSORS_LM63=m
CONFIG_SENSORS_LM75=m
CONFIG_SENSORS_LM77=m
CONFIG_SENSORS_LM78=m
CONFIG_SENSORS_LM80=m
CONFIG_SENSORS_LM83=m
CONFIG_SENSORS_LM85=m
CONFIG_SENSORS_LM87=m
CONFIG_SENSORS_LM90=m
CONFIG_SENSORS_LM92=m
# CONFIG_SENSORS_LM93 is not set
CONFIG_SENSORS_MAX1619=m
CONFIG_SENSORS_MAX6650=m
CONFIG_SENSORS_PC87360=m
CONFIG_SENSORS_PC87427=m
CONFIG_SENSORS_SIS5595=m
# CONFIG_SENSORS_DME1737 is not set
CONFIG_SENSORS_SMSC47M1=m
CONFIG_SENSORS_SMSC47M192=m
CONFIG_SENSORS_SMSC47B397=m
# CONFIG_SENSORS_THMC50 is not set
CONFIG_SENSORS_VIA686A=m
CONFIG_SENSORS_VT1211=m
CONFIG_SENSORS_VT8231=m
CONFIG_SENSORS_W83781D=m
CONFIG_SENSORS_W83791D=m
CONFIG_SENSORS_W83792D=m
CONFIG_SENSORS_W83793=m
CONFIG_SENSORS_W83L785TS=m
CONFIG_SENSORS_W83627HF=m
CONFIG_SENSORS_W83627EHF=m
CONFIG_SENSORS_HDAPS=m
CONFIG_SENSORS_APPLESMC=m
# CONFIG_HWMON_DEBUG_CHIP is not set
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set
#
# Watchdog Device Drivers
#
CONFIG_SOFT_WATCHDOG=m
CONFIG_ACQUIRE_WDT=m
CONFIG_ADVANTECH_WDT=m
CONFIG_ALIM1535_WDT=m
CONFIG_ALIM7101_WDT=m
CONFIG_SC520_WDT=m
CONFIG_EUROTECH_WDT=m
CONFIG_IB700_WDT=m
CONFIG_IBMASR=m
CONFIG_WAFER_WDT=m
CONFIG_I6300ESB_WDT=m
CONFIG_ITCO_WDT=m
# CONFIG_ITCO_VENDOR_SUPPORT is not set
CONFIG_SC1200_WDT=m
CONFIG_PC87413_WDT=m
CONFIG_60XX_WDT=m
CONFIG_SBC8360_WDT=m
CONFIG_CPU5_WDT=m
CONFIG_SMSC37B787_WDT=m
CONFIG_W83627HF_WDT=m
CONFIG_W83697HF_WDT=m
CONFIG_W83877F_WDT=m
CONFIG_W83977F_WDT=m
CONFIG_MACHZ_WDT=m
CONFIG_SBC_EPX_C3_WATCHDOG=m
#
# ISA-based Watchdog Cards
#
CONFIG_PCWATCHDOG=m
CONFIG_MIXCOMWD=m
CONFIG_WDT=m
CONFIG_WDT_501=y
#
# PCI-based Watchdog Cards
#
CONFIG_PCIPCWATCHDOG=m
CONFIG_WDTPCI=m
CONFIG_WDT_501_PCI=y
#
# USB-based Watchdog Cards
#
CONFIG_USBPCWATCHDOG=m
#
# Sonics Silicon Backplane
#
CONFIG_SSB_POSSIBLE=y
# CONFIG_SSB is not set
#
# Multifunction device drivers
#
# CONFIG_MFD_SM501 is not set
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
# CONFIG_DVB_CORE is not set
# CONFIG_DAB is not set
#
# Graphics support
#
CONFIG_AGP=m
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_ATI is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not set
CONFIG_AGP_INTEL=m
# CONFIG_AGP_NVIDIA is not set
# 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=m
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
CONFIG_DRM_I810=m
CONFIG_DRM_I830=m
CONFIG_DRM_I915=m
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set
CONFIG_VGASTATE=m
CONFIG_VIDEO_OUTPUT_CONTROL=m
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_DDC=m
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
# CONFIG_FB_SYS_FILLRECT is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_SYS_FOPS is not set
CONFIG_FB_DEFERRED_IO=y
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
#
# Frame buffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
CONFIG_FB_VGA16=m
# CONFIG_FB_UVESA is not set
CONFIG_FB_VESA=y
# CONFIG_FB_IMAC is not set
# CONFIG_FB_HECUBA 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=m
# CONFIG_FB_I810_GTF is not set
# CONFIG_FB_LE80578 is not set
CONFIG_FB_INTEL=m
# 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_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_CYBLA is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
# CONFIG_LCD_CLASS_DEVICE is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
# CONFIG_BACKLIGHT_CORGI is not set
CONFIG_BACKLIGHT_PROGEAR=m
#
# Display device support
#
CONFIG_DISPLAY_SUPPORT=m
#
# Display hardware drivers
#
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VGACON_SOFT_SCROLLBACK is not set
CONFIG_VIDEO_SELECT=y
CONFIG_MDA_CONSOLE=m
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
# CONFIG_LOGO is not set
#
# Sound
#
CONFIG_SOUND=m
#
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
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 is not set
CONFIG_SND_SUPPORT_OLD_API=y
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
#
# Generic devices
#
CONFIG_SND_MPU401_UART=m
CONFIG_SND_AC97_CODEC=m
CONFIG_SND_DUMMY=m
CONFIG_SND_VIRMIDI=m
CONFIG_SND_MTPAV=m
CONFIG_SND_MTS64=m
CONFIG_SND_SERIAL_U16550=m
CONFIG_SND_MPU401=m
CONFIG_SND_PORTMAN2X4=m
#
# ISA devices
#
# CONFIG_SND_ADLIB is not set
# CONFIG_SND_AD1816A is not set
# CONFIG_SND_AD1848 is not set
# CONFIG_SND_ALS100 is not set
# CONFIG_SND_AZT2320 is not set
# CONFIG_SND_CMI8330 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
# CONFIG_SND_DT019X is not set
# CONFIG_SND_ES968 is not set
# CONFIG_SND_ES1688 is not set
# CONFIG_SND_ES18XX is not set
# CONFIG_SND_SC6000 is not set
# CONFIG_SND_GUSCLASSIC is not set
# CONFIG_SND_GUSEXTREME is not set
# CONFIG_SND_GUSMAX is not set
# CONFIG_SND_INTERWAVE is not set
# CONFIG_SND_INTERWAVE_STB is not set
# CONFIG_SND_OPL3SA2 is not set
# CONFIG_SND_OPTI92X_AD1848 is not set
# CONFIG_SND_OPTI92X_CS4231 is not set
# CONFIG_SND_OPTI93X is not set
# CONFIG_SND_MIRO is not set
# CONFIG_SND_SB8 is not set
# CONFIG_SND_SB16 is not set
# CONFIG_SND_SBAWE is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_SSCAPE is not set
# CONFIG_SND_WAVEFRONT is not set
#
# PCI devices
#
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS5530 is not set
# CONFIG_SND_CS5535AUDIO is not set
# CONFIG_SND_DARLA20 is not set
# CONFIG_SND_GINA20 is not set
# CONFIG_SND_LAYLA20 is not set
# CONFIG_SND_DARLA24 is not set
# CONFIG_SND_GINA24 is not set
# CONFIG_SND_LAYLA24 is not set
# CONFIG_SND_MONA is not set
# CONFIG_SND_MIA is not set
# CONFIG_SND_ECHO3G is not set
# CONFIG_SND_INDIGO is not set
# CONFIG_SND_INDIGOIO is not set
# CONFIG_SND_INDIGODJ is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_HDA_INTEL is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
CONFIG_SND_INTEL8X0=m
CONFIG_SND_INTEL8X0M=m
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_PCXHR is not set
# CONFIG_SND_RIPTIDE is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI is not set
CONFIG_SND_AC97_POWER_SAVE=y
CONFIG_SND_AC97_POWER_SAVE_DEFAULT=0
#
# USB devices
#
# CONFIG_SND_USB_AUDIO is not set
# CONFIG_SND_USB_USX2Y is not set
# CONFIG_SND_USB_CAIAQ is not set
#
# PCMCIA devices
#
# CONFIG_SND_VXPOCKET is not set
# CONFIG_SND_PDAUDIOCF is not set
#
# System on Chip audio support
#
# CONFIG_SND_SOC is not set
#
# SoC Audio support for SuperH
#
#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set
CONFIG_AC97_BUS=m
CONFIG_HID_SUPPORT=y
CONFIG_HID=m
# CONFIG_HID_DEBUG is not set
# CONFIG_HIDRAW is not set
#
# USB Input Devices
#
CONFIG_USB_HID=m
CONFIG_USB_HIDINPUT_POWERBOOK=y
# 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_SUPPORT=y
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_DEVICE_CLASS=y
# CONFIG_USB_DYNAMIC_MINORS is not set
CONFIG_USB_SUSPEND=y
# CONFIG_USB_PERSIST is not set
# CONFIG_USB_OTG is not set
#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_EHCI_SPLIT_ISO=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
# CONFIG_USB_ISP116X_HCD is not set
CONFIG_USB_OHCI_HCD=m
# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=m
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
#
# 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 is not set
# CONFIG_USB_LIBUSUAL is not set
#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
CONFIG_USB_MON=y
#
# USB port drivers
#
CONFIG_USB_USS720=m
#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set
#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_BERRY_CHARGE is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGET is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
#
# USB DSL modem support
#
#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
# CONFIG_MMC is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=m
#
# LED drivers
#
#
# LED Triggers
#
# CONFIG_LEDS_TRIGGERS is not set
# CONFIG_INFINIBAND is not set
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=m
CONFIG_RTC_CLASS=m
#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set
#
# I2C RTC drivers
#
CONFIG_RTC_DRV_DS1307=m
CONFIG_RTC_DRV_DS1374=m
CONFIG_RTC_DRV_DS1672=m
CONFIG_RTC_DRV_MAX6900=m
CONFIG_RTC_DRV_RS5C372=m
CONFIG_RTC_DRV_ISL1208=m
CONFIG_RTC_DRV_X1205=m
CONFIG_RTC_DRV_PCF8563=m
CONFIG_RTC_DRV_PCF8583=m
# CONFIG_RTC_DRV_M41T80 is not set
#
# SPI RTC drivers
#
#
# Platform RTC drivers
#
CONFIG_RTC_DRV_CMOS=m
CONFIG_RTC_DRV_DS1553=m
# CONFIG_RTC_DRV_STK17TA8 is not set
CONFIG_RTC_DRV_DS1742=m
CONFIG_RTC_DRV_M48T86=m
# CONFIG_RTC_DRV_M48T59 is not set
CONFIG_RTC_DRV_V3020=m
#
# on-CPU RTC drivers
#
# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_VIRTUALIZATION is not set
#
# Userspace I/O
#
# CONFIG_UIO is not set
#
# Firmware Drivers
#
CONFIG_EDD=m
CONFIG_EFI_VARS=m
CONFIG_DELL_RBU=m
CONFIG_DCDBAS=m
CONFIG_DMIID=y
#
# 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 is not set
CONFIG_JBD=m
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=m
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_MINIX_FS is not set
CONFIG_ROMFS_FS=m
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_QUOTA=y
# CONFIG_QUOTA_NETLINK_INTERFACE is not set
CONFIG_PRINT_QUOTA_WARNING=y
CONFIG_QFMT_V1=m
CONFIG_QFMT_V2=m
CONFIG_QUOTACTL=y
CONFIG_DNOTIFY=y
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m
CONFIG_FUSE_FS=m
CONFIG_GENERIC_ACL=y
#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_NTFS_FS=m
# CONFIG_NTFS_DEBUG is not set
CONFIG_NTFS_RW=y
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_CONFIGFS_FS=y
#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_ECRYPT_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_JFFS2_FS is not set
CONFIG_CRAMFS=y
# 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
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
CONFIG_NFS_DIRECTIO=y
# CONFIG_NFSD is not set
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_NFS_ACL_SUPPORT=m
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=m
CONFIG_SUNRPC_GSS=m
CONFIG_SUNRPC_BIND34=y
CONFIG_RPCSEC_GSS_KRB5=m
CONFIG_RPCSEC_GSS_SPKM3=m
CONFIG_SMB_FS=m
# CONFIG_SMB_NLS_DEFAULT is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
CONFIG_LDM_PARTITION=y
# CONFIG_LDM_DEBUG 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
# CONFIG_SYSV68_PARTITION is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
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=m
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
CONFIG_DLM=m
CONFIG_DLM_DEBUG=y
CONFIG_INSTRUMENTATION=y
# CONFIG_PROFILING is not set
# CONFIG_KPROBES is not set
# CONFIG_MARKERS is not set
#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not set
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_UNUSED_SYMBOLS=y
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_DETECT_SOFTLOCKUP=y
CONFIG_SCHED_DEBUG=y
# CONFIG_SCHEDSTATS is not set
CONFIG_TIMER_STATS=y
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_FRAME_POINTER is not set
# CONFIG_FORCED_INLINING is not set
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_SAMPLES is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set
#
# Page alloc debug is incompatible with Software Suspend on i386
#
# 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=y
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_NETWORK_XFRM=y
CONFIG_SECURITY_CAPABILITIES=y
# CONFIG_SECURITY_FILE_CAPABILITIES is not set
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=0
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
# CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT is not set
# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set
CONFIG_XOR_BLOCKS=m
CONFIG_ASYNC_CORE=m
CONFIG_ASYNC_MEMCPY=m
CONFIG_ASYNC_XOR=m
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_AEAD=m
CONFIG_CRYPTO_BLKCIPHER=m
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_XCBC=m
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=m
CONFIG_CRYPTO_TGR192=m
CONFIG_CRYPTO_GF128MUL=m
CONFIG_CRYPTO_ECB=m
CONFIG_CRYPTO_CBC=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_LRW=m
CONFIG_CRYPTO_XTS=m
# CONFIG_CRYPTO_CRYPTD is not set
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_FCRYPT=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_TWOFISH_COMMON=m
CONFIG_CRYPTO_TWOFISH_586=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_AES_586=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_SEED=m
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_CRC32C=m
CONFIG_CRYPTO_CAMELLIA=m
CONFIG_CRYPTO_TEST=m
CONFIG_CRYPTO_AUTHENC=m
CONFIG_CRYPTO_HW=y
CONFIG_CRYPTO_DEV_PADLOCK=m
CONFIG_CRYPTO_DEV_PADLOCK_AES=m
CONFIG_CRYPTO_DEV_PADLOCK_SHA=m
CONFIG_CRYPTO_DEV_GEODE=m
#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_CRC_CCITT=m
CONFIG_CRC16=m
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=m
CONFIG_AUDIT_GENERIC=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_REED_SOLOMON=m
CONFIG_REED_SOLOMON_DEC16=y
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=m
CONFIG_TEXTSEARCH_BM=m
CONFIG_TEXTSEARCH_FSM=m
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_CHECK_SIGNATURE=y
[-- Attachment #3: VBox_cmd640_lockup.png --]
[-- Type: image/png, Size: 50994 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: "buggy cmd640" message followed by soft lockup
[not found] ` <200711241904.13132.bzolnier@gmail.com>
@ 2007-11-24 19:07 ` Rafael J. Wysocki
2007-11-25 0:26 ` kernel bugzilla is FPOS (was: Re: "buggy cmd640" message followed by soft lockup) Bartlomiej Zolnierkiewicz
[not found] ` <200711242038.06677.elendil@planet.nl>
1 sibling, 1 reply; 22+ messages in thread
From: Rafael J. Wysocki @ 2007-11-24 19:07 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Frans Pop, linux-ide, linux-kernel, Andrew Morton
On Saturday, 24 of November 2007, Bartlomiej Zolnierkiewicz wrote:
[--snip--]
> Rafael, I see that you've filled a bug for this bugreport into kernel
> bugzilla tracker (one day after the bugreport):
>
> http://bugzilla.kernel.org/show_bug.cgi?id=9442
>
> Since we try to address regressions with the highest priority in the
> IDE-land (and usually they get fixed quickly) I would strongly prefer to
> use bugzilla only for long-term bugs and avoid the needless bureaucracy.
As a rule, I put all of the reported regressions into the Bugzilla early. You
are not required to use these entries for tracking the bugs, though. If you
don't want to, just leave the entry as is and I'll close it when the fix is in
the Linus' tree.
> Therefore I kindly ask you to defer filling bugs for new bugreports for
> a week or two, and give us some time to react (and always ping me about
> the bugreport status before filling bugzilla entry).
Well, I thought you'd get an email from the Bugzilla, but of course I can notify
you directly about reported regressions related to IDE.
> The alternative solution would be that you fill all new bugreports but
> then please assign them to yourself and track their status (if after two
> weeks the problem is not fixed feel free to reassign bug to me).
I can do that, but please note that the bugs filed against IDE are assigned to
you automatically, so I'll have to reassign them to me (as I've just done with
this particular entry). If you don't want them to be assigned to you at all,
please contact the Bugzilla administrators and ask them to change that.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: "buggy cmd640" message followed by soft lockup
[not found] ` <200711242038.06677.elendil@planet.nl>
@ 2007-11-24 20:12 ` Rafael J. Wysocki
[not found] ` <200711250013.51279.bzolnier@gmail.com>
1 sibling, 0 replies; 22+ messages in thread
From: Rafael J. Wysocki @ 2007-11-24 20:12 UTC (permalink / raw)
To: Frans Pop; +Cc: Bartlomiej Zolnierkiewicz, linux-ide, linux-kernel
On Saturday, 24 of November 2007, Frans Pop wrote:
> On Saturday 24 November 2007, Bartlomiej Zolnierkiewicz wrote:
> > Unfortunately I'm unable to reproduce this with:
> >
> > * VirtualBox 1.5.2 from http://www.virtualbox.org
> > (VirtualBox-1.5.2_25433_fedora7-1.i586.rpm)
> >
> > * Fedora 7 with kernel-2.6.22.9-91.fc7 as a host OS
> >
> > * Fedora 8 with vanilla 2.6.24-rc2 as a guest OS
> > (using the kernel config posted by you)
> >
> > so right now I suspect either a problem somehow specific to your system
> > (narrowing it down using git-bisect to a specific kernel commit would
> > greatly help) or a weird gcc bug (please make sure that you are using
> > non-buggy/up-to-date gcc version).
>
> Thanks for looking at the issue Bartlomiej.
>
> I started a bisect yesterday and suddenly found I could not reproduce the
> issue anymore. Today I tried again and _did_ manage to reproduce the issue
> again, but only with a 24-rc3 kernel, not with 24-rc1 or 24-rc2 kernels.
> And also only in combination with ata_piix and not with piix (one or the
> other blacklisted). Also, after I changed the setup of the VM (changed
> default boot medium from CD-ROM to hard disk), the kernel that failed
> suddenly booted correctly.
> Both of these (module used and boot order) could explain why I could not
> reproduce the issue yesterday.
>
> After I changed the boot order back I could reproduce the BUG again, but
> seemingly completely random for 24-rc1, 24-rc2 and 24-rc3: sometimes a
> kernel boots fine, other times it fails. It may be related to way the
> system is shut down, but I'm not sure of that.
>
> My conclusion is that the base cause is probably an issue somewhere in
> VirtualBox, but I suspect there is also something not 100% clean in the
> kernel code (if only a missing sanity check). Especially since I've never
> yet been able to reproduce it with a kernel before 2.6.24-rcX.
>
> However, as it seems there are various variables involved and I cannot be
> confident that I can reliably reproduce the issue with different kernels, I
> do not really see any point in trying to bisect this.
>
> I suggest closing #9442 in bugzilla as it does not seem worth tracking this
> as a regression.
Closed.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 22+ messages in thread
* kernel bugzilla is FPOS (was: Re: "buggy cmd640" message followed by soft lockup)
2007-11-24 19:07 ` Rafael J. Wysocki
@ 2007-11-25 0:26 ` Bartlomiej Zolnierkiewicz
2007-11-25 13:11 ` Rafael J. Wysocki
0 siblings, 1 reply; 22+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2007-11-25 0:26 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-ide, linux-kernel, Andrew Morton
[ I removed Frans from cc: since it is off-topic to the original bugreport ]
On Saturday 24 November 2007, Rafael J. Wysocki wrote:
> On Saturday, 24 of November 2007, Bartlomiej Zolnierkiewicz wrote:
> [--snip--]
> > Rafael, I see that you've filled a bug for this bugreport into kernel
> > bugzilla tracker (one day after the bugreport):
> >
> > http://bugzilla.kernel.org/show_bug.cgi?id=9442
> >
> > Since we try to address regressions with the highest priority in the
> > IDE-land (and usually they get fixed quickly) I would strongly prefer to
> > use bugzilla only for long-term bugs and avoid the needless bureaucracy.
>
> As a rule, I put all of the reported regressions into the Bugzilla early. You
> are not required to use these entries for tracking the bugs, though. If you
[ I really don't think that the recent push from both Andrew and you in
bugzilla direction is a good thing... ]
There is a mix of technical and psychological issues with using bugzilla:
* Interface for filling bugs is a joke:
- help for "Product" selection is mediocre
("IO/Storage:" -> "Bugs related to IO")
- there is no help for "Componenet" selection
- "Some basic debugging hints" are not there
- "Kernel version" given by reporter should be checked against the latest
kernel version and if not matching there should be a kind request to
retest with the latest kernel
- it should be strongly suggested to attach dmesg output and kernel config
- zillion other little improvements...
[ The average bug quality is not very high (bugs often lack critical
information) and this is really not reporters' fault! The interface
should be kept as simple as possible but if the reporter wants to
find some help and hints they should be there. ]
* Bugs that sit in NEEDINFO state for more than i.e. one month should be
automatically closed.
* After each major kernel release bugzilla should send a kind request for
retesting to all open bugs.
* You can't close/reject bugs by email.
* There is "Assigned-to:" field which is described as "This is the person in
charge of resolving the bug." in bugzilla's help so people get assumptions
that there is somebody who is supposed to handle the bug and that this
person should be actively working on it. Both assumptions may be invalid
(orhpaned drivers, there are more high priority bugs etc.). OTOH mailing
list doesn't give such assumptions and encourages more active attitudes
of bugreporters.
[ also compare this with "Maintained" definition in MAINTAINERS file ]
* From maintainer/developer POV you really want to track bugs in public
(mailing list) so other people can jump in and help.
[ It is also important that the other developers see that you are active. ]
* We want bug tracking the other way around: everything goes through mailing
list first (including bugs filled to the bug tracker) and if not fixed
quickly, somebody (maintainer of the given part of code or a higher level
maintainer) replies cc:ing bugzilla so the new bug entry is added.
Also this way we fix trivial/easy/medium bugs ASAP or reject invalid ones
without any bugzilla overhead. We also add a new patch description tags:
- "Fixes-bug:" tag with reference to the original discussion
and
- "Fixes-commit:" tag with reference to the kernel commit
which are automatically snooped by bugzilla from git so we keep info about
fixed bugs/regression for statistics, bugs history and to aid -stable team
in their efforts.
[ This is just a blurry sketch of the desired workflow but please note how
this is different from just assigning your component to the mailing list
address which should already be possible. ]
* Last but not least our bugzilla just looks ugly (it is _very_ important,
I feel disgusted each time I have to work with it, OTOH I love using
gitweb - you get the idea).
Sigh, I've just realized that comparing to source code control we are in
the "stone-age" when it comes to bug tracking. Hmm, what about switching
to some proprietary bug tracking system just to talk Linus into writing
a superior one? ;-)
> don't want to, just leave the entry as is and I'll close it when the fix is in
> the Linus' tree.
> > Therefore I kindly ask you to defer filling bugs for new bugreports for
> > a week or two, and give us some time to react (and always ping me about
> > the bugreport status before filling bugzilla entry).
>
> Well, I thought you'd get an email from the Bugzilla, but of course I can notify
> you directly about reported regressions related to IDE.
I do get mails from bugzilla so if you are going to assign these bugs to
yourself and track them, then no need to notify me.
[ I also regularly read your regressions list. ]
> > The alternative solution would be that you fill all new bugreports but
> > then please assign them to yourself and track their status (if after two
> > weeks the problem is not fixed feel free to reassign bug to me).
>
> I can do that, but please note that the bugs filed against IDE are assigned to
> you automatically, so I'll have to reassign them to me (as I've just done with
Thank you.
> this particular entry). If you don't want them to be assigned to you at all,
> please contact the Bugzilla administrators and ask them to change that.
Well, I consider this from time to time...
Bart
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: kernel bugzilla is FPOS (was: Re: "buggy cmd640" message followed by soft lockup)
2007-11-25 0:26 ` kernel bugzilla is FPOS (was: Re: "buggy cmd640" message followed by soft lockup) Bartlomiej Zolnierkiewicz
@ 2007-11-25 13:11 ` Rafael J. Wysocki
2007-11-25 13:49 ` Adrian Bunk
2007-11-25 14:08 ` Bartlomiej Zolnierkiewicz
0 siblings, 2 replies; 22+ messages in thread
From: Rafael J. Wysocki @ 2007-11-25 13:11 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: linux-ide, linux-kernel, Andrew Morton, Natalie Protasevich, Adrian Bunk
On Sunday, 25 of November 2007, Bartlomiej Zolnierkiewicz wrote:
>
> [ I removed Frans from cc: since it is off-topic to the original bugreport ]
>
> On Saturday 24 November 2007, Rafael J. Wysocki wrote:
> > On Saturday, 24 of November 2007, Bartlomiej Zolnierkiewicz wrote:
> > [--snip--]
> > > Rafael, I see that you've filled a bug for this bugreport into kernel
> > > bugzilla tracker (one day after the bugreport):
> > >
> > > http://bugzilla.kernel.org/show_bug.cgi?id=9442
> > >
> > > Since we try to address regressions with the highest priority in the
> > > IDE-land (and usually they get fixed quickly) I would strongly prefer to
> > > use bugzilla only for long-term bugs and avoid the needless bureaucracy.
> >
> > As a rule, I put all of the reported regressions into the Bugzilla early. You
> > are not required to use these entries for tracking the bugs, though. If you
>
> [ I really don't think that the recent push from both Andrew and you in
> bugzilla direction is a good thing... ]
Well, I use the Bugzilla as a tool for tracking regressions.
You don't need to use or even follow the entries created by me, but some
people do with good results.
> There is a mix of technical and psychological issues with using bugzilla:
>
> * Interface for filling bugs is a joke:
> - help for "Product" selection is mediocre
> ("IO/Storage:" -> "Bugs related to IO")
Here, I agree, but IMO that's an organizational issue. We first should assign
people to handling bugs related to various subsystems and based on that create
the menu so that the right people are notified of the reports.
> - there is no help for "Componenet" selection
> - "Some basic debugging hints" are not there
It looks like you'd like the reporter to initially debug the issue for you
before actually reporting it. I don't think it's realistic. ;-)
> - "Kernel version" given by reporter should be checked against the latest
> kernel version and if not matching there should be a kind request to
> retest with the latest kernel
Why?
If someone has a problem with 2.6.23.x which has already been fixed in the
mainline, we should be able to point him to the fix. If we aren't, then
something is wrong on our side.
> - it should be strongly suggested to attach dmesg output and kernel config
I, personally, don't like reports with dmesgs and .configs attached from the
start, especially if they are cut'n'pasted into the message window, because
they often don't contain the relevant information.
> - zillion other little improvements...
Sure, improvements are always possible. :-)
> [ The average bug quality is not very high (bugs often lack critical
> information) and this is really not reporters' fault! The interface
> should be kept as simple as possible but if the reporter wants to
> find some help and hints they should be there. ]
IMO, if there's a user who has a problem with _our_ code, we should do our best
to help him even if he doesn't report the bug very well. Also, if the problem
is not with the most recent kernel, we should at least ask the reporter to try
a newer version.
> * Bugs that sit in NEEDINFO state for more than i.e. one month should be
> automatically closed.
I agree that we probably should do something like this.
> * After each major kernel release bugzilla should send a kind request for
> retesting to all open bugs.
Good idea, IMO.
> * You can't close/reject bugs by email.
Well, how would you authenticate?
> * There is "Assigned-to:" field which is described as "This is the person in
> charge of resolving the bug." in bugzilla's help so people get assumptions
> that there is somebody who is supposed to handle the bug and that this
> person should be actively working on it. Both assumptions may be invalid
> (orhpaned drivers, there are more high priority bugs etc.).
True and that's why I think there should be some poeple officially resposnible
for handling bugs (which involves talking with the reporter and forwarding the
bug to an appropriate developer if necessary etc.).
> OTOH mailing list doesn't give such assumptions and encourages more active
> attitudes of bugreporters.
Nothing prevents bugreporters from sending emails along with filing Bugzilla
reports.
> [ also compare this with "Maintained" definition in MAINTAINERS file ]
>
> * From maintainer/developer POV you really want to track bugs in public
> (mailing list) so other people can jump in and help.
>
> [ It is also important that the other developers see that you are active. ]
You can always ask on the list, pointing to the Bugzilla entry in question.
> * We want bug tracking the other way around: everything goes through mailing
> list first (including bugs filled to the bug tracker) and if not fixed
> quickly, somebody (maintainer of the given part of code or a higher level
> maintainer) replies cc:ing bugzilla so the new bug entry is added.
>
> Also this way we fix trivial/easy/medium bugs ASAP or reject invalid ones
> without any bugzilla overhead. We also add a new patch description tags:
> - "Fixes-bug:" tag with reference to the original discussion
Alternatively, we can give a Bugzilla link here pointing to the entry which
contains a pointer to the original discussion. [This may be more convenient,
since some bugs are reported multiple times and tracked separately to the point
in which it turns out that they really are the same.]
> and
> - "Fixes-commit:" tag with reference to the kernel commit
> which are automatically snooped by bugzilla from git so we keep info about
> fixed bugs/regression for statistics, bugs history and to aid -stable team
> in their efforts.
>
> [ This is just a blurry sketch of the desired workflow but please note how
> this is different from just assigning your component to the mailing list
> address which should already be possible. ]
This obviously is a matter for discussion.
I think that many bugs have been lost, because they haven't be recorded
anywhere and the Bugzilla is a place where you can record information about
the bug with some references to more information, if need be. [BTW, that's
exactly what I use it for.]
> * Last but not least our bugzilla just looks ugly (it is _very_ important,
> I feel disgusted each time I have to work with it, OTOH I love using
> gitweb - you get the idea).
Well, that doesn't matter to me as long as it's useful. Any ideas how to
improve that? ;-)
> Sigh, I've just realized that comparing to source code control we are in
> the "stone-age" when it comes to bug tracking.
I agree.
> Hmm, what about switching to some proprietary bug tracking system just to
> talk Linus into writing a superior one? ;-)
I think that we just have to get an idea of what exactly is needed. IOW, we
need to know exactly how we're going to handle bugs as much as we needed
to know exactly how we were going the handle the flow of changes.
Perhaps it would be necessary to use a proprietary bug tracking system for some
time for this purpose, but _maybe_ we can figure it out without anything like
that.
The first, most important, step is to realize that we have a problem ...
> > don't want to, just leave the entry as is and I'll close it when the fix is in
> > the Linus' tree.
>
> > > Therefore I kindly ask you to defer filling bugs for new bugreports for
> > > a week or two, and give us some time to react (and always ping me about
> > > the bugreport status before filling bugzilla entry).
> >
> > Well, I thought you'd get an email from the Bugzilla, but of course I can notify
> > you directly about reported regressions related to IDE.
>
> I do get mails from bugzilla so if you are going to assign these bugs to
> yourself and track them, then no need to notify me.
>
> [ I also regularly read your regressions list. ]
OK :-)
> > > The alternative solution would be that you fill all new bugreports but
> > > then please assign them to yourself and track their status (if after two
> > > weeks the problem is not fixed feel free to reassign bug to me).
> >
> > I can do that, but please note that the bugs filed against IDE are assigned to
> > you automatically, so I'll have to reassign them to me (as I've just done with
>
> Thank you.
>
> > this particular entry). If you don't want them to be assigned to you at all,
> > please contact the Bugzilla administrators and ask them to change that.
>
> Well, I consider this from time to time...
Greetings,
Rafael
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: kernel bugzilla is FPOS (was: Re: "buggy cmd640" message followed by soft lockup)
2007-11-25 13:11 ` Rafael J. Wysocki
@ 2007-11-25 13:49 ` Adrian Bunk
2007-11-25 20:07 ` Rafael J. Wysocki
2007-11-25 14:08 ` Bartlomiej Zolnierkiewicz
1 sibling, 1 reply; 22+ messages in thread
From: Adrian Bunk @ 2007-11-25 13:49 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Bartlomiej Zolnierkiewicz, linux-ide, linux-kernel,
Andrew Morton, Natalie Protasevich
On Sun, Nov 25, 2007 at 02:11:15PM +0100, Rafael J. Wysocki wrote:
> On Sunday, 25 of November 2007, Bartlomiej Zolnierkiewicz wrote:
>...
> > On Saturday 24 November 2007, Rafael J. Wysocki wrote:
> > > On Saturday, 24 of November 2007, Bartlomiej Zolnierkiewicz wrote:
>...
> > - zillion other little improvements...
>
> Sure, improvements are always possible. :-)
>
> > [ The average bug quality is not very high (bugs often lack critical
> > information) and this is really not reporters' fault! The interface
> > should be kept as simple as possible but if the reporter wants to
> > find some help and hints they should be there. ]
>
> IMO, if there's a user who has a problem with _our_ code, we should do our best
> to help him even if he doesn't report the bug very well. Also, if the problem
> is not with the most recent kernel, we should at least ask the reporter to try
> a newer version.
Completely ACK'ed.
Also keep in mind:
Andrew is going through all new bug reports.
People like Natalie or me also go through new bug reports.
Good bug reports are valuable contributions.
Bug reporters are humans.
In my experience, most bug reporters are more than willing to provide
any kind of information or testing when requested.
And not to forget:
All the problems with bug report quality are not better when the bug
report comes via email.
> > * Bugs that sit in NEEDINFO state for more than i.e. one month should be
> > automatically closed.
>
> I agree that we probably should do something like this.
Not automatically.
Often submitters answer the question that led to the NEEDINFO state but
don't change the state.
And I know this, since going through all bugs in the NEEDINFO state and
either closing them or removing the NEEDINFO is a simple and not too big
task I'm sometimes doing.
> > * After each major kernel release bugzilla should send a kind request for
> > retesting to all open bugs.
>
> Good idea, IMO.
Good idea ... for pissing off bug submitters.
We have many bug reports in the Bugzilla with very responsive submitters
who wrote very good bug reports but have the bad luck that it's in an
area without a maintainer looking after the bug.
>...
> > [ also compare this with "Maintained" definition in MAINTAINERS file ]
> >
> > * From maintainer/developer POV you really want to track bugs in public
> > (mailing list) so other people can jump in and help.
> >
> > [ It is also important that the other developers see that you are active. ]
>
> You can always ask on the list, pointing to the Bugzilla entry in question.
You can also assign bugs for some component by default to some real or
dummy address that forwards everything from the Bugzilla bug (starting
with the initial bug report) to some mailing list.
And when people answer to this email, the answers will be tracked in
Bugzilla.
> > * We want bug tracking the other way around: everything goes through mailing
> > list first (including bugs filled to the bug tracker) and if not fixed
> > quickly, somebody (maintainer of the given part of code or a higher level
> > maintainer) replies cc:ing bugzilla so the new bug entry is added.
> >
> > Also this way we fix trivial/easy/medium bugs ASAP or reject invalid ones
> > without any bugzilla overhead. We also add a new patch description tags:
> > - "Fixes-bug:" tag with reference to the original discussion
>
> Alternatively, we can give a Bugzilla link here pointing to the entry which
> contains a pointer to the original discussion. [This may be more convenient,
> since some bugs are reported multiple times and tracked separately to the point
> in which it turns out that they really are the same.]
It would be best if bugs would initially be entered in Bugzilla.
If you have a permanent cookie with the Bugzilla authentification in
your browser the overhead of closing a bug is to click on the link in
the Bugzilla email plus 2 clicks in the browser.
>...
> 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: kernel bugzilla is FPOS (was: Re: "buggy cmd640" message followed by soft lockup)
2007-11-25 13:11 ` Rafael J. Wysocki
2007-11-25 13:49 ` Adrian Bunk
@ 2007-11-25 14:08 ` Bartlomiej Zolnierkiewicz
2007-11-25 20:25 ` Rafael J. Wysocki
1 sibling, 1 reply; 22+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2007-11-25 14:08 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: linux-ide, linux-kernel, Andrew Morton, Natalie Protasevich, Adrian Bunk
Hi,
On Sunday 25 November 2007, Rafael J. Wysocki wrote:
> On Sunday, 25 of November 2007, Bartlomiej Zolnierkiewicz wrote:
> >
> > [ I removed Frans from cc: since it is off-topic to the original bugreport ]
> >
> > On Saturday 24 November 2007, Rafael J. Wysocki wrote:
> > > On Saturday, 24 of November 2007, Bartlomiej Zolnierkiewicz wrote:
> > > [--snip--]
> > > > Rafael, I see that you've filled a bug for this bugreport into kernel
> > > > bugzilla tracker (one day after the bugreport):
> > > >
> > > > http://bugzilla.kernel.org/show_bug.cgi?id=9442
> > > >
> > > > Since we try to address regressions with the highest priority in the
> > > > IDE-land (and usually they get fixed quickly) I would strongly prefer to
> > > > use bugzilla only for long-term bugs and avoid the needless bureaucracy.
> > >
> > > As a rule, I put all of the reported regressions into the Bugzilla early. You
> > > are not required to use these entries for tracking the bugs, though. If you
> >
> > [ I really don't think that the recent push from both Andrew and you in
> > bugzilla direction is a good thing... ]
>
> Well, I use the Bugzilla as a tool for tracking regressions.
>
> You don't need to use or even follow the entries created by me, but some
> people do with good results.
>
> > There is a mix of technical and psychological issues with using bugzilla:
> >
> > * Interface for filling bugs is a joke:
> > - help for "Product" selection is mediocre
> > ("IO/Storage:" -> "Bugs related to IO")
>
> Here, I agree, but IMO that's an organizational issue. We first should assign
> people to handling bugs related to various subsystems and based on that create
> the menu so that the right people are notified of the reports.
>
> > - there is no help for "Componenet" selection
> > - "Some basic debugging hints" are not there
>
> It looks like you'd like the reporter to initially debug the issue for you
> before actually reporting it. I don't think it's realistic. ;-)
Give people right hints and tools and they will work miracles. ;-)
If user reports hard lockup propably the first thing to ask will be
to try NMI watchdog etc. We have this kind of information spreaded
through various files in Documentation/ (and also other sources).
What we right now we have in bugzilla is:
"
Some basic debugging hints
* Diagnosing OOM conditions
* Debugging kernel hangs
* Setting up a serial console
"
[ at http://test.kernel.org/bugzilla/faq.html ]
and all entries end up with "This page does not exist yet. You can create
a new empty page, or use one of the page templates. Before creating the
page, please check if a similar page already exists."
> > - "Kernel version" given by reporter should be checked against the latest
> > kernel version and if not matching there should be a kind request to
> > retest with the latest kernel
>
> Why?
To speedup a process.
> If someone has a problem with 2.6.23.x which has already been fixed in the
> mainline, we should be able to point him to the fix. If we aren't, then
> something is wrong on our side.
Sure there is something wrong on our side as we don't store this kind of
information in organized way currently.
> > - it should be strongly suggested to attach dmesg output and kernel config
>
> I, personally, don't like reports with dmesgs and .configs attached from the
> start, especially if they are cut'n'pasted into the message window, because
I do.
> they often don't contain the relevant information.
If you are lucky the right information will be there and it will save both
reporter and the developer one "communication cycle".
> > - zillion other little improvements...
>
> Sure, improvements are always possible. :-)
>
> > [ The average bug quality is not very high (bugs often lack critical
> > information) and this is really not reporters' fault! The interface
> > should be kept as simple as possible but if the reporter wants to
> > find some help and hints they should be there. ]
>
> IMO, if there's a user who has a problem with _our_ code, we should do our best
> to help him even if he doesn't report the bug very well. Also, if the problem
> is not with the most recent kernel, we should at least ask the reporter to try
> a newer version.
Fully agreed.
I rather meant that the we can make the process work better for both sides.
> > * Bugs that sit in NEEDINFO state for more than i.e. one month should be
> > automatically closed.
>
> I agree that we probably should do something like this.
>
> > * After each major kernel release bugzilla should send a kind request for
> > retesting to all open bugs.
>
> Good idea, IMO.
>
> > * You can't close/reject bugs by email.
>
> Well, how would you authenticate?
Technically it is not a problem at all, i.e. you can sign mail with GPG etc.
> > * There is "Assigned-to:" field which is described as "This is the person in
> > charge of resolving the bug." in bugzilla's help so people get assumptions
> > that there is somebody who is supposed to handle the bug and that this
> > person should be actively working on it. Both assumptions may be invalid
> > (orhpaned drivers, there are more high priority bugs etc.).
>
> True and that's why I think there should be some poeple officially resposnible
> for handling bugs (which involves talking with the reporter and forwarding the
> bug to an appropriate developer if necessary etc.).
>
> > OTOH mailing list doesn't give such assumptions and encourages more active
> > attitudes of bugreporters.
>
> Nothing prevents bugreporters from sending emails along with filing Bugzilla
> reports.
Duplicating efforts is not good thing (wasted time).
[...]
> > * Last but not least our bugzilla just looks ugly (it is _very_ important,
> > I feel disgusted each time I have to work with it, OTOH I love using
> > gitweb - you get the idea).
>
> Well, that doesn't matter to me as long as it's useful. Any ideas how to
> improve that? ;-)
Well, I hope that we can use some help from distro people here
(many distros have bugzillas superior to our).
Bart
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: kernel bugzilla is FPOS (was: Re: "buggy cmd640" message followed by soft lockup)
2007-11-25 13:49 ` Adrian Bunk
@ 2007-11-25 20:07 ` Rafael J. Wysocki
2007-11-25 20:08 ` Dr. David Alan Gilbert
2007-11-25 20:32 ` Adrian Bunk
0 siblings, 2 replies; 22+ messages in thread
From: Rafael J. Wysocki @ 2007-11-25 20:07 UTC (permalink / raw)
To: Adrian Bunk
Cc: Bartlomiej Zolnierkiewicz, linux-ide, linux-kernel,
Andrew Morton, Natalie Protasevich
On Sunday, 25 of November 2007, Adrian Bunk wrote:
> On Sun, Nov 25, 2007 at 02:11:15PM +0100, Rafael J. Wysocki wrote:
> > On Sunday, 25 of November 2007, Bartlomiej Zolnierkiewicz wrote:
> >...
> > > On Saturday 24 November 2007, Rafael J. Wysocki wrote:
> > > > On Saturday, 24 of November 2007, Bartlomiej Zolnierkiewicz wrote:
> >...
> > > - zillion other little improvements...
> >
> > Sure, improvements are always possible. :-)
> >
> > > [ The average bug quality is not very high (bugs often lack critical
> > > information) and this is really not reporters' fault! The interface
> > > should be kept as simple as possible but if the reporter wants to
> > > find some help and hints they should be there. ]
> >
> > IMO, if there's a user who has a problem with _our_ code, we should do our best
> > to help him even if he doesn't report the bug very well. Also, if the problem
> > is not with the most recent kernel, we should at least ask the reporter to try
> > a newer version.
>
>
> Completely ACK'ed.
>
> Also keep in mind:
>
> Andrew is going through all new bug reports.
> People like Natalie or me also go through new bug reports.
>
> Good bug reports are valuable contributions.
> Bug reporters are humans.
> In my experience, most bug reporters are more than willing to provide
> any kind of information or testing when requested.
>
> And not to forget:
> All the problems with bug report quality are not better when the bug
> report comes via email.
>
>
> > > * Bugs that sit in NEEDINFO state for more than i.e. one month should be
> > > automatically closed.
> >
> > I agree that we probably should do something like this.
>
> Not automatically.
OK, say "as a rule".
> Often submitters answer the question that led to the NEEDINFO state but
> don't change the state.
>
> And I know this, since going through all bugs in the NEEDINFO state and
> either closing them or removing the NEEDINFO is a simple and not too big
> task I'm sometimes doing.
I think we can set a rule that NEEDINFO bugs with a developer request not
responded to by the reporter for a month are closable. Everyone with
sufficient access rights who spots such a bug can close it.
> > > * After each major kernel release bugzilla should send a kind request for
> > > retesting to all open bugs.
> >
> > Good idea, IMO.
>
> Good idea ... for pissing off bug submitters.
>
> We have many bug reports in the Bugzilla with very responsive submitters
> who wrote very good bug reports but have the bad luck that it's in an
> area without a maintainer looking after the bug.
These are two different issues.
On the one hand, I don't see anything wrong with encouraging bug reporters to
test new kernels, especially if the reported problems depend on hardware, as it
is possible that the bug will get fixed as a result of a loosely related change
(like a fix for another bug etc.). [Still, in such cases it would be good to
identify the change that fixes the problem anyway.]
OTOH, the situations in which good bug reports are not responded to are not
acceptable. There should be a way to make developers take care of _their_
code, because by not doing so they hurt us all, big time.
> >...
> > > [ also compare this with "Maintained" definition in MAINTAINERS file ]
> > >
> > > * From maintainer/developer POV you really want to track bugs in public
> > > (mailing list) so other people can jump in and help.
> > >
> > > [ It is also important that the other developers see that you are active. ]
> >
> > You can always ask on the list, pointing to the Bugzilla entry in question.
>
>
> You can also assign bugs for some component by default to some real or
> dummy address that forwards everything from the Bugzilla bug (starting
> with the initial bug report) to some mailing list.
>
> And when people answer to this email, the answers will be tracked in
> Bugzilla.
Yes.
> > > * We want bug tracking the other way around: everything goes through mailing
> > > list first (including bugs filled to the bug tracker) and if not fixed
> > > quickly, somebody (maintainer of the given part of code or a higher level
> > > maintainer) replies cc:ing bugzilla so the new bug entry is added.
> > >
> > > Also this way we fix trivial/easy/medium bugs ASAP or reject invalid ones
> > > without any bugzilla overhead. We also add a new patch description tags:
> > > - "Fixes-bug:" tag with reference to the original discussion
> >
> > Alternatively, we can give a Bugzilla link here pointing to the entry which
> > contains a pointer to the original discussion. [This may be more convenient,
> > since some bugs are reported multiple times and tracked separately to the point
> > in which it turns out that they really are the same.]
>
>
> It would be best if bugs would initially be entered in Bugzilla.
The Bugzilla has a considerable "barrier to entry" for new bug reporters, as
it pretends to require them to spend quite a lot of time on the bug report.
Also, some developers do not consider the Bugzilla as a useful thing and
wouldn't like to use it (which is why this thread has appeared, among other
things ;-)).
> If you have a permanent cookie with the Bugzilla authentification in
> your browser the overhead of closing a bug is to click on the link in
> the Bugzilla email plus 2 clicks in the browser.
Sure.
Greetings,
Rafael
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: kernel bugzilla is FPOS (was: Re: "buggy cmd640" message followed by soft lockup)
2007-11-25 20:07 ` Rafael J. Wysocki
@ 2007-11-25 20:08 ` Dr. David Alan Gilbert
2007-11-25 20:32 ` Adrian Bunk
1 sibling, 0 replies; 22+ messages in thread
From: Dr. David Alan Gilbert @ 2007-11-25 20:08 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Adrian Bunk, Bartlomiej Zolnierkiewicz, linux-ide, linux-kernel,
Andrew Morton, Natalie Protasevich
* Rafael J. Wysocki (rjw@sisk.pl) wrote:
<snip>
(many levels of quote)
> > > > * Bugs that sit in NEEDINFO state for more than i.e. one month should be
> > > > automatically closed.
> > >
> > > I agree that we probably should do something like this.
> >
> > Not automatically.
>
> OK, say "as a rule".
The only thing I would say is that a reporter can be in a situation
after a while where they no longer have access to the original
machine; if the bug was originally believed to be real and triaged
then it seems to make sense to differentiate that from a bug that is
just closed, just so people can know there is an issue with
a configuration.
Dave
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: kernel bugzilla is FPOS (was: Re: "buggy cmd640" message followed by soft lockup)
2007-11-25 14:08 ` Bartlomiej Zolnierkiewicz
@ 2007-11-25 20:25 ` Rafael J. Wysocki
0 siblings, 0 replies; 22+ messages in thread
From: Rafael J. Wysocki @ 2007-11-25 20:25 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: linux-ide, linux-kernel, Andrew Morton, Natalie Protasevich, Adrian Bunk
On Sunday, 25 of November 2007, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Sunday 25 November 2007, Rafael J. Wysocki wrote:
> > On Sunday, 25 of November 2007, Bartlomiej Zolnierkiewicz wrote:
> > >
> > > [ I removed Frans from cc: since it is off-topic to the original bugreport ]
> > >
> > > On Saturday 24 November 2007, Rafael J. Wysocki wrote:
> > > > On Saturday, 24 of November 2007, Bartlomiej Zolnierkiewicz wrote:
> > > > [--snip--]
> > > > > Rafael, I see that you've filled a bug for this bugreport into kernel
> > > > > bugzilla tracker (one day after the bugreport):
> > > > >
> > > > > http://bugzilla.kernel.org/show_bug.cgi?id=9442
> > > > >
> > > > > Since we try to address regressions with the highest priority in the
> > > > > IDE-land (and usually they get fixed quickly) I would strongly prefer to
> > > > > use bugzilla only for long-term bugs and avoid the needless bureaucracy.
> > > >
> > > > As a rule, I put all of the reported regressions into the Bugzilla early. You
> > > > are not required to use these entries for tracking the bugs, though. If you
> > >
> > > [ I really don't think that the recent push from both Andrew and you in
> > > bugzilla direction is a good thing... ]
> >
> > Well, I use the Bugzilla as a tool for tracking regressions.
> >
> > You don't need to use or even follow the entries created by me, but some
> > people do with good results.
> >
> > > There is a mix of technical and psychological issues with using bugzilla:
> > >
> > > * Interface for filling bugs is a joke:
> > > - help for "Product" selection is mediocre
> > > ("IO/Storage:" -> "Bugs related to IO")
> >
> > Here, I agree, but IMO that's an organizational issue. We first should assign
> > people to handling bugs related to various subsystems and based on that create
> > the menu so that the right people are notified of the reports.
> >
> > > - there is no help for "Componenet" selection
> > > - "Some basic debugging hints" are not there
> >
> > It looks like you'd like the reporter to initially debug the issue for you
> > before actually reporting it. I don't think it's realistic. ;-)
>
> Give people right hints and tools and they will work miracles. ;-)
>
> If user reports hard lockup propably the first thing to ask will be
> to try NMI watchdog etc. We have this kind of information spreaded
> through various files in Documentation/ (and also other sources).
That's correct, and we generally need to gather it in one place. Still, I'm
not sure if that should be the Bugzilla.
> What we right now we have in bugzilla is:
>
> "
> Some basic debugging hints
>
> * Diagnosing OOM conditions
> * Debugging kernel hangs
> * Setting up a serial console
> "
>
> [ at http://test.kernel.org/bugzilla/faq.html ]
>
> and all entries end up with "This page does not exist yet. You can create
> a new empty page, or use one of the page templates. Before creating the
> page, please check if a similar page already exists."
>
> > > - "Kernel version" given by reporter should be checked against the latest
> > > kernel version and if not matching there should be a kind request to
> > > retest with the latest kernel
> >
> > Why?
>
> To speedup a process.
This way we can overlook some bugs unreproducible with the latest-greatest for
whatever the reason, but still present and waiting to bite us when we unhide
them.
> > If someone has a problem with 2.6.23.x which has already been fixed in the
> > mainline, we should be able to point him to the fix. If we aren't, then
> > something is wrong on our side.
>
> Sure there is something wrong on our side as we don't store this kind of
> information in organized way currently.
Yes, that's one of the things we should fix, IMO.
> > > - it should be strongly suggested to attach dmesg output and kernel config
> >
> > I, personally, don't like reports with dmesgs and .configs attached from the
> > start, especially if they are cut'n'pasted into the message window, because
>
> I do.
>
> > they often don't contain the relevant information.
>
> If you are lucky the right information will be there and it will save both
> reporter and the developer one "communication cycle".
It usually doesn't. Anyway, you need to acknowledge the report and asking the
submitter to provide you with additional information doesn't cost that much.
OTOH, if the bug report is not directed at the right person from the start,
it gets redirected and then the reporter is often asked for the information
he's already provided and that's annoying.
> > > - zillion other little improvements...
> >
> > Sure, improvements are always possible. :-)
> >
> > > [ The average bug quality is not very high (bugs often lack critical
> > > information) and this is really not reporters' fault! The interface
> > > should be kept as simple as possible but if the reporter wants to
> > > find some help and hints they should be there. ]
> >
> > IMO, if there's a user who has a problem with _our_ code, we should do our best
> > to help him even if he doesn't report the bug very well. Also, if the problem
> > is not with the most recent kernel, we should at least ask the reporter to try
> > a newer version.
>
> Fully agreed.
>
> I rather meant that the we can make the process work better for both sides.
I'm sure we can.
In the meantime, there are bug reports coming and they need to be handled
somehow until we finally agree to do that in this or another way. ;-)
> > > * Bugs that sit in NEEDINFO state for more than i.e. one month should be
> > > automatically closed.
> >
> > I agree that we probably should do something like this.
> >
> > > * After each major kernel release bugzilla should send a kind request for
> > > retesting to all open bugs.
> >
> > Good idea, IMO.
> >
> > > * You can't close/reject bugs by email.
> >
> > Well, how would you authenticate?
>
> Technically it is not a problem at all, i.e. you can sign mail with GPG etc.
Every such method will require additional infrastructure needing to be taken
care of by someone.
> > > * There is "Assigned-to:" field which is described as "This is the person in
> > > charge of resolving the bug." in bugzilla's help so people get assumptions
> > > that there is somebody who is supposed to handle the bug and that this
> > > person should be actively working on it. Both assumptions may be invalid
> > > (orhpaned drivers, there are more high priority bugs etc.).
> >
> > True and that's why I think there should be some poeple officially resposnible
> > for handling bugs (which involves talking with the reporter and forwarding the
> > bug to an appropriate developer if necessary etc.).
> >
> > > OTOH mailing list doesn't give such assumptions and encourages more active
> > > attitudes of bugreporters.
> >
> > Nothing prevents bugreporters from sending emails along with filing Bugzilla
> > reports.
>
> Duplicating efforts is not good thing (wasted time).
Arguably, the time need not be wasted if it results in the bug being taken care
of sooner.
> [...]
>
> > > * Last but not least our bugzilla just looks ugly (it is _very_ important,
> > > I feel disgusted each time I have to work with it, OTOH I love using
> > > gitweb - you get the idea).
> >
> > Well, that doesn't matter to me as long as it's useful. Any ideas how to
> > improve that? ;-)
>
> Well, I hope that we can use some help from distro people here
> (many distros have bugzillas superior to our).
Yes, we probably can.
Greetings,
Rafael
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: kernel bugzilla is FPOS (was: Re: "buggy cmd640" message followed by soft lockup)
2007-11-25 20:07 ` Rafael J. Wysocki
2007-11-25 20:08 ` Dr. David Alan Gilbert
@ 2007-11-25 20:32 ` Adrian Bunk
2007-11-25 21:28 ` Rafael J. Wysocki
1 sibling, 1 reply; 22+ messages in thread
From: Adrian Bunk @ 2007-11-25 20:32 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Bartlomiej Zolnierkiewicz, linux-ide, linux-kernel,
Andrew Morton, Natalie Protasevich
On Sun, Nov 25, 2007 at 09:07:23PM +0100, Rafael J. Wysocki wrote:
> On Sunday, 25 of November 2007, Adrian Bunk wrote:
> > On Sun, Nov 25, 2007 at 02:11:15PM +0100, Rafael J. Wysocki wrote:
> > > On Sunday, 25 of November 2007, Bartlomiej Zolnierkiewicz wrote:
> > >...
> > > > On Saturday 24 November 2007, Rafael J. Wysocki wrote:
> > > > > On Saturday, 24 of November 2007, Bartlomiej Zolnierkiewicz wrote:
> > >...
>...
> > > > * After each major kernel release bugzilla should send a kind request for
> > > > retesting to all open bugs.
> > >
> > > Good idea, IMO.
> >
> > Good idea ... for pissing off bug submitters.
> >
> > We have many bug reports in the Bugzilla with very responsive submitters
> > who wrote very good bug reports but have the bad luck that it's in an
> > area without a maintainer looking after the bug.
>
> These are two different issues.
>
> On the one hand, I don't see anything wrong with encouraging bug reporters to
> test new kernels, especially if the reported problems depend on hardware, as it
> is possible that the bug will get fixed as a result of a loosely related change
> (like a fix for another bug etc.). [Still, in such cases it would be good to
> identify the change that fixes the problem anyway.]
It's not that much a different issue:
If there was for each bug a maintainer looking soon after it, we should
not have many bugs open for a longer time.
> OTOH, the situations in which good bug reports are not responded to are not
> acceptable. There should be a way to make developers take care of _their_
> code, because by not doing so they hurt us all, big time.
There are two different cases:
- no maintainer at all
- maintainer is too busy with other stuff for looking at bug reports
But both cases boil down to the point of how to find maintainers...
>...
> > > > * We want bug tracking the other way around: everything goes through mailing
> > > > list first (including bugs filled to the bug tracker) and if not fixed
> > > > quickly, somebody (maintainer of the given part of code or a higher level
> > > > maintainer) replies cc:ing bugzilla so the new bug entry is added.
> > > >
> > > > Also this way we fix trivial/easy/medium bugs ASAP or reject invalid ones
> > > > without any bugzilla overhead. We also add a new patch description tags:
> > > > - "Fixes-bug:" tag with reference to the original discussion
> > >
> > > Alternatively, we can give a Bugzilla link here pointing to the entry which
> > > contains a pointer to the original discussion. [This may be more convenient,
> > > since some bugs are reported multiple times and tracked separately to the point
> > > in which it turns out that they really are the same.]
> >
> >
> > It would be best if bugs would initially be entered in Bugzilla.
>
> The Bugzilla has a considerable "barrier to entry" for new bug reporters, as
> it pretends to require them to spend quite a lot of time on the bug report.
First of all, Bugzilla is a quite often used bug tracker in the open
source world [1], so many users already know it.
But more important, "it pretends to require them to spend" isn't true
because there's no pretending - we actually often require bug reporters
to spend a lot of time on the bug report (e.g. when asking for
bisecting).
I'm also sometimes writing bug reports in different areas, and in my
experience it doesn't matter whether it's web-based Bugzilla, the
email-based Debian bug tracker or whatever else system - the time spent
on a good bug report is not spend on pasting the text whereever or on
clicking on a few boxes, the time is spent on tracking the issue down
and writing a good bug report.
What matters for a bug reporter is to get a solution for his problem
within a reasonable amount of time.
> Also, some developers do not consider the Bugzilla as a useful thing and
> wouldn't like to use it (which is why this thread has appeared, among other
> things ;-)).
>...
And that's part of the problem.
Bugzilla is a usable tool, but it isn't the only tool available.
If there was one tool all developers would be willing to use that would
be a reason why we should switch to whatever tool this is.
> Greetings,
> Rafael
cu
Adrian
[1] my Seamonkey knows my passwords for more than a dozen Bugzillas
--
"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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: kernel bugzilla is FPOS (was: Re: "buggy cmd640" message followed by soft lockup)
2007-11-25 20:32 ` Adrian Bunk
@ 2007-11-25 21:28 ` Rafael J. Wysocki
2007-11-25 21:36 ` Adrian Bunk
0 siblings, 1 reply; 22+ messages in thread
From: Rafael J. Wysocki @ 2007-11-25 21:28 UTC (permalink / raw)
To: Adrian Bunk
Cc: Bartlomiej Zolnierkiewicz, linux-ide, linux-kernel,
Andrew Morton, Natalie Protasevich
On Sunday, 25 of November 2007, Adrian Bunk wrote:
> On Sun, Nov 25, 2007 at 09:07:23PM +0100, Rafael J. Wysocki wrote:
> > On Sunday, 25 of November 2007, Adrian Bunk wrote:
> > > On Sun, Nov 25, 2007 at 02:11:15PM +0100, Rafael J. Wysocki wrote:
> > > > On Sunday, 25 of November 2007, Bartlomiej Zolnierkiewicz wrote:
> > > >...
> > > > > On Saturday 24 November 2007, Rafael J. Wysocki wrote:
> > > > > > On Saturday, 24 of November 2007, Bartlomiej Zolnierkiewicz wrote:
> > > >...
> >...
> > > > > * After each major kernel release bugzilla should send a kind request for
> > > > > retesting to all open bugs.
> > > >
> > > > Good idea, IMO.
> > >
> > > Good idea ... for pissing off bug submitters.
> > >
> > > We have many bug reports in the Bugzilla with very responsive submitters
> > > who wrote very good bug reports but have the bad luck that it's in an
> > > area without a maintainer looking after the bug.
> >
> > These are two different issues.
> >
> > On the one hand, I don't see anything wrong with encouraging bug reporters to
> > test new kernels, especially if the reported problems depend on hardware, as it
> > is possible that the bug will get fixed as a result of a loosely related change
> > (like a fix for another bug etc.). [Still, in such cases it would be good to
> > identify the change that fixes the problem anyway.]
>
> It's not that much a different issue:
>
> If there was for each bug a maintainer looking soon after it, we should
> not have many bugs open for a longer time.
Apart from the bugs that no one has any idea how to fix. :-)
> > OTOH, the situations in which good bug reports are not responded to are not
> > acceptable. There should be a way to make developers take care of _their_
> > code, because by not doing so they hurt us all, big time.
>
> There are two different cases:
> - no maintainer at all
> - maintainer is too busy with other stuff for looking at bug reports
>
> But both cases boil down to the point of how to find maintainers...
Agreed.
> > > > > * We want bug tracking the other way around: everything goes through mailing
> > > > > list first (including bugs filled to the bug tracker) and if not fixed
> > > > > quickly, somebody (maintainer of the given part of code or a higher level
> > > > > maintainer) replies cc:ing bugzilla so the new bug entry is added.
> > > > >
> > > > > Also this way we fix trivial/easy/medium bugs ASAP or reject invalid ones
> > > > > without any bugzilla overhead. We also add a new patch description tags:
> > > > > - "Fixes-bug:" tag with reference to the original discussion
> > > >
> > > > Alternatively, we can give a Bugzilla link here pointing to the entry which
> > > > contains a pointer to the original discussion. [This may be more convenient,
> > > > since some bugs are reported multiple times and tracked separately to the point
> > > > in which it turns out that they really are the same.]
> > >
> > >
> > > It would be best if bugs would initially be entered in Bugzilla.
> >
> > The Bugzilla has a considerable "barrier to entry" for new bug reporters, as
> > it pretends to require them to spend quite a lot of time on the bug report.
>
> First of all, Bugzilla is a quite often used bug tracker in the open
> source world [1], so many users already know it.
>
> But more important, "it pretends to require them to spend" isn't true
> because there's no pretending - we actually often require bug reporters
> to spend a lot of time on the bug report (e.g. when asking for
> bisecting).
But not *initially*.
We should not confuse *debugging* with *reporting bugs*. While the former is
actually more difficult and more time consuming than writing the code in which
the bug is present, the latter should be as simple as sending an email.
> I'm also sometimes writing bug reports in different areas, and in my
> experience it doesn't matter whether it's web-based Bugzilla, the
> email-based Debian bug tracker or whatever else system - the time spent
> on a good bug report is not spend on pasting the text whereever or on
> clicking on a few boxes, the time is spent on tracking the issue down
> and writing a good bug report.
Apparently, you are expecting the reporters do *debug* problems, while they need
not be aware of how to do that.
IMHO, we should make reporting problems as simple as reasonably possible and
once we've learnt that a bug is present (call it a "bug notification" or
whatever if you think that "bug report" is not the right name), we can instruct
the reporter to provide us with more information, as needed.
For example, "my box doesn't boot with 2.6.24-rc3" is the kind of information
which should be sufficient for everyone on this list to come to the conclusion
that there _is_ a problem without any additional information. ;-) [Of course,
the additional information will be needed to debug the problem.]
> What matters for a bug reporter is to get a solution for his problem
> within a reasonable amount of time.
Still, it's annoying if you attach tons of information to the report and that
information does not turn out to be useful.
> > Also, some developers do not consider the Bugzilla as a useful thing and
> > wouldn't like to use it (which is why this thread has appeared, among other
> > things ;-)).
> >...
>
> And that's part of the problem.
>
> Bugzilla is a usable tool, but it isn't the only tool available.
>
> If there was one tool all developers would be willing to use that would
> be a reason why we should switch to whatever tool this is.
The choice of the tool should be a result of the choice of a *method*. IOW,
we have to know our needs and choose the tool that satisfies them or write one
if it doesn't exist.
For now, IMHO, we don't really know what we need.
Greetings,
Rafael
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: kernel bugzilla is FPOS (was: Re: "buggy cmd640" message followed by soft lockup)
2007-11-25 21:28 ` Rafael J. Wysocki
@ 2007-11-25 21:36 ` Adrian Bunk
2007-11-25 22:38 ` Rafael J. Wysocki
0 siblings, 1 reply; 22+ messages in thread
From: Adrian Bunk @ 2007-11-25 21:36 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Bartlomiej Zolnierkiewicz, linux-ide, linux-kernel,
Andrew Morton, Natalie Protasevich
On Sun, Nov 25, 2007 at 10:28:06PM +0100, Rafael J. Wysocki wrote:
> On Sunday, 25 of November 2007, Adrian Bunk wrote:
>..
> > First of all, Bugzilla is a quite often used bug tracker in the open
> > source world [1], so many users already know it.
> >
> > But more important, "it pretends to require them to spend" isn't true
> > because there's no pretending - we actually often require bug reporters
> > to spend a lot of time on the bug report (e.g. when asking for
> > bisecting).
>
> But not *initially*.
>
> We should not confuse *debugging* with *reporting bugs*. While the former is
> actually more difficult and more time consuming than writing the code in which
> the bug is present, the latter should be as simple as sending an email.
For hardcore geeks like you and me sending an email might be easier than
using some web interface.
Normal humans tend to be more accustomed to web interfaces, and
following the instructions on some web page is _much_ easier than
reading three text files for knowing what to write in an email.
> > I'm also sometimes writing bug reports in different areas, and in my
> > experience it doesn't matter whether it's web-based Bugzilla, the
> > email-based Debian bug tracker or whatever else system - the time spent
> > on a good bug report is not spend on pasting the text whereever or on
> > clicking on a few boxes, the time is spent on tracking the issue down
> > and writing a good bug report.
>
> Apparently, you are expecting the reporters do *debug* problems, while they need
> not be aware of how to do that.
>
> IMHO, we should make reporting problems as simple as reasonably possible and
Agreed, and as said above simple = web interface.
>...
> > What matters for a bug reporter is to get a solution for his problem
> > within a reasonable amount of time.
>
> Still, it's annoying if you attach tons of information to the report and that
> information does not turn out to be useful.
Agreed.
> > > Also, some developers do not consider the Bugzilla as a useful thing and
> > > wouldn't like to use it (which is why this thread has appeared, among other
> > > things ;-)).
> > >...
> >
> > And that's part of the problem.
> >
> > Bugzilla is a usable tool, but it isn't the only tool available.
> >
> > If there was one tool all developers would be willing to use that would
> > be a reason why we should switch to whatever tool this is.
>
> The choice of the tool should be a result of the choice of a *method*. IOW,
> we have to know our needs and choose the tool that satisfies them or write one
> if it doesn't exist.
>
> For now, IMHO, we don't really know what we need.
Even worse:
Different people have different opinions what they need and what they
don't want...
> 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: kernel bugzilla is FPOS (was: Re: "buggy cmd640" message followed by soft lockup)
2007-11-25 21:36 ` Adrian Bunk
@ 2007-11-25 22:38 ` Rafael J. Wysocki
2007-11-25 22:40 ` Adrian Bunk
2007-11-25 22:55 ` Rafael J. Wysocki
0 siblings, 2 replies; 22+ messages in thread
From: Rafael J. Wysocki @ 2007-11-25 22:38 UTC (permalink / raw)
To: Adrian Bunk
Cc: Bartlomiej Zolnierkiewicz, linux-ide, linux-kernel,
Andrew Morton, Natalie Protasevich
On Sunday, 25 of November 2007, Adrian Bunk wrote:
> On Sun, Nov 25, 2007 at 10:28:06PM +0100, Rafael J. Wysocki wrote:
> > On Sunday, 25 of November 2007, Adrian Bunk wrote:
> >..
> > > First of all, Bugzilla is a quite often used bug tracker in the open
> > > source world [1], so many users already know it.
> > >
> > > But more important, "it pretends to require them to spend" isn't true
> > > because there's no pretending - we actually often require bug reporters
> > > to spend a lot of time on the bug report (e.g. when asking for
> > > bisecting).
> >
> > But not *initially*.
> >
> > We should not confuse *debugging* with *reporting bugs*. While the former is
> > actually more difficult and more time consuming than writing the code in which
> > the bug is present, the latter should be as simple as sending an email.
>
> For hardcore geeks like you and me sending an email might be easier than
> using some web interface.
>
> Normal humans tend to be more accustomed to web interfaces, and
> following the instructions on some web page is _much_ easier than
> reading three text files for knowing what to write in an email.
Hm, this is a good argument for having such a web interface, but IMO it
shouldn't be mandatory. IOW, there should be a way to report a bug using plain
email, if the reporter prefers that. We can, however, request that the address
of our bug tracking system be added to the report's Cc list.
Now, the question is what information this web interface should ask for.
IMO, first, it should ask for what the bug is against, ie.:
- kernel version (to be obtained from 'git describe' or from /proc/version or
from .config, if the kernel doesn't boot)
- architecture (x86, ARM, MIPS etc.)
- subsystem and subsubsystem (that could be selectable from a menu and might
depend on the architecture)
It also should ask if the problem is a regression and what was the last known
good kernel (I'd prefer that to be the last known major release selectable from
a list).
Also, the reporter should be required to provide a summary (subject) and
a (concise) description of the problem and a list of email addresses to
send the report to in addition to the regular handling (there should be a way
to verify which addresses are acceptable).
Anything else?
Next, the report should be sent to a mailing list selected on the basis of the
information provided (not necessarily to individual developers, unless there
are some addresses provided explicitly by the reporter).
IMO, it should be possible to work on the bug using both email and the web
interface, whichever is preferred by the participant in question, without the
need to stick to any of them (ie. email messages sent in the corresponding
email thread should be registered by the bug tracking system and comments
entered into it should appear as messages in the email thread with the
appropriate To:, From: and Cc: information).
There surely are more things that we'd like it to do, but the above seem to be
a reasonable minimum.
> > > I'm also sometimes writing bug reports in different areas, and in my
> > > experience it doesn't matter whether it's web-based Bugzilla, the
> > > email-based Debian bug tracker or whatever else system - the time spent
> > > on a good bug report is not spend on pasting the text whereever or on
> > > clicking on a few boxes, the time is spent on tracking the issue down
> > > and writing a good bug report.
> >
> > Apparently, you are expecting the reporters do *debug* problems, while they need
> > not be aware of how to do that.
> >
> > IMHO, we should make reporting problems as simple as reasonably possible and
>
> Agreed, and as said above simple = web interface.
>
> >...
> > > What matters for a bug reporter is to get a solution for his problem
> > > within a reasonable amount of time.
> >
> > Still, it's annoying if you attach tons of information to the report and that
> > information does not turn out to be useful.
>
> Agreed.
>
> > > > Also, some developers do not consider the Bugzilla as a useful thing and
> > > > wouldn't like to use it (which is why this thread has appeared, among other
> > > > things ;-)).
> > > >...
> > >
> > > And that's part of the problem.
> > >
> > > Bugzilla is a usable tool, but it isn't the only tool available.
> > >
> > > If there was one tool all developers would be willing to use that would
> > > be a reason why we should switch to whatever tool this is.
> >
> > The choice of the tool should be a result of the choice of a *method*. IOW,
> > we have to know our needs and choose the tool that satisfies them or write one
> > if it doesn't exist.
> >
> > For now, IMHO, we don't really know what we need.
>
> Even worse:
> Different people have different opinions what they need and what they
> don't want...
Let's collect these opitions, then, and try to find a solution that would
satisfy all of them or at least the majority of them.
Greetings,
Rafael
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: kernel bugzilla is FPOS (was: Re: "buggy cmd640" message followed by soft lockup)
2007-11-25 22:38 ` Rafael J. Wysocki
@ 2007-11-25 22:40 ` Adrian Bunk
2007-11-25 23:28 ` Rafael J. Wysocki
2007-11-25 22:55 ` Rafael J. Wysocki
1 sibling, 1 reply; 22+ messages in thread
From: Adrian Bunk @ 2007-11-25 22:40 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Bartlomiej Zolnierkiewicz, linux-ide, linux-kernel,
Andrew Morton, Natalie Protasevich
On Sun, Nov 25, 2007 at 11:38:59PM +0100, Rafael J. Wysocki wrote:
> On Sunday, 25 of November 2007, Adrian Bunk wrote:
> > On Sun, Nov 25, 2007 at 10:28:06PM +0100, Rafael J. Wysocki wrote:
> > > On Sunday, 25 of November 2007, Adrian Bunk wrote:
> > >..
> > > > First of all, Bugzilla is a quite often used bug tracker in the open
> > > > source world [1], so many users already know it.
> > > >
> > > > But more important, "it pretends to require them to spend" isn't true
> > > > because there's no pretending - we actually often require bug reporters
> > > > to spend a lot of time on the bug report (e.g. when asking for
> > > > bisecting).
> > >
> > > But not *initially*.
> > >
> > > We should not confuse *debugging* with *reporting bugs*. While the former is
> > > actually more difficult and more time consuming than writing the code in which
> > > the bug is present, the latter should be as simple as sending an email.
> >
> > For hardcore geeks like you and me sending an email might be easier than
> > using some web interface.
> >
> > Normal humans tend to be more accustomed to web interfaces, and
> > following the instructions on some web page is _much_ easier than
> > reading three text files for knowing what to write in an email.
>
> Hm, this is a good argument for having such a web interface, but IMO it
> shouldn't be mandatory. IOW, there should be a way to report a bug using plain
> email, if the reporter prefers that. We can, however, request that the address
> of our bug tracking system be added to the report's Cc list.
Looking at both other open source projects and the support of commercial
software a web interface should be enough.
But this is not the problem - the problem is what happens after the
initial report with the bug report.
> Now, the question is what information this web interface should ask for.
>
> IMO, first, it should ask for what the bug is against, ie.:
> - kernel version (to be obtained from 'git describe' or from /proc/version or
> from .config, if the kernel doesn't boot)
> - architecture (x86, ARM, MIPS etc.)
> - subsystem and subsubsystem (that could be selectable from a menu and might
> depend on the architecture)
>
> It also should ask if the problem is a regression and what was the last known
> good kernel (I'd prefer that to be the last known major release selectable from
> a list).
>
> Also, the reporter should be required to provide a summary (subject) and
> a (concise) description of the problem and a list of email addresses to
> send the report to in addition to the regular handling (there should be a way
> to verify which addresses are acceptable).
>
> Anything else?
>
> Next, the report should be sent to a mailing list selected on the basis of the
> information provided (not necessarily to individual developers, unless there
> are some addresses provided explicitly by the reporter).
The architecture choice seems to be the only thing from your list that
isn't already available in the "Enter a new bug report" dialog of the
kernel Bugzilla.
> IMO, it should be possible to work on the bug using both email and the web
> interface, whichever is preferred by the participant in question, without the
> need to stick to any of them (ie. email messages sent in the corresponding
> email thread should be registered by the bug tracking system and comments
> entered into it should appear as messages in the email thread with the
> appropriate To:, From: and Cc: information).
>
> There surely are more things that we'd like it to do, but the above seem to be
> a reasonable minimum.
Except from the From: header in outgoing emails the kernel Bugzilla
already offers this for years.
>...
> 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: kernel bugzilla is FPOS (was: Re: "buggy cmd640" message followed by soft lockup)
2007-11-25 22:38 ` Rafael J. Wysocki
2007-11-25 22:40 ` Adrian Bunk
@ 2007-11-25 22:55 ` Rafael J. Wysocki
1 sibling, 0 replies; 22+ messages in thread
From: Rafael J. Wysocki @ 2007-11-25 22:55 UTC (permalink / raw)
To: Adrian Bunk
Cc: Bartlomiej Zolnierkiewicz, linux-ide, linux-kernel,
Andrew Morton, Natalie Protasevich
On Sunday, 25 of November 2007, Rafael J. Wysocki wrote:
> On Sunday, 25 of November 2007, Adrian Bunk wrote:
> > On Sun, Nov 25, 2007 at 10:28:06PM +0100, Rafael J. Wysocki wrote:
> > > On Sunday, 25 of November 2007, Adrian Bunk wrote:
[--snip--]
> > Even worse:
> > Different people have different opinions what they need and what they
> > don't want...
>
> Let's collect these opitions, then, and try to find a solution that would
> satisfy all of them or at least the majority of them.
s/opitions/opinions/
Sorry.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: kernel bugzilla is FPOS (was: Re: "buggy cmd640" message followed by soft lockup)
2007-11-25 22:40 ` Adrian Bunk
@ 2007-11-25 23:28 ` Rafael J. Wysocki
2007-11-25 23:34 ` Adrian Bunk
0 siblings, 1 reply; 22+ messages in thread
From: Rafael J. Wysocki @ 2007-11-25 23:28 UTC (permalink / raw)
To: Adrian Bunk
Cc: Bartlomiej Zolnierkiewicz, linux-ide, linux-kernel,
Andrew Morton, Natalie Protasevich
On Sunday, 25 of November 2007, Adrian Bunk wrote:
> On Sun, Nov 25, 2007 at 11:38:59PM +0100, Rafael J. Wysocki wrote:
> > On Sunday, 25 of November 2007, Adrian Bunk wrote:
> > > On Sun, Nov 25, 2007 at 10:28:06PM +0100, Rafael J. Wysocki wrote:
> > > > On Sunday, 25 of November 2007, Adrian Bunk wrote:
> > > >..
> > > > > First of all, Bugzilla is a quite often used bug tracker in the open
> > > > > source world [1], so many users already know it.
> > > > >
> > > > > But more important, "it pretends to require them to spend" isn't true
> > > > > because there's no pretending - we actually often require bug reporters
> > > > > to spend a lot of time on the bug report (e.g. when asking for
> > > > > bisecting).
> > > >
> > > > But not *initially*.
> > > >
> > > > We should not confuse *debugging* with *reporting bugs*. While the former is
> > > > actually more difficult and more time consuming than writing the code in which
> > > > the bug is present, the latter should be as simple as sending an email.
> > >
> > > For hardcore geeks like you and me sending an email might be easier than
> > > using some web interface.
> > >
> > > Normal humans tend to be more accustomed to web interfaces, and
> > > following the instructions on some web page is _much_ easier than
> > > reading three text files for knowing what to write in an email.
> >
> > Hm, this is a good argument for having such a web interface, but IMO it
> > shouldn't be mandatory. IOW, there should be a way to report a bug using plain
> > email, if the reporter prefers that. We can, however, request that the address
> > of our bug tracking system be added to the report's Cc list.
>
> Looking at both other open source projects and the support of commercial
> software a web interface should be enough.
Well, IMHO the Linux kernel is exceptional in many ways ...
> But this is not the problem - the problem is what happens after the
> initial report with the bug report.
Not only that.
First, each bug report has to reach the right lists/people and that's what we
can't assure using the Bugzilla alone right now. To make the Bugzilla
generally useful for that we need to change the way in which the target of the
report is selected and make it send reports to mailing lists rather than to
individual people.
Second, once the bug report have reached the right place, we have two problems
to solve:
(1) we need to make the developers respond and actively work on the bug
(2) we need to make the tracking of the bug possibly unintrusive (ie.
developers should be able to work with the reporter in a way that *they*
prefer)
While it's generally difficult to solve (1), we can at least make (2) happen
(well, in theory).
> > Now, the question is what information this web interface should ask for.
> >
> > IMO, first, it should ask for what the bug is against, ie.:
> > - kernel version (to be obtained from 'git describe' or from /proc/version or
> > from .config, if the kernel doesn't boot)
> > - architecture (x86, ARM, MIPS etc.)
> > - subsystem and subsubsystem (that could be selectable from a menu and might
> > depend on the architecture)
> >
> > It also should ask if the problem is a regression and what was the last known
> > good kernel (I'd prefer that to be the last known major release selectable from
> > a list).
> >
> > Also, the reporter should be required to provide a summary (subject) and
> > a (concise) description of the problem and a list of email addresses to
> > send the report to in addition to the regular handling (there should be a way
> > to verify which addresses are acceptable).
> >
> > Anything else?
> >
> > Next, the report should be sent to a mailing list selected on the basis of the
> > information provided (not necessarily to individual developers, unless there
> > are some addresses provided explicitly by the reporter).
>
> The architecture choice seems to be the only thing from your list that
> isn't already available in the "Enter a new bug report" dialog of the
> kernel Bugzilla.
Yet, the architecture choice affects the way in which the other choices are
made. Also, the "sending to mailing lists" part is obviously missing.
> > IMO, it should be possible to work on the bug using both email and the web
> > interface, whichever is preferred by the participant in question, without the
> > need to stick to any of them (ie. email messages sent in the corresponding
> > email thread should be registered by the bug tracking system and comments
> > entered into it should appear as messages in the email thread with the
> > appropriate To:, From: and Cc: information).
> >
> > There surely are more things that we'd like it to do, but the above seem to be
> > a reasonable minimum.
>
> Except from the From: header in outgoing emails the kernel Bugzilla
> already offers this for years.
No, it doesn't. You can't send the initial report by email so that it's
registered by the Bugzilla, at least I'm not aware of such a possibility.
Also, if you "switch to email", and then want to switch back to the web
interface, the Cc list from the email messages will be lost.
Greetings,
Rafael
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: kernel bugzilla is FPOS (was: Re: "buggy cmd640" message followed by soft lockup)
2007-11-25 23:28 ` Rafael J. Wysocki
@ 2007-11-25 23:34 ` Adrian Bunk
2007-11-26 0:30 ` Rafael J. Wysocki
0 siblings, 1 reply; 22+ messages in thread
From: Adrian Bunk @ 2007-11-25 23:34 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Bartlomiej Zolnierkiewicz, linux-ide, linux-kernel,
Andrew Morton, Natalie Protasevich
On Mon, Nov 26, 2007 at 12:28:17AM +0100, Rafael J. Wysocki wrote:
> On Sunday, 25 of November 2007, Adrian Bunk wrote:
> > On Sun, Nov 25, 2007 at 11:38:59PM +0100, Rafael J. Wysocki wrote:
> > > On Sunday, 25 of November 2007, Adrian Bunk wrote:
> > > > On Sun, Nov 25, 2007 at 10:28:06PM +0100, Rafael J. Wysocki wrote:
> > > > > On Sunday, 25 of November 2007, Adrian Bunk wrote:
> > > > >..
> > > > > > First of all, Bugzilla is a quite often used bug tracker in the open
> > > > > > source world [1], so many users already know it.
> > > > > >
> > > > > > But more important, "it pretends to require them to spend" isn't true
> > > > > > because there's no pretending - we actually often require bug reporters
> > > > > > to spend a lot of time on the bug report (e.g. when asking for
> > > > > > bisecting).
> > > > >
> > > > > But not *initially*.
> > > > >
> > > > > We should not confuse *debugging* with *reporting bugs*. While the former is
> > > > > actually more difficult and more time consuming than writing the code in which
> > > > > the bug is present, the latter should be as simple as sending an email.
> > > >
> > > > For hardcore geeks like you and me sending an email might be easier than
> > > > using some web interface.
> > > >
> > > > Normal humans tend to be more accustomed to web interfaces, and
> > > > following the instructions on some web page is _much_ easier than
> > > > reading three text files for knowing what to write in an email.
> > >
> > > Hm, this is a good argument for having such a web interface, but IMO it
> > > shouldn't be mandatory. IOW, there should be a way to report a bug using plain
> > > email, if the reporter prefers that. We can, however, request that the address
> > > of our bug tracking system be added to the report's Cc list.
> >
> > Looking at both other open source projects and the support of commercial
> > software a web interface should be enough.
>
> Well, IMHO the Linux kernel is exceptional in many ways ...
If your goal is not to solve our problems with bug handling but trying
to maximize the "being different" factor...
> > But this is not the problem - the problem is what happens after the
> > initial report with the bug report.
>
> Not only that.
>
> First, each bug report has to reach the right lists/people and that's what we
> can't assure using the Bugzilla alone right now. To make the Bugzilla
> generally useful for that we need to change the way in which the target of the
> report is selected and make it send reports to mailing lists rather than to
> individual people.
In recent years, the default assignees of changed or new components in
the kernel Bugzilla have been pseudo addresses, and you can subscribe a
mailing list (like any other email address) to get copies of the emails
going to this pseudo address.
> Second, once the bug report have reached the right place, we have two problems
> to solve:
> (1) we need to make the developers respond and actively work on the bug
This is the one problem we have.
> (2) we need to make the tracking of the bug possibly unintrusive (ie.
> developers should be able to work with the reporter in a way that *they*
> prefer)
> While it's generally difficult to solve (1), we can at least make (2) happen
> (well, in theory).
For normal communication (2) already works in the kernel Bugzilla.
> > > Now, the question is what information this web interface should ask for.
> > >
> > > IMO, first, it should ask for what the bug is against, ie.:
> > > - kernel version (to be obtained from 'git describe' or from /proc/version or
> > > from .config, if the kernel doesn't boot)
> > > - architecture (x86, ARM, MIPS etc.)
> > > - subsystem and subsubsystem (that could be selectable from a menu and might
> > > depend on the architecture)
> > >
> > > It also should ask if the problem is a regression and what was the last known
> > > good kernel (I'd prefer that to be the last known major release selectable from
> > > a list).
> > >
> > > Also, the reporter should be required to provide a summary (subject) and
> > > a (concise) description of the problem and a list of email addresses to
> > > send the report to in addition to the regular handling (there should be a way
> > > to verify which addresses are acceptable).
> > >
> > > Anything else?
> > >
> > > Next, the report should be sent to a mailing list selected on the basis of the
> > > information provided (not necessarily to individual developers, unless there
> > > are some addresses provided explicitly by the reporter).
> >
> > The architecture choice seems to be the only thing from your list that
> > isn't already available in the "Enter a new bug report" dialog of the
> > kernel Bugzilla.
>
> Yet, the architecture choice affects the way in which the other choices are
> made.
I can claim having seen every single of the 9457 bugs entered into the
kernel Bugzilla until now at least once, and I do not see a real need
for this.
You can add something like this, but let's not confuse problems with
nice-to-have features.
> Also, the "sending to mailing lists" part is obviously missing.
As said above, it's already available.
> > > IMO, it should be possible to work on the bug using both email and the web
> > > interface, whichever is preferred by the participant in question, without the
> > > need to stick to any of them (ie. email messages sent in the corresponding
> > > email thread should be registered by the bug tracking system and comments
> > > entered into it should appear as messages in the email thread with the
> > > appropriate To:, From: and Cc: information).
> > >
> > > There surely are more things that we'd like it to do, but the above seem to be
> > > a reasonable minimum.
> >
> > Except from the From: header in outgoing emails the kernel Bugzilla
> > already offers this for years.
>
> No, it doesn't. You can't send the initial report by email so that it's
> registered by the Bugzilla, at least I'm not aware of such a possibility.
That's not possible, but as already said it's not required.
And more important, it's unrelated to any problems we have.
And it sounds funny that you first write specifications mandating stuff
like "IMO, first, it should ask for what the bug is against" and then
demand an additional email interface that bypasses everything you
demanded previously.
> Also, if you "switch to email", and then want to switch back to the web
> interface, the Cc list from the email messages will be lost.
The perfect is the enemy of the good.
> 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: kernel bugzilla is FPOS (was: Re: "buggy cmd640" message followed by soft lockup)
2007-11-25 23:34 ` Adrian Bunk
@ 2007-11-26 0:30 ` Rafael J. Wysocki
2007-11-26 21:45 ` Adrian Bunk
0 siblings, 1 reply; 22+ messages in thread
From: Rafael J. Wysocki @ 2007-11-26 0:30 UTC (permalink / raw)
To: Adrian Bunk
Cc: Bartlomiej Zolnierkiewicz, linux-ide, linux-kernel,
Andrew Morton, Natalie Protasevich
On Monday, 26 of November 2007, Adrian Bunk wrote:
> On Mon, Nov 26, 2007 at 12:28:17AM +0100, Rafael J. Wysocki wrote:
> > On Sunday, 25 of November 2007, Adrian Bunk wrote:
> > > On Sun, Nov 25, 2007 at 11:38:59PM +0100, Rafael J. Wysocki wrote:
> > > > On Sunday, 25 of November 2007, Adrian Bunk wrote:
> > > > > On Sun, Nov 25, 2007 at 10:28:06PM +0100, Rafael J. Wysocki wrote:
> > > > > > On Sunday, 25 of November 2007, Adrian Bunk wrote:
> > > > > >..
> > > > > > > First of all, Bugzilla is a quite often used bug tracker in the open
> > > > > > > source world [1], so many users already know it.
> > > > > > >
> > > > > > > But more important, "it pretends to require them to spend" isn't true
> > > > > > > because there's no pretending - we actually often require bug reporters
> > > > > > > to spend a lot of time on the bug report (e.g. when asking for
> > > > > > > bisecting).
> > > > > >
> > > > > > But not *initially*.
> > > > > >
> > > > > > We should not confuse *debugging* with *reporting bugs*. While the former is
> > > > > > actually more difficult and more time consuming than writing the code in which
> > > > > > the bug is present, the latter should be as simple as sending an email.
> > > > >
> > > > > For hardcore geeks like you and me sending an email might be easier than
> > > > > using some web interface.
> > > > >
> > > > > Normal humans tend to be more accustomed to web interfaces, and
> > > > > following the instructions on some web page is _much_ easier than
> > > > > reading three text files for knowing what to write in an email.
> > > >
> > > > Hm, this is a good argument for having such a web interface, but IMO it
> > > > shouldn't be mandatory. IOW, there should be a way to report a bug using plain
> > > > email, if the reporter prefers that. We can, however, request that the address
> > > > of our bug tracking system be added to the report's Cc list.
> > >
> > > Looking at both other open source projects and the support of commercial
> > > software a web interface should be enough.
> >
> > Well, IMHO the Linux kernel is exceptional in many ways ...
>
> If your goal is not to solve our problems with bug handling but trying
> to maximize the "being different" factor...
>
> > > But this is not the problem - the problem is what happens after the
> > > initial report with the bug report.
> >
> > Not only that.
> >
> > First, each bug report has to reach the right lists/people and that's what we
> > can't assure using the Bugzilla alone right now. To make the Bugzilla
> > generally useful for that we need to change the way in which the target of the
> > report is selected and make it send reports to mailing lists rather than to
> > individual people.
>
> In recent years, the default assignees of changed or new components in
> the kernel Bugzilla have been pseudo addresses, and you can subscribe a
> mailing list (like any other email address) to get copies of the emails
> going to this pseudo address.
OK
Why haven't they been subscribed already, then?
I think you would agree that right now the choice of subsystems in the Bugzilla
doesn't reflect the current status of the kernel (some subsystems should be
added, some should be called differently, some should be moved to different
places etc.) and some addresses to which the bug reports are assigned by
default are not the best ones ...
> > Second, once the bug report have reached the right place, we have two problems
> > to solve:
> > (1) we need to make the developers respond and actively work on the bug
>
> This is the one problem we have.
>
> > (2) we need to make the tracking of the bug possibly unintrusive (ie.
> > developers should be able to work with the reporter in a way that *they*
> > prefer)
> > While it's generally difficult to solve (1), we can at least make (2) happen
> > (well, in theory).
>
> For normal communication (2) already works in the kernel Bugzilla.
>
> > > > Now, the question is what information this web interface should ask for.
> > > >
> > > > IMO, first, it should ask for what the bug is against, ie.:
> > > > - kernel version (to be obtained from 'git describe' or from /proc/version or
> > > > from .config, if the kernel doesn't boot)
> > > > - architecture (x86, ARM, MIPS etc.)
> > > > - subsystem and subsubsystem (that could be selectable from a menu and might
> > > > depend on the architecture)
> > > >
> > > > It also should ask if the problem is a regression and what was the last known
> > > > good kernel (I'd prefer that to be the last known major release selectable from
> > > > a list).
> > > >
> > > > Also, the reporter should be required to provide a summary (subject) and
> > > > a (concise) description of the problem and a list of email addresses to
> > > > send the report to in addition to the regular handling (there should be a way
> > > > to verify which addresses are acceptable).
> > > >
> > > > Anything else?
> > > >
> > > > Next, the report should be sent to a mailing list selected on the basis of the
> > > > information provided (not necessarily to individual developers, unless there
> > > > are some addresses provided explicitly by the reporter).
> > >
> > > The architecture choice seems to be the only thing from your list that
> > > isn't already available in the "Enter a new bug report" dialog of the
> > > kernel Bugzilla.
> >
> > Yet, the architecture choice affects the way in which the other choices are
> > made.
>
> I can claim having seen every single of the 9457 bugs entered into the
> kernel Bugzilla until now at least once, and I do not see a real need
> for this.
I do. Some architectures have multiple platforms that are maintained by
different people, etc.
> You can add something like this, but let's not confuse problems with
> nice-to-have features.
>
> > Also, the "sending to mailing lists" part is obviously missing.
>
> As said above, it's already available.
Theoretically.
> > > > IMO, it should be possible to work on the bug using both email and the web
> > > > interface, whichever is preferred by the participant in question, without the
> > > > need to stick to any of them (ie. email messages sent in the corresponding
> > > > email thread should be registered by the bug tracking system and comments
> > > > entered into it should appear as messages in the email thread with the
> > > > appropriate To:, From: and Cc: information).
> > > >
> > > > There surely are more things that we'd like it to do, but the above seem to be
> > > > a reasonable minimum.
> > >
> > > Except from the From: header in outgoing emails the kernel Bugzilla
> > > already offers this for years.
> >
> > No, it doesn't. You can't send the initial report by email so that it's
> > registered by the Bugzilla, at least I'm not aware of such a possibility.
>
> That's not possible, but as already said it's not required.
> And more important, it's unrelated to any problems we have.
>
> And it sounds funny that you first write specifications mandating stuff
> like "IMO, first, it should ask for what the bug is against" and then
> demand an additional email interface that bypasses everything you
> demanded previously.
I just realize that there are people who wouldn't like to use the web interface
and would prefer to use email instead.
Moreover, you won't force people to use the web interface only for reporting
bugs, because frankly for some kinds of problems it's too heavywieght
(compilation problems and purely software, reproducible things like that are
much faster resolved using email; this also applies to easily reproducible bugs
in general). Still, it wouldn't hurt if they were automatically tracked.
> > Also, if you "switch to email", and then want to switch back to the web
> > interface, the Cc list from the email messages will be lost.
>
> The perfect is the enemy of the good.
Sure.
Greetings,
Rafael
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: "buggy cmd640" message followed by soft lockup
[not found] ` <200711250013.51279.bzolnier@gmail.com>
@ 2007-11-26 1:32 ` Frans Pop
0 siblings, 0 replies; 22+ messages in thread
From: Frans Pop @ 2007-11-26 1:32 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-ide, linux-kernel
(Dropped Rafael from CC)
On Sunday 25 November 2007, Bartlomiej Zolnierkiewicz wrote:
> So either something went very very wrong or the oops itself is incorrect.
>
> Please put BUG() before the put_cmd640_reg() above so the next time
> BUG happens we will know which one is it.
I've spent quite a bit of time on this issue over the weekend and have seen
all kinds of "interesting" behavior with various kernels with different
debug patches, but no definite clues (except confirmation that on "good"
boots no cmd64x hardware is detected).
At some point I scrapped the virtual machine I had been using and created a
new one. Since then I've been unable to reproduce the problem. I'm still
quite confused by the issue exactly because it was so consistent when it
_did_ happen and am still not sure if it can be blamed completely on the
quirkiness of Virtualbox.
I'll keep testing new kernels in VirtualBox and will keep alert for the
issue, but for now I think it's best to forget about it.
Bartlomiej: thanks for your feedback and suggestions.
Cheers,
FJP
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: kernel bugzilla is FPOS (was: Re: "buggy cmd640" message followed by soft lockup)
2007-11-26 0:30 ` Rafael J. Wysocki
@ 2007-11-26 21:45 ` Adrian Bunk
2007-11-26 22:57 ` Rafael J. Wysocki
0 siblings, 1 reply; 22+ messages in thread
From: Adrian Bunk @ 2007-11-26 21:45 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Bartlomiej Zolnierkiewicz, linux-ide, linux-kernel,
Andrew Morton, Natalie Protasevich
On Mon, Nov 26, 2007 at 01:30:06AM +0100, Rafael J. Wysocki wrote:
> On Monday, 26 of November 2007, Adrian Bunk wrote:
>...
> > That's not possible, but as already said it's not required.
> > And more important, it's unrelated to any problems we have.
> >
> > And it sounds funny that you first write specifications mandating stuff
> > like "IMO, first, it should ask for what the bug is against" and then
> > demand an additional email interface that bypasses everything you
> > demanded previously.
>
> I just realize that there are people who wouldn't like to use the web interface
> and would prefer to use email instead.
In the cases where these are kernel developers that do (or should)
handle dozens of bugs each week I see a point if they have problems
integrating some medium into their workflow.
But in all software, no matter whether open source or commercial, bug
reporters simply have to use whatever the vendor offers as support
channel.
> Moreover, you won't force people to use the web interface only for reporting
> bugs, because frankly for some kinds of problems it's too heavywieght
That developers who know what they are doing might bypass the bug
tracking is not a problem.
> (compilation problems and purely software, reproducible things like that are
> much faster resolved using email; this also applies to easily reproducible bugs
> in general). Still, it wouldn't hurt if they were automatically tracked.
This sounds like "a bit pregnant"...
Tracking requires things like e.g. categorizing the issue and marking it
as fixed when it got fixed.
> > > Also, if you "switch to email", and then want to switch back to the web
> > > interface, the Cc list from the email messages will be lost.
> >
> > The perfect is the enemy of the good.
>
> Sure.
>
> 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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: kernel bugzilla is FPOS (was: Re: "buggy cmd640" message followed by soft lockup)
2007-11-26 21:45 ` Adrian Bunk
@ 2007-11-26 22:57 ` Rafael J. Wysocki
0 siblings, 0 replies; 22+ messages in thread
From: Rafael J. Wysocki @ 2007-11-26 22:57 UTC (permalink / raw)
To: Adrian Bunk
Cc: Bartlomiej Zolnierkiewicz, linux-ide, linux-kernel,
Andrew Morton, Natalie Protasevich
On Monday, 26 of November 2007, Adrian Bunk wrote:
> On Mon, Nov 26, 2007 at 01:30:06AM +0100, Rafael J. Wysocki wrote:
> > On Monday, 26 of November 2007, Adrian Bunk wrote:
> >...
> > > That's not possible, but as already said it's not required.
> > > And more important, it's unrelated to any problems we have.
> > >
> > > And it sounds funny that you first write specifications mandating stuff
> > > like "IMO, first, it should ask for what the bug is against" and then
> > > demand an additional email interface that bypasses everything you
> > > demanded previously.
> >
> > I just realize that there are people who wouldn't like to use the web interface
> > and would prefer to use email instead.
>
> In the cases where these are kernel developers that do (or should)
> handle dozens of bugs each week I see a point if they have problems
> integrating some medium into their workflow.
>
> But in all software, no matter whether open source or commercial, bug
> reporters simply have to use whatever the vendor offers as support
> channel.
Yes.
That's why we should tell them what the channel is. :-)
> > Moreover, you won't force people to use the web interface only for reporting
> > bugs, because frankly for some kinds of problems it's too heavywieght
>
> That developers who know what they are doing might bypass the bug
> tracking is not a problem.
>
> > (compilation problems and purely software, reproducible things like that are
> > much faster resolved using email; this also applies to easily reproducible bugs
> > in general). Still, it wouldn't hurt if they were automatically tracked.
>
> This sounds like "a bit pregnant"...
>
> Tracking requires things like e.g. categorizing the issue and marking it
> as fixed when it got fixed.
Yes, but that may be done after the fact. It's not a big problem to review an
email thread starting from a bug report and see if it lead to a fix (I do that
on a regular basis). [Note: They tend to be relatively short. ] You can even
check if the fix has been merged.
Still, you need to know which threads to review.
Greetings,
Rafael
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2007-11-26 22:39 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-11-22 19:07 "buggy cmd640" message followed by soft lockup Frans Pop
[not found] ` <200711241904.13132.bzolnier@gmail.com>
2007-11-24 19:07 ` Rafael J. Wysocki
2007-11-25 0:26 ` kernel bugzilla is FPOS (was: Re: "buggy cmd640" message followed by soft lockup) Bartlomiej Zolnierkiewicz
2007-11-25 13:11 ` Rafael J. Wysocki
2007-11-25 13:49 ` Adrian Bunk
2007-11-25 20:07 ` Rafael J. Wysocki
2007-11-25 20:08 ` Dr. David Alan Gilbert
2007-11-25 20:32 ` Adrian Bunk
2007-11-25 21:28 ` Rafael J. Wysocki
2007-11-25 21:36 ` Adrian Bunk
2007-11-25 22:38 ` Rafael J. Wysocki
2007-11-25 22:40 ` Adrian Bunk
2007-11-25 23:28 ` Rafael J. Wysocki
2007-11-25 23:34 ` Adrian Bunk
2007-11-26 0:30 ` Rafael J. Wysocki
2007-11-26 21:45 ` Adrian Bunk
2007-11-26 22:57 ` Rafael J. Wysocki
2007-11-25 22:55 ` Rafael J. Wysocki
2007-11-25 14:08 ` Bartlomiej Zolnierkiewicz
2007-11-25 20:25 ` Rafael J. Wysocki
[not found] ` <200711242038.06677.elendil@planet.nl>
2007-11-24 20:12 ` "buggy cmd640" message followed by soft lockup Rafael J. Wysocki
[not found] ` <200711250013.51279.bzolnier@gmail.com>
2007-11-26 1:32 ` Frans Pop
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).