linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Linux v2.6.27-rc1
@ 2008-07-29  3:23 Linus Torvalds
  2008-07-29  4:01 ` Nick Piggin
                   ` (6 more replies)
  0 siblings, 7 replies; 42+ messages in thread
From: Linus Torvalds @ 2008-07-29  3:23 UTC (permalink / raw)
  To: Linux Kernel Mailing List


It's two weeks (and one day), and the merge window is over.

Finally. I don't know why, but this one really did feel pretty dang busy. 
And the size of the -rc1 patch bears that out - at 12MB, it's about 50% 
bigger than 26-rc1 (but not that much bigger than 24/25-rc1, so it's not 
like it's anything unheard of).

The pure size of the -rc's _is_ making me a bit nervous, though. Sure, it 
means that we are good at merging it all, but I have to say that I 
sometimes wonder if we don't merge too much in one go, and even our 
current (fairly short) release cycle is actually too big.

Anyway, that's a discussion for some other event.

Much of -rc1 was in linux-next, but certainly not everything. We'll see 
how that whole thing ends up evolving - it certainly didn't solve all 
problems, and there was some bickering about things that weren't there 
(and some things that mostly were ;), but maybe it helped.

There's a ton of new stuff in there, but at least personally the 
interesting things are the BKL pushdown and perhaps the introduction of 
the lockless get_user_pages_fast(). The build system also got updated to 
allow moving the architecture include files ("include/asm-xyz") into the 
architecture subdirectories ("arch/xyz/include/asm"), and sparc seems to 
have taken advantage of that already.

But those changes are just small details in the end. As usual, the bulk of 
changes are all to device drivers (roughly half, as usual), with the arch 
directory amounting to about half of the remainder. Dirstat:

   3.2% arch/arm/
   9.2% arch/ppc/
  24.6% arch/
   5.2% drivers/char/drm/
   6.3% drivers/char/
   4.5% drivers/gpu/drm/
   4.5% drivers/gpu/
   4.6% drivers/media/video/
   5.5% drivers/media/
   3.0% drivers/net/wireless/
  10.7% drivers/net/
   6.4% drivers/usb/misc/
   4.7% drivers/usb/serial/
  12.9% drivers/usb/
  51.2% drivers/
   4.4% firmware/
   3.7% fs/
   9.2% include/

where the bulk of that fs/ update is the merge of the UBI filesystem, to 
pick one fairly sizeable chunk outside of arch or drivers (there's omfs 
too, but that's tiny in comparison).

Other stuff? tracing. firmware loading. continued x86 arch merging. And 
moving more code to generic support (unified generic IPI handling, 
coherent dma memory allocation, show_mem etc). bootmem rewrites. Some 
support for further scalability (ie 4k cpu cores).

But mostly lots and lots of driver and arch updates.

Go to kernelnewbies or lwn for more reporting, I'm going to sleep for 
twenty-four hours now ;)

			Linus

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Linux v2.6.27-rc1
  2008-07-29  3:23 Linux v2.6.27-rc1 Linus Torvalds
@ 2008-07-29  4:01 ` Nick Piggin
  2008-07-29  9:49 ` 2.6.27-rc1: zd1211rw association fails Alistair John Strachan
                   ` (5 subsequent siblings)
  6 siblings, 0 replies; 42+ messages in thread
From: Nick Piggin @ 2008-07-29  4:01 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List

On Tuesday 29 July 2008 13:23, Linus Torvalds wrote:

> Other stuff? tracing. firmware loading. continued x86 arch merging. And
> moving more code to generic support (unified generic IPI handling,
> coherent dma memory allocation, show_mem etc). bootmem rewrites. Some
> support for further scalability (ie 4k cpu cores).

And lockless pagecache, woohoo!

^ permalink raw reply	[flat|nested] 42+ messages in thread

* 2.6.27-rc1: zd1211rw association fails
  2008-07-29  3:23 Linux v2.6.27-rc1 Linus Torvalds
  2008-07-29  4:01 ` Nick Piggin
@ 2008-07-29  9:49 ` Alistair John Strachan
  2008-07-29 10:09   ` Johannes Berg
  2008-07-29 13:57 ` Oops in microcode sysfs registration, Alistair John Strachan
                   ` (4 subsequent siblings)
  6 siblings, 1 reply; 42+ messages in thread
From: Alistair John Strachan @ 2008-07-29  9:49 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List, dsd, kune, linux-wireless

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

Hi,

Just tried switching to 2.6.27-rc1 on my desktop, with a supported zd1211rw
device, and my wireless AP does not "authenticate". With 2.6.26 (the only
previous working version tested) I get the following in dmesg:

[   17.481900] firmware: requesting zd1211/zd1211b_ub
[   17.536820] firmware: requesting zd1211/zd1211b_uphr
[   17.601837] zd1211rw 1-2:1.0: firmware version 4725
[   17.602837] zd1211rw 1-2:1.0: zd1211b chip 050d:705c v4810 high 00-17-3f AL2230_RF pa0 g--NS
[   18.613540] wlan0: Initial auth_alg=0
[   18.613540] wlan0: authenticate with AP 00:17:3f:a4:d6:9d
[   18.622538] wlan0: RX authentication from 00:17:3f:a4:d6:9d (alg=0 transaction=2 status=0)
[   18.622538] wlan0: authenticated
[   18.622538] wlan0: associate with AP 00:17:3f:a4:d6:9d
[   18.622538] wlan0: RX AssocResp from 00:17:3f:a4:d6:9d (capab=0x461 status=0 aid=2)
[   18.622538] wlan0: associated
[   18.622538] wlan0: switched to short barker preamble (BSSID=00:17:3f:a4:d6:9d)

Which is correct. One perhaps interesting detail is that the AP is unencrypted,
here is what iwlist wlan0 scanning sees:

wlan0     Scan completed :
          Cell 01 - Address: 00:17:3F:A4:D6:9D
                    ESSID:"strachan"
                    Mode:Master
                    Channel:6
                    Frequency:2.437 GHz (Channel 6)
                    Quality=100/100  Signal level=44/100
                    Encryption key:off
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 22 Mb/s
                              6 Mb/s; 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s
                              36 Mb/s; 48 Mb/s; 54 Mb/s
                    Extra:tsf=00000036b0f6e1b6

However, on 2.6.27-rc1 I see the following instead:

[   12.120189] firmware: requesting zd1211/zd1211b_ub
[   12.166388] firmware: requesting zd1211/zd1211b_uphr
[   12.218877] zd1211rw 4-2:1.0: firmware version 4725
[   12.258877] zd1211rw 4-2:1.0: zd1211b chip 050d:705c v4810 high 00-17-3f AL2230_RF pa0 g--NS
[   13.097289] wlan0: authenticate with AP 00:17:3f:a4:d6:9d
[   13.296890] wlan0: authenticate with AP 00:17:3f:a4:d6:9d
[   13.496890] wlan0: authenticate with AP 00:17:3f:a4:d6:9d
[   13.696886] wlan0: authentication with AP 00:17:3f:a4:d6:9d timed out

And Debian's networking script fails to obtain an IP address. I notice the line:

[   18.613540] wlan0: Initial auth_alg=0

Is missing from the 2.6.27-rc1 dmesg, however my config should not have been
altered (I simply make oldconfig'ed it). Find attached anyway.

I'll start a bisection if nobody has any immediate ideas.

-- 
Cheers,
Alistair.

[-- Attachment #2: .config --]
[-- Type: text/plain, Size: 47973 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.27-rc1
# Tue Jul 29 08:01:02 2008
#
CONFIG_64BIT=y
# CONFIG_X86_32 is not set
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
# CONFIG_GENERIC_LOCKBREAK is not set
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_FAST_CMPXCHG_LOCAL=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
# CONFIG_GENERIC_GPIO is not set
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
# CONFIG_RWSEM_XCHGADD_ALGORITHM is not set
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_HAVE_CPUMASK_OF_CPU_MAP=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ZONE_DMA32=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_AOUT=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_X86_SMP=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
# CONFIG_KTIME_SCALAR is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION="-damocles"
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=16
# CONFIG_CGROUPS is not set
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
# CONFIG_GROUP_SCHED is not set
# CONFIG_SYSFS_DEPRECATED_V2 is not set
# CONFIG_RELAY is not set
# CONFIG_NAMESPACES is not set
# CONFIG_BLK_DEV_INITRD is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_SYSCTL_SYSCALL_CHECK=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
# CONFIG_COMPAT_BRK is not set
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_PROFILING=y
# CONFIG_MARKERS is not set
# CONFIG_OPROFILE is not set
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
# CONFIG_HAVE_ARCH_TRACEHOOK is not set
# CONFIG_HAVE_DMA_ATTRS is not set
CONFIG_USE_GENERIC_SMP_HELPERS=y
# CONFIG_HAVE_CLK is not set
CONFIG_PROC_PAGE_MONITOR=y
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
# CONFIG_BLK_DEV_IO_TRACE is not set
CONFIG_BLK_DEV_BSG=y
# CONFIG_BLK_DEV_INTEGRITY is not set
CONFIG_BLOCK_COMPAT=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
# CONFIG_IOSCHED_DEADLINE is not set
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_PREEMPT_NOTIFIERS=y
# CONFIG_CLASSIC_RCU is not set

#
# 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_MPPARSE is not set
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_VSMP is not set
# CONFIG_PARAVIRT_GUEST is not set
# CONFIG_MEMTEST is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_MPSC is not set
CONFIG_MCORE2=y
# CONFIG_GENERIC_CPU is not set
CONFIG_X86_CPU=y
CONFIG_X86_L1_CACHE_BYTES=64
CONFIG_X86_INTERNODE_CACHE_BYTES=64
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_P6_NOP=y
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=64
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_DMI=y
CONFIG_GART_IOMMU=y
# CONFIG_CALGARY_IOMMU is not set
# CONFIG_AMD_IOMMU is not set
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
# CONFIG_MAXSMP is not set
CONFIG_NR_CPUS=2
# CONFIG_SCHED_SMT is not set
CONFIG_SCHED_MC=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_RCU=y
# CONFIG_RCU_TRACE is not set
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_INTEL=y
# CONFIG_X86_MCE_AMD is not set
# CONFIG_I8K is not set
CONFIG_MICROCODE=y
CONFIG_MICROCODE_OLD_INTERFACE=y
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
# CONFIG_NUMA is not set
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_SELECT_MEMORY_MODEL=y
# CONFIG_FLATMEM_MANUAL is not set
# CONFIG_DISCONTIGMEM_MANUAL is not set
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_HAVE_GET_USER_PAGES_FAST=y
CONFIG_HAVE_MEMORY_PRESENT=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
CONFIG_SPARSEMEM_VMEMMAP=y
# CONFIG_MEMORY_HOTPLUG is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_RESOURCES_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_MMU_NOTIFIER=y
CONFIG_MTRR=y
# CONFIG_MTRR_SANITIZER is not set
CONFIG_X86_PAT=y
# CONFIG_EFI is not set
# CONFIG_SECCOMP is not set
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_SCHED_HRTICK=y
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
CONFIG_PHYSICAL_START=0x200000
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=0x200000
CONFIG_HOTPLUG_CPU=y
# CONFIG_COMPAT_VDSO is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y

#
# Power management options
#
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
CONFIG_PM_SLEEP_SMP=y
CONFIG_PM_SLEEP=y
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
# CONFIG_HIBERNATION is not set
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
# CONFIG_ACPI_PROCFS is not set
# CONFIG_ACPI_PROCFS_POWER is not set
CONFIG_ACPI_SYSFS_POWER=y
CONFIG_ACPI_PROC_EVENT=y
CONFIG_ACPI_AC=y
# CONFIG_ACPI_BATTERY is not set
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_DOCK=y
# CONFIG_ACPI_BAY is not set
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_WMI is not set
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_CUSTOM_DSDT_FILE="/boot/dsdt.hex"
CONFIG_ACPI_CUSTOM_DSDT=y
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_EC=y
# CONFIG_ACPI_PCI_SLOT is not set
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=y
# CONFIG_ACPI_SBS is not set

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=m
# CONFIG_CPU_FREQ_DEBUG is not set
# CONFIG_CPU_FREQ_STAT is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE=y
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_GOV_USERSPACE is not set
# CONFIG_CPU_FREQ_GOV_ONDEMAND is not set
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y

#
# CPUFreq processor drivers
#
CONFIG_X86_ACPI_CPUFREQ=m
# CONFIG_X86_POWERNOW_K8 is not set
# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
# CONFIG_X86_P4_CLOCKMOD is not set

#
# shared options
#
# CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set
# CONFIG_X86_SPEEDSTEP_LIB is not set
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_DOMAINS=y
CONFIG_DMAR=y
CONFIG_DMAR_GFX_WA=y
CONFIG_DMAR_FLOPPY_WA=y
CONFIG_PCIEPORTBUS=y
CONFIG_PCIEAER=y
CONFIG_PCIEASPM=y
# CONFIG_PCIEASPM_DEBUG is not set
CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_PCI_MSI=y
CONFIG_PCI_LEGACY=y
# CONFIG_PCI_DEBUG is not set
# CONFIG_HT_IRQ is not set
CONFIG_ISA_DMA_API=y
CONFIG_K8_NB=y
# CONFIG_PCCARD is not set
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_COMPAT_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
CONFIG_IA32_EMULATION=y
# CONFIG_IA32_AOUT is not set
CONFIG_COMPAT=y
CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
CONFIG_SYSVIPC_COMPAT=y

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
# CONFIG_INET_LRO is not set
# CONFIG_INET_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
# CONFIG_NETWORK_SECMARK is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
# CONFIG_NETFILTER_ADVANCED is not set

#
# Core Netfilter Configuration
#
# CONFIG_NETFILTER_NETLINK_LOG is not set
CONFIG_NF_CONNTRACK=m
# CONFIG_NF_CONNTRACK_FTP is not set
# CONFIG_NF_CONNTRACK_IRC is not set
# CONFIG_NF_CONNTRACK_SIP is not set
# CONFIG_NF_CT_NETLINK is not set
CONFIG_NETFILTER_XTABLES=m
# CONFIG_NETFILTER_XT_TARGET_MARK is not set
# CONFIG_NETFILTER_XT_TARGET_NFLOG is not set
# CONFIG_NETFILTER_XT_TARGET_TCPMSS is not set
# CONFIG_NETFILTER_XT_MATCH_CONNTRACK is not set
# CONFIG_NETFILTER_XT_MATCH_MARK is not set
# CONFIG_NETFILTER_XT_MATCH_STATE is not set

#
# IP: Netfilter Configuration
#
CONFIG_NF_CONNTRACK_IPV4=m
# CONFIG_NF_CONNTRACK_PROC_COMPAT is not set
CONFIG_IP_NF_IPTABLES=m
# CONFIG_IP_NF_FILTER is not set
# CONFIG_IP_NF_TARGET_LOG is not set
# CONFIG_IP_NF_TARGET_ULOG is not set
CONFIG_NF_NAT=m
CONFIG_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
# CONFIG_NF_NAT_FTP is not set
# CONFIG_NF_NAT_IRC is not set
# CONFIG_NF_NAT_TFTP is not set
# CONFIG_NF_NAT_AMANDA is not set
# CONFIG_NF_NAT_PPTP is not set
# CONFIG_NF_NAT_H323 is not set
# CONFIG_NF_NAT_SIP is not set
# CONFIG_IP_NF_MANGLE is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
CONFIG_STP=m
CONFIG_BRIDGE=m
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
CONFIG_LLC=m
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_SCHED is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
CONFIG_BT=m
CONFIG_BT_L2CAP=m
CONFIG_BT_SCO=m
CONFIG_BT_RFCOMM=m
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_BNEP=m
CONFIG_BT_BNEP_MC_FILTER=y
CONFIG_BT_BNEP_PROTO_FILTER=y
CONFIG_BT_HIDP=m

#
# Bluetooth device drivers
#
CONFIG_BT_HCIUSB=m
CONFIG_BT_HCIUSB_SCO=y
# CONFIG_BT_HCIUART is not set
# CONFIG_BT_HCIBCM203X is not set
# CONFIG_BT_HCIBPA10X is not set
# CONFIG_BT_HCIBFUSB is not set
# CONFIG_BT_HCIVHCI is not set
# CONFIG_AF_RXRPC is not set

#
# Wireless
#
CONFIG_CFG80211=m
CONFIG_NL80211=y
CONFIG_WIRELESS_EXT=y
CONFIG_WIRELESS_EXT_SYSFS=y
CONFIG_MAC80211=m

#
# Rate control algorithm selection
#
CONFIG_MAC80211_RC_PID=y
CONFIG_MAC80211_RC_DEFAULT_PID=y
CONFIG_MAC80211_RC_DEFAULT="pid"
# CONFIG_MAC80211_MESH is not set
# CONFIG_MAC80211_LEDS is not set
# CONFIG_MAC80211_DEBUGFS is not set
# CONFIG_MAC80211_DEBUG_MENU is not set
# CONFIG_IEEE80211 is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
# CONFIG_STANDALONE is not set
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
# CONFIG_MTD is not set
# CONFIG_PARPORT is not set
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set

#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
# CONFIG_BLK_DEV_RAM is not set
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_BLK_DEV_HD is not set
# CONFIG_MISC_DEVICES is not set
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set

#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
# CONFIG_SCSI_PROC_FS is not set

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=m
# CONFIG_CHR_DEV_SCH is not set

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set
CONFIG_SCSI_WAIT_SCAN=m

#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
# CONFIG_SCSI_LOWLEVEL is not set
# CONFIG_SCSI_DH is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_ACPI=y
CONFIG_SATA_PMP=y
CONFIG_SATA_AHCI=y
# CONFIG_SATA_SIL24 is not set
CONFIG_ATA_SFF=y
# CONFIG_SATA_SVW is not set
# CONFIG_ATA_PIIX is not set
# 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_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_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
# CONFIG_ATA_GENERIC is not set
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_IT8213 is not set
CONFIG_PATA_JMICRON=y
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_MARVELL is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NINJA32 is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_NS87415 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RZ1000 is not set
# CONFIG_PATA_SC1200 is not set
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set
# CONFIG_PATA_PLATFORM is not set
# CONFIG_PATA_SCH is not set
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
# CONFIG_MD_LINEAR is not set
CONFIG_MD_RAID0=y
CONFIG_MD_RAID1=y
# CONFIG_MD_RAID10 is not set
CONFIG_MD_RAID456=y
CONFIG_MD_RAID5_RESHAPE=y
# CONFIG_MD_MULTIPATH is not set
# CONFIG_MD_FAULTY is not set
# CONFIG_BLK_DEV_DM is not set
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#

#
# Enable only one of the two stacks, unless you know what you are doing
#
CONFIG_FIREWIRE=m
CONFIG_FIREWIRE_OHCI=m
CONFIG_FIREWIRE_OHCI_DEBUG=y
CONFIG_FIREWIRE_SBP2=m
# CONFIG_IEEE1394 is not set
# CONFIG_I2O is not set
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=y
# CONFIG_VETH is not set
# CONFIG_NET_SB1000 is not set
# CONFIG_ARCNET is not set
# CONFIG_NET_ETHERNET is not set
CONFIG_NETDEV_1000=y
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_E1000E is not set
# CONFIG_IP1000 is not set
# CONFIG_IGB is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
CONFIG_R8169=m
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set
# CONFIG_QLA3XXX is not set
# CONFIG_ATL1 is not set
# CONFIG_ATL1E 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=y
# CONFIG_IPW2100 is not set
# CONFIG_IPW2200 is not set
# CONFIG_LIBERTAS is not set
# CONFIG_AIRO is not set
# CONFIG_HERMES is not set
# CONFIG_ATMEL is not set
# CONFIG_PRISM54 is not set
# CONFIG_USB_ZD1201 is not set
# CONFIG_USB_NET_RNDIS_WLAN is not set
# CONFIG_RTL8180 is not set
# CONFIG_RTL8187 is not set
# CONFIG_ADM8211 is not set
# CONFIG_MAC80211_HWSIM is not set
# CONFIG_P54_COMMON is not set
# CONFIG_ATH5K is not set
# CONFIG_IWLCORE is not set
# CONFIG_IWLWIFI_LEDS is not set
# CONFIG_IWL4965 is not set
# CONFIG_IWL3945 is not set
# CONFIG_HOSTAP is not set
# CONFIG_B43 is not set
# CONFIG_B43LEGACY is not set
CONFIG_ZD1211RW=m
# CONFIG_ZD1211RW_DEBUG is not set
# CONFIG_RT2X00 is not set

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
CONFIG_NETCONSOLE=m
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 is not set
# CONFIG_INPUT_POLLDEV is not set

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1280
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=1024
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_PS2_ALPS is not set
# CONFIG_MOUSE_PS2_LOGIPS2PP is not set
# CONFIG_MOUSE_PS2_SYNAPTICS is not set
# CONFIG_MOUSE_PS2_LIFEBOOK is not set
# CONFIG_MOUSE_PS2_TRACKPOINT is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set

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

#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set
CONFIG_FIX_EARLYCON_MEM=y

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
# CONFIG_IPMI_HANDLER is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
CONFIG_RTC=y
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_HPET=y
CONFIG_HPET_RTC_IRQ=y
CONFIG_HPET_MMAP=y
# CONFIG_HANGCHECK_TIMER is not set
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set
CONFIG_DEVPORT=y
CONFIG_I2C=m
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_CHARDEV=m

#
# I2C Hardware Bus support
#

#
# PC SMBus host controller drivers
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
CONFIG_I2C_I801=m
# CONFIG_I2C_ISCH is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_SIMTEC is not set

#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set
# CONFIG_I2C_TINY_USB is not set

#
# Graphics adapter I2C/DDC channel drivers
#
# CONFIG_I2C_VOODOO3 is not set

#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_STUB is not set

#
# Miscellaneous I2C Chip support
#
# CONFIG_DS1682 is not set
# CONFIG_AT24 is not set
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_PCF8575 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_MAX6875 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set
# CONFIG_SPI is not set
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
# CONFIG_GPIOLIB is not set
# CONFIG_W1 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_BATTERY_DS2760 is not set
CONFIG_HWMON=m
CONFIG_HWMON_VID=m
# CONFIG_SENSORS_ABITUGURU is not set
CONFIG_SENSORS_ABITUGURU3=m
# CONFIG_SENSORS_AD7418 is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ADT7470 is not set
# CONFIG_SENSORS_ADT7473 is not set
# CONFIG_SENSORS_K8TEMP is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_I5K_AMB is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_F71882FG is not set
# CONFIG_SENSORS_F75375S is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_FSCPOS is not set
# CONFIG_SENSORS_FSCHMD is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
CONFIG_SENSORS_CORETEMP=m
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_LM93 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_MAX6650 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_DME1737 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_ADS7828 is not set
# CONFIG_SENSORS_THMC50 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_VT8231 is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83L786NG is not set
# CONFIG_SENSORS_W83627HF is not set
CONFIG_SENSORS_W83627EHF=m
# CONFIG_SENSORS_HDAPS is not set
# CONFIG_SENSORS_APPLESMC is not set
# CONFIG_HWMON_DEBUG_CHIP is not set
CONFIG_THERMAL=y
# CONFIG_WATCHDOG is not set

#
# Sonics Silicon Backplane
#
CONFIG_SSB_POSSIBLE=y
# CONFIG_SSB is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_HTC_PASIC3 is not set

#
# Multimedia devices
#

#
# Multimedia core support
#
CONFIG_VIDEO_DEV=y
CONFIG_VIDEO_V4L2_COMMON=m
CONFIG_VIDEO_ALLOW_V4L1=y
CONFIG_VIDEO_V4L1_COMPAT=y
# CONFIG_DVB_CORE is not set
CONFIG_VIDEO_MEDIA=y

#
# Multimedia drivers
#
CONFIG_MEDIA_ATTACH=y
CONFIG_MEDIA_TUNER=m
CONFIG_MEDIA_TUNER_CUSTOMIZE=y
# CONFIG_MEDIA_TUNER_SIMPLE is not set
# CONFIG_MEDIA_TUNER_TDA8290 is not set
# CONFIG_MEDIA_TUNER_TDA827X is not set
# CONFIG_MEDIA_TUNER_TDA18271 is not set
# CONFIG_MEDIA_TUNER_TDA9887 is not set
# CONFIG_MEDIA_TUNER_TEA5761 is not set
# CONFIG_MEDIA_TUNER_TEA5767 is not set
# CONFIG_MEDIA_TUNER_MT20XX is not set
# CONFIG_MEDIA_TUNER_MT2060 is not set
# CONFIG_MEDIA_TUNER_MT2266 is not set
# CONFIG_MEDIA_TUNER_MT2131 is not set
# CONFIG_MEDIA_TUNER_QT1010 is not set
# CONFIG_MEDIA_TUNER_XC2028 is not set
# CONFIG_MEDIA_TUNER_XC5000 is not set
# CONFIG_MEDIA_TUNER_MXL5005S is not set
# CONFIG_MEDIA_TUNER_MXL5007T is not set
CONFIG_VIDEO_V4L2=m
CONFIG_VIDEO_V4L1=m
# CONFIG_VIDEO_CAPTURE_DRIVERS is not set
# CONFIG_RADIO_ADAPTERS is not set
# CONFIG_DAB is not set

#
# Graphics support
#
CONFIG_AGP=y
CONFIG_AGP_AMD64=y
# CONFIG_AGP_INTEL is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_DRM is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
# CONFIG_FB_DDC is not set
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
# CONFIG_FB_SYS_FILLRECT is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_FOREIGN_ENDIAN is not set
# CONFIG_FB_SYS_FOPS is not set
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
# CONFIG_FB_TILEBLITTING is not set

#
# Frame buffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
CONFIG_FB_VESA=y
# CONFIG_FB_EFI is not set
# CONFIG_FB_N411 is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_LE80578 is not set
# CONFIG_FB_INTEL is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_CARMINE is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VGACON_SOFT_SCROLLBACK is not set
CONFIG_VIDEO_SELECT=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_LOGO_LINUX_CLUT224=y
CONFIG_SOUND=m
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_HWDEP=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
# CONFIG_SND_SEQ_DUMMY is not set
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
# CONFIG_SND_PCM_OSS_PLUGINS is not set
CONFIG_SND_SEQUENCER_OSS=y
# CONFIG_SND_RTCTIMER is not set
# CONFIG_SND_DYNAMIC_MINORS is not set
# CONFIG_SND_SUPPORT_OLD_API is not set
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
CONFIG_SND_VMASTER=y
CONFIG_SND_MPU401_UART=m
CONFIG_SND_AC97_CODEC=m
CONFIG_SND_DRIVERS=y
# CONFIG_SND_PCSP is not set
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_VIRMIDI is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
CONFIG_SND_MPU401=m
# CONFIG_SND_AC97_POWER_SAVE is not set
CONFIG_SND_PCI=y
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP 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_AW2 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_OXYGEN is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS5530 is not set
# CONFIG_SND_DARLA20 is not set
# CONFIG_SND_GINA20 is not set
# CONFIG_SND_LAYLA20 is not set
# CONFIG_SND_DARLA24 is not set
# CONFIG_SND_GINA24 is not set
# CONFIG_SND_LAYLA24 is not set
# CONFIG_SND_MONA is not set
# CONFIG_SND_MIA is not set
# CONFIG_SND_ECHO3G is not set
# CONFIG_SND_INDIGO is not set
# CONFIG_SND_INDIGOIO is not set
# CONFIG_SND_INDIGODJ is not set
CONFIG_SND_EMU10K1=m
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_FM801 is not set
CONFIG_SND_HDA_INTEL=m
# CONFIG_SND_HDA_HWDEP is not set
CONFIG_SND_HDA_CODEC_REALTEK=y
# CONFIG_SND_HDA_CODEC_ANALOG is not set
# CONFIG_SND_HDA_CODEC_SIGMATEL is not set
# CONFIG_SND_HDA_CODEC_VIA is not set
# CONFIG_SND_HDA_CODEC_ATIHDMI is not set
# CONFIG_SND_HDA_CODEC_CONEXANT is not set
# CONFIG_SND_HDA_CODEC_CMEDIA is not set
# CONFIG_SND_HDA_CODEC_SI3054 is not set
# CONFIG_SND_HDA_GENERIC is not set
# CONFIG_SND_HDA_POWER_SAVE is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_HIFIER is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
# CONFIG_SND_INTEL8X0 is not set
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_PCXHR is not set
# CONFIG_SND_RIPTIDE is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VIRTUOSO is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_USB is not set
# CONFIG_SND_SOC is not set
# CONFIG_SOUND_PRIME is not set
CONFIG_AC97_BUS=m
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
# CONFIG_HID_DEBUG is not set
# CONFIG_HIDRAW is not set

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

#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=m
# CONFIG_USB_DEBUG is not set
# CONFIG_USB_ANNOUNCE_NEW_DEVICES is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_DEVICE_CLASS is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_SUSPEND is not set
# CONFIG_USB_OTG is not set
# CONFIG_USB_OTG_WHITELIST is not set
# CONFIG_USB_OTG_BLACKLIST_HUB is not set

#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
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
# CONFIG_USB_WDM is not set

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#

#
# may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_ONETOUCH is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_STORAGE_CYPRESS_ATACB is not set
# CONFIG_USB_LIBUSUAL is not set

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

#
# USB port drivers
#
CONFIG_USB_SERIAL=m
# CONFIG_USB_EZUSB is not set
CONFIG_USB_SERIAL_GENERIC=y
# CONFIG_USB_SERIAL_AIRCABLE is not set
# CONFIG_USB_SERIAL_ARK3116 is not set
# CONFIG_USB_SERIAL_BELKIN is not set
# CONFIG_USB_SERIAL_CH341 is not set
# CONFIG_USB_SERIAL_WHITEHEAT is not set
# CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set
# CONFIG_USB_SERIAL_CP2101 is not set
# CONFIG_USB_SERIAL_CYPRESS_M8 is not set
# CONFIG_USB_SERIAL_EMPEG is not set
# CONFIG_USB_SERIAL_FTDI_SIO is not set
# CONFIG_USB_SERIAL_FUNSOFT is not set
# CONFIG_USB_SERIAL_VISOR is not set
# CONFIG_USB_SERIAL_IPAQ is not set
# CONFIG_USB_SERIAL_IR is not set
# CONFIG_USB_SERIAL_EDGEPORT is not set
# CONFIG_USB_SERIAL_EDGEPORT_TI is not set
# CONFIG_USB_SERIAL_GARMIN is not set
# CONFIG_USB_SERIAL_IPW is not set
# CONFIG_USB_SERIAL_IUU is not set
# CONFIG_USB_SERIAL_KEYSPAN_PDA is not set
# CONFIG_USB_SERIAL_KEYSPAN is not set
# CONFIG_USB_SERIAL_KLSI is not set
# CONFIG_USB_SERIAL_KOBIL_SCT is not set
# CONFIG_USB_SERIAL_MCT_U232 is not set
# CONFIG_USB_SERIAL_MOS7720 is not set
# CONFIG_USB_SERIAL_MOS7840 is not set
# CONFIG_USB_SERIAL_MOTOROLA is not set
# CONFIG_USB_SERIAL_NAVMAN is not set
# CONFIG_USB_SERIAL_PL2303 is not set
# CONFIG_USB_SERIAL_OTI6858 is not set
# CONFIG_USB_SERIAL_SPCP8X5 is not set
# CONFIG_USB_SERIAL_HP4X is not set
# CONFIG_USB_SERIAL_SAFE is not set
# CONFIG_USB_SERIAL_SIERRAWIRELESS is not set
# CONFIG_USB_SERIAL_TI is not set
# CONFIG_USB_SERIAL_CYBERJACK is not set
# CONFIG_USB_SERIAL_XIRCOM is not set
# CONFIG_USB_SERIAL_OPTION is not set
# CONFIG_USB_SERIAL_OMNINET is not set
# CONFIG_USB_SERIAL_DEBUG is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_BERRY_CHARGE is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGET is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_GADGET is not set
# CONFIG_MMC is not set
# CONFIG_MEMSTICK is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
# CONFIG_EDAC is not set
# CONFIG_RTC_CLASS is not set
# CONFIG_DMADEVICES is not set
# CONFIG_UIO is not set

#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_FIRMWARE_MEMMAP=y
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
CONFIG_DMIID=y
# CONFIG_ISCSI_IBFT_FIND is not set

#
# File systems
#
CONFIG_EXT2_FS=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=y
# CONFIG_XFS_QUOTA is not set
# CONFIG_XFS_POSIX_ACL is not set
# CONFIG_XFS_RT is not set
# CONFIG_XFS_DEBUG is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
CONFIG_DNOTIFY=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
CONFIG_FUSE_FS=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=850
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-15"
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 is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_CONFIGFS_FS=m

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
CONFIG_HFSPLUS_FS=y
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
# CONFIG_NFS_V4 is not set
# 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_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-15"
CONFIG_NLS_CODEPAGE_437=m
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=m
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=m
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=y
# CONFIG_DLM is not set

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_PRINTK_TIME=y
# CONFIG_ENABLE_WARN_DEPRECATED is not set
# CONFIG_ENABLE_MUST_CHECK is not set
CONFIG_FRAME_WARN=2048
CONFIG_MAGIC_SYSRQ=y
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
CONFIG_SCHED_DEBUG=y
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
# CONFIG_DEBUG_PREEMPT 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_STACKTRACE=y
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_BUGVERBOSE is not set
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_WRITECOUNT is not set
# CONFIG_DEBUG_MEMORY_INIT is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_DEBUG_SG is not set
CONFIG_FRAME_POINTER=y
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_FAULT_INJECTION is not set
CONFIG_LATENCYTOP=y
CONFIG_HAVE_FTRACE=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_TRACING=y
# CONFIG_FTRACE is not set
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_PREEMPT_TRACER is not set
# CONFIG_SYSPROF_TRACER is not set
# CONFIG_SCHED_TRACER is not set
# CONFIG_CONTEXT_SWITCH_TRACER is not set
# CONFIG_FTRACE_STARTUP_TEST is not set
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
# CONFIG_FIREWIRE_OHCI_REMOTE_DMA is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
CONFIG_STRICT_DEVMEM=y
# CONFIG_X86_VERBOSE_BOOTUP is not set
# CONFIG_EARLY_PRINTK is not set
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_DEBUG_PER_CPU_MAPS is not set
# CONFIG_X86_PTDUMP is not set
# CONFIG_DEBUG_RODATA is not set
# CONFIG_DIRECT_GBPAGES is not set
# CONFIG_DEBUG_NX_TEST is not set
CONFIG_IOMMU_DEBUG=y
CONFIG_IOMMU_LEAK=y
CONFIG_MMIOTRACE_HOOKS=y
CONFIG_MMIOTRACE=y
# CONFIG_MMIOTRACE_TEST is not set
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
CONFIG_IO_DELAY_0X80=y
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=0
# CONFIG_DEBUG_BOOT_PARAMS is not set
# CONFIG_CPA_DEBUG is not set
CONFIG_OPTIMIZE_INLINING=y

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITY_FILE_CAPABILITIES is not set
CONFIG_XOR_BLOCKS=y
CONFIG_ASYNC_CORE=y
CONFIG_ASYNC_MEMCPY=y
CONFIG_ASYNC_XOR=y
CONFIG_CRYPTO=m

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=m
CONFIG_CRYPTO_BLKCIPHER=m
CONFIG_CRYPTO_MANAGER=m
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set
# CONFIG_CRYPTO_TEST is not set

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set

#
# Block modes
#
# CONFIG_CRYPTO_CBC is not set
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
CONFIG_CRYPTO_ECB=m
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set

#
# Hash modes
#
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set

#
# Digest
#
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=m
# CONFIG_CRYPTO_AES_X86_64 is not set
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_ARC4=m
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SALSA20_X86_64 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_X86_64 is not set

#
# Compression
#
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_LZO is not set
CONFIG_CRYPTO_HW=y
# CONFIG_CRYPTO_DEV_HIFN_795X is not set
CONFIG_HAVE_KVM=y
CONFIG_VIRTUALIZATION=y
CONFIG_KVM=m
CONFIG_KVM_INTEL=m
# CONFIG_KVM_AMD is not set
# CONFIG_VIRTIO_PCI is not set
# CONFIG_VIRTIO_BALLOON is not set

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
CONFIG_CRC_T10DIF=y
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=m
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 2.6.27-rc1: zd1211rw association fails
  2008-07-29  9:49 ` 2.6.27-rc1: zd1211rw association fails Alistair John Strachan
@ 2008-07-29 10:09   ` Johannes Berg
  2008-07-29 11:25     ` Alistair John Strachan
  2008-07-29 12:04     ` Theodore Tso
  0 siblings, 2 replies; 42+ messages in thread
From: Johannes Berg @ 2008-07-29 10:09 UTC (permalink / raw)
  To: Alistair John Strachan
  Cc: Linus Torvalds, Linux Kernel Mailing List, dsd, kune, linux-wireless

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


> However, on 2.6.27-rc1 I see the following instead:
> 
> [   12.120189] firmware: requesting zd1211/zd1211b_ub
> [   12.166388] firmware: requesting zd1211/zd1211b_uphr
> [   12.218877] zd1211rw 4-2:1.0: firmware version 4725
> [   12.258877] zd1211rw 4-2:1.0: zd1211b chip 050d:705c v4810 high 00-17-3f AL2230_RF pa0 g--NS
> [   13.097289] wlan0: authenticate with AP 00:17:3f:a4:d6:9d
> [   13.296890] wlan0: authenticate with AP 00:17:3f:a4:d6:9d
> [   13.496890] wlan0: authenticate with AP 00:17:3f:a4:d6:9d
> [   13.696886] wlan0: authentication with AP 00:17:3f:a4:d6:9d timed out
> 
> And Debian's networking script fails to obtain an IP address. I notice the line:
> 
> [   18.613540] wlan0: Initial auth_alg=0
> 
> Is missing from the 2.6.27-rc1 dmesg, however my config should not have been
> altered (I simply make oldconfig'ed it). Find attached anyway.
> 
> I'll start a bisection if nobody has any immediate ideas.

This is about the 100 millionth time this is reported. Please try the
patch I just posted.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 2.6.27-rc1: zd1211rw association fails
  2008-07-29 10:09   ` Johannes Berg
@ 2008-07-29 11:25     ` Alistair John Strachan
  2008-07-29 11:26       ` Johannes Berg
  2008-07-29 12:04     ` Theodore Tso
  1 sibling, 1 reply; 42+ messages in thread
From: Alistair John Strachan @ 2008-07-29 11:25 UTC (permalink / raw)
  To: Johannes Berg
  Cc: Linus Torvalds, Linux Kernel Mailing List, dsd, kune, linux-wireless

On Tuesday 29 July 2008 11:09:55 Johannes Berg wrote:
> > However, on 2.6.27-rc1 I see the following instead:
> >
> > [   12.120189] firmware: requesting zd1211/zd1211b_ub
> > [   12.166388] firmware: requesting zd1211/zd1211b_uphr
> > [   12.218877] zd1211rw 4-2:1.0: firmware version 4725
> > [   12.258877] zd1211rw 4-2:1.0: zd1211b chip 050d:705c v4810 high
> > 00-17-3f AL2230_RF pa0 g--NS [   13.097289] wlan0: authenticate with AP
> > 00:17:3f:a4:d6:9d
> > [   13.296890] wlan0: authenticate with AP 00:17:3f:a4:d6:9d
> > [   13.496890] wlan0: authenticate with AP 00:17:3f:a4:d6:9d
> > [   13.696886] wlan0: authentication with AP 00:17:3f:a4:d6:9d timed out
> >
> > And Debian's networking script fails to obtain an IP address. I notice
> > the line:
> >
> > [   18.613540] wlan0: Initial auth_alg=0
> >
> > Is missing from the 2.6.27-rc1 dmesg, however my config should not have
> > been altered (I simply make oldconfig'ed it). Find attached anyway.
> >
> > I'll start a bisection if nobody has any immediate ideas.
>
> This is about the 100 millionth time this is reported. Please try the
> patch I just posted.

If it doesn't strain you too much more, could you actually tell me where this 
is? Your last 5 posts to LKML don't seem to contain such a patch, and I'm not 
subscribed to linux-wireless.

-- 
Cheers,
Alistair.

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 2.6.27-rc1: zd1211rw association fails
  2008-07-29 11:25     ` Alistair John Strachan
@ 2008-07-29 11:26       ` Johannes Berg
  2008-07-29 11:37         ` Hugh Dickins
                           ` (2 more replies)
  0 siblings, 3 replies; 42+ messages in thread
From: Johannes Berg @ 2008-07-29 11:26 UTC (permalink / raw)
  To: Alistair John Strachan
  Cc: Linus Torvalds, Linux Kernel Mailing List, dsd, kune, linux-wireless

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


> If it doesn't strain you too much more, could you actually tell me where this 
> is? Your last 5 posts to LKML don't seem to contain such a patch, and I'm not 
> subscribed to linux-wireless.

Well, the latter has archives.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 2.6.27-rc1: zd1211rw association fails
  2008-07-29 11:26       ` Johannes Berg
@ 2008-07-29 11:37         ` Hugh Dickins
  2008-07-29 11:46         ` Kalle Valo
  2008-07-29 11:55         ` Alistair John Strachan
  2 siblings, 0 replies; 42+ messages in thread
From: Hugh Dickins @ 2008-07-29 11:37 UTC (permalink / raw)
  To: Johannes Berg
  Cc: Alistair John Strachan, Linus Torvalds,
	Linux Kernel Mailing List, dsd, kune, linux-wireless

On Tue, 29 Jul 2008, Johannes Berg wrote:
> 
> > If it doesn't strain you too much more, could you actually tell me where this 
> > is? Your last 5 posts to LKML don't seem to contain such a patch, and I'm not 
> > subscribed to linux-wireless.
> 
> Well, the latter has archives.

Wow, your patches seem to be a lot more helpful than your emails.
I presume it's this one below, which at first sight seems to be
working for me on iwl3945 - thank you for that.

Hugh


This patch fixes mac80211 to not use the skb->cb over the queue step
from virtual interfaces to the master. The patch also, for now,
disables aggregation because that would still require requeuing,
will fix that in a separate patch. There are two other places (software
requeue and powersaving stations) where requeue can happen, but that is
not currently used by any drivers/not possible to use respectively.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
This fixes wireless. At least it works on my WPA network, I haven't
actually tested a broken kernel.

 drivers/net/wireless/ath5k/base.c           |    2 -
 drivers/net/wireless/b43/xmit.c             |    2 -
 drivers/net/wireless/b43legacy/xmit.c       |    2 -
 drivers/net/wireless/iwlwifi/iwl-tx.c       |    2 -
 drivers/net/wireless/iwlwifi/iwl3945-base.c |    2 -
 drivers/net/wireless/rt2x00/rt2x00mac.c     |    2 -
 include/linux/skbuff.h                      |    5 ++
 include/net/mac80211.h                      |    6 ---
 net/core/skbuff.c                           |    3 +
 net/mac80211/main.c                         |    8 ----
 net/mac80211/mlme.c                         |    8 +---
 net/mac80211/tx.c                           |   47 ++++++++++++----------------
 net/mac80211/wme.c                          |    3 +
 13 files changed, 40 insertions(+), 52 deletions(-)

--- everything.orig/include/net/mac80211.h	2008-07-29 09:08:16.000000000 +0200
+++ everything/include/net/mac80211.h	2008-07-29 11:07:41.000000000 +0200
@@ -206,8 +206,6 @@ struct ieee80211_bss_conf {
  * These flags are used with the @flags member of &ieee80211_tx_info.
  *
  * @IEEE80211_TX_CTL_REQ_TX_STATUS: request TX status callback for this frame.
- * @IEEE80211_TX_CTL_DO_NOT_ENCRYPT: send this frame without encryption;
- *	e.g., for EAPOL frame
  * @IEEE80211_TX_CTL_USE_RTS_CTS: use RTS-CTS before sending frame
  * @IEEE80211_TX_CTL_USE_CTS_PROTECT: use CTS protection for the frame (e.g.,
  *	for combined 802.11g / 802.11b networks)
@@ -220,7 +218,6 @@ struct ieee80211_bss_conf {
  * @IEEE80211_TX_CTL_SHORT_PREAMBLE: TBD
  * @IEEE80211_TX_CTL_LONG_RETRY_LIMIT: this frame should be send using the
  *	through set_retry_limit configured long retry value
- * @IEEE80211_TX_CTL_EAPOL_FRAME: internal to mac80211
  * @IEEE80211_TX_CTL_SEND_AFTER_DTIM: send this frame after DTIM beacon
  * @IEEE80211_TX_CTL_AMPDU: this frame should be sent as part of an A-MPDU
  * @IEEE80211_TX_CTL_OFDM_HT: this frame can be sent in HT OFDM rates. number
@@ -253,7 +250,6 @@ struct ieee80211_bss_conf {
  */
 enum mac80211_tx_control_flags {
 	IEEE80211_TX_CTL_REQ_TX_STATUS		= BIT(0),
-	IEEE80211_TX_CTL_DO_NOT_ENCRYPT		= BIT(1),
 	IEEE80211_TX_CTL_USE_RTS_CTS		= BIT(2),
 	IEEE80211_TX_CTL_USE_CTS_PROTECT	= BIT(3),
 	IEEE80211_TX_CTL_NO_ACK			= BIT(4),
@@ -263,7 +259,6 @@ enum mac80211_tx_control_flags {
 	IEEE80211_TX_CTL_FIRST_FRAGMENT		= BIT(8),
 	IEEE80211_TX_CTL_SHORT_PREAMBLE		= BIT(9),
 	IEEE80211_TX_CTL_LONG_RETRY_LIMIT	= BIT(10),
-	IEEE80211_TX_CTL_EAPOL_FRAME		= BIT(11),
 	IEEE80211_TX_CTL_SEND_AFTER_DTIM	= BIT(12),
 	IEEE80211_TX_CTL_AMPDU			= BIT(13),
 	IEEE80211_TX_CTL_OFDM_HT		= BIT(14),
@@ -323,7 +318,6 @@ struct ieee80211_tx_info {
 			struct ieee80211_vif *vif;
 			struct ieee80211_key_conf *hw_key;
 			unsigned long jiffies;
-			int ifindex;
 			u16 aid;
 			s8 rts_cts_rate_idx, alt_retry_rate_idx;
 			u8 retry_limit;
--- everything.orig/net/mac80211/tx.c	2008-07-29 09:08:16.000000000 +0200
+++ everything/net/mac80211/tx.c	2008-07-29 11:09:09.000000000 +0200
@@ -439,14 +439,14 @@ ieee80211_tx_h_select_key(struct ieee802
 	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(tx->skb);
 	u16 fc = tx->fc;
 
-	if (unlikely(info->flags & IEEE80211_TX_CTL_DO_NOT_ENCRYPT))
+	if (unlikely(tx->skb->do_not_encrypt))
 		tx->key = NULL;
 	else if (tx->sta && (key = rcu_dereference(tx->sta->key)))
 		tx->key = key;
 	else if ((key = rcu_dereference(tx->sdata->default_key)))
 		tx->key = key;
 	else if (tx->sdata->drop_unencrypted &&
-		 !(info->flags & IEEE80211_TX_CTL_EAPOL_FRAME) &&
+		 (tx->skb->protocol != cpu_to_be16(ETH_P_PAE)) &&
 		 !(info->flags & IEEE80211_TX_CTL_INJECTED)) {
 		I802_DEBUG_INC(tx->local->tx_handlers_drop_unencrypted);
 		return TX_DROP;
@@ -476,7 +476,7 @@ ieee80211_tx_h_select_key(struct ieee802
 	}
 
 	if (!tx->key || !(tx->key->flags & KEY_FLAG_UPLOADED_TO_HARDWARE))
-		info->flags |= IEEE80211_TX_CTL_DO_NOT_ENCRYPT;
+		tx->skb->do_not_encrypt = 1;
 
 	return TX_CONTINUE;
 }
@@ -732,6 +732,7 @@ ieee80211_tx_h_fragment(struct ieee80211
 		memcpy(skb_put(frag, copylen), pos, copylen);
 		memcpy(frag->cb, first->cb, sizeof(frag->cb));
 		skb_copy_queue_mapping(frag, first);
+		frag->do_not_encrypt = first->do_not_encrypt;
 
 		pos += copylen;
 		left -= copylen;
@@ -852,7 +853,7 @@ __ieee80211_parse_tx_radiotap(struct iee
 
 	sband = tx->local->hw.wiphy->bands[tx->channel->band];
 
-	info->flags |= IEEE80211_TX_CTL_DO_NOT_ENCRYPT;
+	skb->do_not_encrypt = 1;
 	info->flags |= IEEE80211_TX_CTL_INJECTED;
 	tx->flags &= ~IEEE80211_TX_FRAGMENTED;
 
@@ -925,8 +926,7 @@ __ieee80211_parse_tx_radiotap(struct iee
 				skb_trim(skb, skb->len - FCS_LEN);
 			}
 			if (*iterator.this_arg & IEEE80211_RADIOTAP_F_WEP)
-				info->flags &=
-					~IEEE80211_TX_CTL_DO_NOT_ENCRYPT;
+				tx->skb->do_not_encrypt = 0;
 			if (*iterator.this_arg & IEEE80211_RADIOTAP_F_FRAG)
 				tx->flags |= IEEE80211_TX_FRAGMENTED;
 			break;
@@ -1042,10 +1042,9 @@ static int ieee80211_tx_prepare(struct i
 				struct sk_buff *skb,
 				struct net_device *mdev)
 {
-	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
 	struct net_device *dev;
 
-	dev = dev_get_by_index(&init_net, info->control.ifindex);
+	dev = dev_get_by_index(&init_net, skb->iif);
 	if (unlikely(dev && !is_ieee80211_device(dev, mdev))) {
 		dev_put(dev);
 		dev = NULL;
@@ -1306,8 +1305,8 @@ int ieee80211_master_start_xmit(struct s
 	bool may_encrypt;
 	int ret;
 
-	if (info->control.ifindex)
-		odev = dev_get_by_index(&init_net, info->control.ifindex);
+	if (skb->iif)
+		odev = dev_get_by_index(&init_net, skb->iif);
 	if (unlikely(odev && !is_ieee80211_device(odev, dev))) {
 		dev_put(odev);
 		odev = NULL;
@@ -1321,9 +1320,13 @@ int ieee80211_master_start_xmit(struct s
 		return 0;
 	}
 
+	memset(info, 0, sizeof(*info));
+
+	info->flags |= IEEE80211_TX_CTL_REQ_TX_STATUS;
+
 	osdata = IEEE80211_DEV_TO_SUB_IF(odev);
 
-	may_encrypt = !(info->flags & IEEE80211_TX_CTL_DO_NOT_ENCRYPT);
+	may_encrypt = !skb->do_not_encrypt;
 
 	headroom = osdata->local->tx_headroom;
 	if (may_encrypt)
@@ -1348,7 +1351,6 @@ int ieee80211_monitor_start_xmit(struct 
 				 struct net_device *dev)
 {
 	struct ieee80211_local *local = wdev_priv(dev->ieee80211_ptr);
-	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
 	struct ieee80211_radiotap_header *prthdr =
 		(struct ieee80211_radiotap_header *)skb->data;
 	u16 len_rthdr;
@@ -1371,11 +1373,11 @@ int ieee80211_monitor_start_xmit(struct 
 	skb->dev = local->mdev;
 
 	/* needed because we set skb device to master */
-	info->control.ifindex = dev->ifindex;
+	skb->iif = dev->ifindex;
 
-	info->flags |= IEEE80211_TX_CTL_DO_NOT_ENCRYPT;
-	/* Interfaces should always request a status report */
-	info->flags |= IEEE80211_TX_CTL_REQ_TX_STATUS;
+	/* sometimes we do encrypt injected frames, will be fixed
+	 * up in radiotap parser if not wanted */
+	skb->do_not_encrypt = 0;
 
 	/*
 	 * fix up the pointers accounting for the radiotap
@@ -1419,7 +1421,6 @@ int ieee80211_subif_start_xmit(struct sk
 			       struct net_device *dev)
 {
 	struct ieee80211_local *local = wdev_priv(dev->ieee80211_ptr);
-	struct ieee80211_tx_info *info;
 	struct ieee80211_sub_if_data *sdata;
 	int ret = 1, head_need;
 	u16 ethertype, hdrlen,  meshhdrlen = 0;
@@ -1645,14 +1646,7 @@ int ieee80211_subif_start_xmit(struct sk
 	nh_pos += hdrlen;
 	h_pos += hdrlen;
 
-	info = IEEE80211_SKB_CB(skb);
-	memset(info, 0, sizeof(*info));
-	info->control.ifindex = dev->ifindex;
-	if (ethertype == ETH_P_PAE)
-		info->flags |= IEEE80211_TX_CTL_EAPOL_FRAME;
-
-	/* Interfaces should always request a status report */
-	info->flags |= IEEE80211_TX_CTL_REQ_TX_STATUS;
+	skb->iif = dev->ifindex;
 
 	skb->dev = local->mdev;
 	dev->stats.tx_packets++;
@@ -1922,6 +1916,8 @@ struct sk_buff *ieee80211_beacon_get(str
 
 	info = IEEE80211_SKB_CB(skb);
 
+	skb->do_not_encrypt = 1;
+
 	info->band = band;
 	rate_control_get_rate(local->mdev, sband, skb, &rsel);
 
@@ -1940,7 +1936,6 @@ struct sk_buff *ieee80211_beacon_get(str
 	info->tx_rate_idx = rsel.rate_idx;
 
 	info->flags |= IEEE80211_TX_CTL_NO_ACK;
-	info->flags |= IEEE80211_TX_CTL_DO_NOT_ENCRYPT;
 	info->flags |= IEEE80211_TX_CTL_CLEAR_PS_FILT;
 	info->flags |= IEEE80211_TX_CTL_ASSIGN_SEQ;
 	if (sdata->bss_conf.use_short_preamble &&
--- everything.orig/net/mac80211/mlme.c	2008-07-29 09:08:16.000000000 +0200
+++ everything/net/mac80211/mlme.c	2008-07-29 09:15:17.000000000 +0200
@@ -606,7 +606,6 @@ void ieee80211_sta_tx(struct net_device 
 		      int encrypt)
 {
 	struct ieee80211_sub_if_data *sdata;
-	struct ieee80211_tx_info *info;
 
 	sdata = IEEE80211_DEV_TO_SUB_IF(dev);
 	skb->dev = sdata->local->mdev;
@@ -614,11 +613,8 @@ void ieee80211_sta_tx(struct net_device 
 	skb_set_network_header(skb, 0);
 	skb_set_transport_header(skb, 0);
 
-	info = IEEE80211_SKB_CB(skb);
-	memset(info, 0, sizeof(struct ieee80211_tx_info));
-	info->control.ifindex = sdata->dev->ifindex;
-	if (!encrypt)
-		info->flags |= IEEE80211_TX_CTL_DO_NOT_ENCRYPT;
+	skb->iif = sdata->dev->ifindex;
+	skb->do_not_encrypt = !encrypt;
 
 	dev_queue_xmit(skb);
 }
--- everything.orig/include/linux/skbuff.h	2008-07-29 09:08:16.000000000 +0200
+++ everything/include/linux/skbuff.h	2008-07-29 09:15:17.000000000 +0200
@@ -316,7 +316,10 @@ struct sk_buff {
 #ifdef CONFIG_IPV6_NDISC_NODETYPE
 	__u8			ndisc_nodetype:2;
 #endif
-	/* 14 bit hole */
+#if defined(CONFIG_MAC80211) || defined(CONFIG_MAC80211_MODULE)
+	__u8			do_not_encrypt:1;
+#endif
+	/* 0/13/14 bit hole */
 
 #ifdef CONFIG_NET_DMA
 	dma_cookie_t		dma_cookie;
--- everything.orig/net/core/skbuff.c	2008-07-29 09:15:39.000000000 +0200
+++ everything/net/core/skbuff.c	2008-07-29 09:16:13.000000000 +0200
@@ -485,6 +485,9 @@ static struct sk_buff *__skb_clone(struc
 	C(head);
 	C(data);
 	C(truesize);
+#if defined(CONFIG_MAC80211) || defined(CONFIG_MAC80211_MODULE)
+	C(do_not_encrypt);
+#endif
 	atomic_set(&n->users, 1);
 
 	atomic_inc(&(skb_shinfo(skb)->dataref));
--- everything.orig/net/mac80211/main.c	2008-07-29 09:18:20.000000000 +0200
+++ everything/net/mac80211/main.c	2008-07-29 09:19:06.000000000 +0200
@@ -1233,18 +1233,12 @@ static void ieee80211_tasklet_handler(un
 /* Remove added headers (e.g., QoS control), encryption header/MIC, etc. to
  * make a prepared TX frame (one that has been given to hw) to look like brand
  * new IEEE 802.11 frame that is ready to go through TX processing again.
- * Also, tx_packet_data in cb is restored from tx_control. */
+ */
 static void ieee80211_remove_tx_extra(struct ieee80211_local *local,
 				      struct ieee80211_key *key,
 				      struct sk_buff *skb)
 {
 	int hdrlen, iv_len, mic_len;
-	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
-
-	info->flags &=	IEEE80211_TX_CTL_REQ_TX_STATUS |
-			IEEE80211_TX_CTL_DO_NOT_ENCRYPT |
-			IEEE80211_TX_CTL_REQUEUE |
-			IEEE80211_TX_CTL_EAPOL_FRAME;
 
 	hdrlen = ieee80211_get_hdrlen_from_skb(skb);
 
--- everything.orig/drivers/net/wireless/ath5k/base.c	2008-07-29 09:38:38.000000000 +0200
+++ everything/drivers/net/wireless/ath5k/base.c	2008-07-29 09:38:53.000000000 +0200
@@ -1224,7 +1224,7 @@ ath5k_txbuf_setup(struct ath5k_softc *sc
 
 	pktlen = skb->len;
 
-	if (!(info->flags & IEEE80211_TX_CTL_DO_NOT_ENCRYPT)) {
+	if (info->control.hw_key) {
 		keyidx = info->control.hw_key->hw_key_idx;
 		pktlen += info->control.icv_len;
 	}
--- everything.orig/drivers/net/wireless/b43/xmit.c	2008-07-29 09:39:28.000000000 +0200
+++ everything/drivers/net/wireless/b43/xmit.c	2008-07-29 09:40:19.000000000 +0200
@@ -192,7 +192,7 @@ int b43_generate_txhdr(struct b43_wldev 
 	const struct b43_phy *phy = &dev->phy;
 	const struct ieee80211_hdr *wlhdr =
 	    (const struct ieee80211_hdr *)fragment_data;
-	int use_encryption = (!(info->flags & IEEE80211_TX_CTL_DO_NOT_ENCRYPT));
+	int use_encryption = !!info->control.hw_key;
 	__le16 fctl = wlhdr->frame_control;
 	struct ieee80211_rate *fbrate;
 	u8 rate, rate_fb;
--- everything.orig/drivers/net/wireless/b43legacy/xmit.c	2008-07-29 09:39:29.000000000 +0200
+++ everything/drivers/net/wireless/b43legacy/xmit.c	2008-07-29 09:40:25.000000000 +0200
@@ -192,7 +192,7 @@ static int generate_txhdr_fw3(struct b43
 			       u16 cookie)
 {
 	const struct ieee80211_hdr *wlhdr;
-	int use_encryption = (!(info->flags & IEEE80211_TX_CTL_DO_NOT_ENCRYPT));
+	int use_encryption = !!info->control.hw_key;
 	u16 fctl;
 	u8 rate;
 	struct ieee80211_rate *rate_fb;
--- everything.orig/drivers/net/wireless/iwlwifi/iwl-tx.c	2008-07-29 09:39:28.000000000 +0200
+++ everything/drivers/net/wireless/iwlwifi/iwl-tx.c	2008-07-29 09:39:44.000000000 +0200
@@ -906,7 +906,7 @@ int iwl_tx_skb(struct iwl_priv *priv, st
 	 * first entry */
 	iwl_hw_txq_attach_buf_to_tfd(priv, tfd, txcmd_phys, len);
 
-	if (!(info->flags & IEEE80211_TX_CTL_DO_NOT_ENCRYPT))
+	if (info->control.hw_key)
 		iwl_tx_cmd_build_hwcrypto(priv, info, tx_cmd, skb, sta_id);
 
 	/* Set up TFD's 2nd entry to point directly to remainder of skb,
--- everything.orig/drivers/net/wireless/iwlwifi/iwl3945-base.c	2008-07-29 09:39:28.000000000 +0200
+++ everything/drivers/net/wireless/iwlwifi/iwl3945-base.c	2008-07-29 09:39:39.000000000 +0200
@@ -2667,7 +2667,7 @@ static int iwl3945_tx_skb(struct iwl3945
 	 * first entry */
 	iwl3945_hw_txq_attach_buf_to_tfd(priv, tfd, txcmd_phys, len);
 
-	if (!(info->flags & IEEE80211_TX_CTL_DO_NOT_ENCRYPT))
+	if (info->control.hw_key)
 		iwl3945_build_tx_cmd_hwcrypto(priv, info, out_cmd, skb, 0);
 
 	/* Set up TFD's 2nd entry to point directly to remainder of skb,
--- everything.orig/drivers/net/wireless/rt2x00/rt2x00mac.c	2008-07-29 09:39:28.000000000 +0200
+++ everything/drivers/net/wireless/rt2x00/rt2x00mac.c	2008-07-29 09:40:08.000000000 +0200
@@ -63,7 +63,7 @@ static int rt2x00mac_tx_rts_cts(struct r
 	 */
 	memcpy(skb->cb, frag_skb->cb, sizeof(skb->cb));
 	rts_info = IEEE80211_SKB_CB(skb);
-	rts_info->flags |= IEEE80211_TX_CTL_DO_NOT_ENCRYPT;
+	rts_info->control.hw_key = NULL;
 	rts_info->flags &= ~IEEE80211_TX_CTL_USE_RTS_CTS;
 	rts_info->flags &= ~IEEE80211_TX_CTL_USE_CTS_PROTECT;
 	rts_info->flags &= ~IEEE80211_TX_CTL_REQ_TX_STATUS;
--- everything.orig/net/mac80211/wme.c	2008-07-29 09:45:41.000000000 +0200
+++ everything/net/mac80211/wme.c	2008-07-29 09:47:17.000000000 +0200
@@ -188,6 +188,9 @@ int ieee80211_ht_agg_queue_add(struct ie
 {
 	int i;
 
+	/* XXX: currently broken due to cb/requeue use */
+	return -EPERM;
+
 	/* prepare the filter and save it for the SW queue
 	 * matching the received HW queue */
 

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 2.6.27-rc1: zd1211rw association fails
  2008-07-29 11:26       ` Johannes Berg
  2008-07-29 11:37         ` Hugh Dickins
@ 2008-07-29 11:46         ` Kalle Valo
  2008-07-29 11:55         ` Alistair John Strachan
  2 siblings, 0 replies; 42+ messages in thread
From: Kalle Valo @ 2008-07-29 11:46 UTC (permalink / raw)
  To: Johannes Berg
  Cc: Alistair John Strachan, Linus Torvalds,
	Linux Kernel Mailing List, dsd, kune, linux-wireless

Johannes Berg <johannes@sipsolutions.net> writes:

>> If it doesn't strain you too much more, could you actually tell me
>> where this is? Your last 5 posts to LKML don't seem to contain such
>> a patch, and I'm not subscribed to linux-wireless.
>
> Well, the latter has archives.

Here's a link to the patch:

http://marc.info/?l=linux-wireless&m=121732394028001&w=2

-- 
Kalle Valo

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 2.6.27-rc1: zd1211rw association fails
  2008-07-29 11:26       ` Johannes Berg
  2008-07-29 11:37         ` Hugh Dickins
  2008-07-29 11:46         ` Kalle Valo
@ 2008-07-29 11:55         ` Alistair John Strachan
  2 siblings, 0 replies; 42+ messages in thread
From: Alistair John Strachan @ 2008-07-29 11:55 UTC (permalink / raw)
  To: Johannes Berg
  Cc: Linus Torvalds, Linux Kernel Mailing List, dsd, kune, linux-wireless

On Tuesday 29 July 2008 12:26:17 Johannes Berg wrote:
> > If it doesn't strain you too much more, could you actually tell me where
> > this is? Your last 5 posts to LKML don't seem to contain such a patch,
> > and I'm not subscribed to linux-wireless.
>
> Well, the latter has archives.

Thanks for the patch, it fixes the issue for me with my zd1211rw. I hope 
the "100 million" rabid users that reported this can piss off happily with 
their working wireless. ;-)

(BTW thanks Hugh/Holger for the patch posting/link.)

-- 
Cheers,
Alistair.

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 2.6.27-rc1: zd1211rw association fails
  2008-07-29 10:09   ` Johannes Berg
  2008-07-29 11:25     ` Alistair John Strachan
@ 2008-07-29 12:04     ` Theodore Tso
  2008-07-29 12:09       ` Johannes Berg
  1 sibling, 1 reply; 42+ messages in thread
From: Theodore Tso @ 2008-07-29 12:04 UTC (permalink / raw)
  To: Johannes Berg
  Cc: Alistair John Strachan, Linus Torvalds,
	Linux Kernel Mailing List, dsd, kune, linux-wireless

On Tue, Jul 29, 2008 at 12:09:55PM +0200, Johannes Berg wrote:
> This is about the 100 millionth time this is reported. Please try the
> patch I just posted.

Yeah, it's really too bad -rc1 got released just before you were able
to post the fix to this, since if there were 100 million people who
were trying out kernels starting with -git7 that use wireless, there
will probably be 200 million people trying out -rc1.  :-)

Thanks for finding and fixing it, though.  I stopped trying out
kernels after -git6 since I was travelling at OSCON, and not having
wireless was a show-stopper for me....

						- Ted

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 2.6.27-rc1: zd1211rw association fails
  2008-07-29 12:04     ` Theodore Tso
@ 2008-07-29 12:09       ` Johannes Berg
  2008-07-29 12:15         ` Johannes Berg
  0 siblings, 1 reply; 42+ messages in thread
From: Johannes Berg @ 2008-07-29 12:09 UTC (permalink / raw)
  To: Theodore Tso
  Cc: Alistair John Strachan, Linus Torvalds,
	Linux Kernel Mailing List, dsd, kune, linux-wireless

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

On Tue, 2008-07-29 at 08:04 -0400, Theodore Tso wrote:
> On Tue, Jul 29, 2008 at 12:09:55PM +0200, Johannes Berg wrote:
> > This is about the 100 millionth time this is reported. Please try the
> > patch I just posted.
> 
> Yeah, it's really too bad -rc1 got released just before you were able
> to post the fix to this, since if there were 100 million people who
> were trying out kernels starting with -git7 that use wireless, there
> will probably be 200 million people trying out -rc1.  :-)
> 
> Thanks for finding and fixing it, though.  I stopped trying out
> kernels after -git6 since I was travelling at OSCON, and not having
> wireless was a show-stopper for me....

If everybody's going to decide now to hit on _me_, I'll point out that
davem's MQ TX changes broke it, I only heard about the problem once that
was out because nobody had found it earlier, and I was also travelling
at OLS.

Maybe the lesson we could learn from this is to not release an rc1 while
a bunch of important people are at various conferences.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 2.6.27-rc1: zd1211rw association fails
  2008-07-29 12:09       ` Johannes Berg
@ 2008-07-29 12:15         ` Johannes Berg
  2008-07-29 15:18           ` Theodore Tso
  2008-07-29 17:52           ` John W. Linville
  0 siblings, 2 replies; 42+ messages in thread
From: Johannes Berg @ 2008-07-29 12:15 UTC (permalink / raw)
  To: Theodore Tso
  Cc: Alistair John Strachan, Linus Torvalds,
	Linux Kernel Mailing List, dsd, kune, linux-wireless

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


> > Yeah, it's really too bad -rc1 got released just before you were able
> > to post the fix to this, since if there were 100 million people who
> > were trying out kernels starting with -git7 that use wireless, there
> > will probably be 200 million people trying out -rc1.  :-)
> > 
> > Thanks for finding and fixing it, though.  I stopped trying out
> > kernels after -git6 since I was travelling at OSCON, and not having
> > wireless was a show-stopper for me....
> 
> If everybody's going to decide now to hit on _me_, I'll point out that
> davem's MQ TX changes broke it

Of course that's not strictly true, it had been broken forever, it just
happened to never show up before. And I mean forever, the original
devicescape code that got in was already broken.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Oops in microcode sysfs registration,
  2008-07-29  3:23 Linux v2.6.27-rc1 Linus Torvalds
  2008-07-29  4:01 ` Nick Piggin
  2008-07-29  9:49 ` 2.6.27-rc1: zd1211rw association fails Alistair John Strachan
@ 2008-07-29 13:57 ` Alistair John Strachan
  2008-07-29 16:22   ` Pekka Paalanen
  2008-07-29 16:27 ` Linux v2.6.27-rc1 Jesse Barnes
                   ` (3 subsequent siblings)
  6 siblings, 1 reply; 42+ messages in thread
From: Alistair John Strachan @ 2008-07-29 13:57 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Linux Kernel Mailing List, shaohua.li, tigran, Ingo Molnar,
	Thomas Gleixner, Steven Rostedt, Pekka Paalanen

Hi,

(Sorry for the CC frenzy. If you don't have or want anything to do with the
tracing framework in 2.6.27 or the microcode driver, you can stop reading
now.)

Noticing pq's mmiotrace was merged I tried to get a trace of the proprietary
NVIDIA blob. Normally I wouldn't waste your time posting a tainted oops,
however in this case it doesn't look related to the proprietary garbage and I
think there's a real bug somewhere.

As I understand it, the mmiotrace tracing framework requires only one logical
CPU to be active, automatically offlining the other CPUs. When mmiotrace is
disabled, it automatically re-enables the CPUs it offlined. If I offline the
spare CPUs myself, prior to enabling mmiotrace, I do not see the issue I'm
about to describe. That's why tracing people have been CCed, even though that
could be a red herring.

The full dmesg and kernel config are available from
http://devzero.co.uk/~alistair/2.6.27-rc1-mc-oops/

nvidia: module license 'NVIDIA' taints kernel.
Symbol init_mm is marked as UNUSED, however this module is using it.
This symbol will go away in the future.
Please evalute if this is the right api to use and if it really is, submit a report the linux kernel mailinglist together with submitting your code for inclusion.
nvidia 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
nvidia 0000:01:00.0: setting latency timer to 64
NVRM: loading NVIDIA UNIX x86_64 Kernel Module  173.14.09  Wed Jun  4 23:40:50 PDT 2008
in mmio_trace_init
mmiotrace: Disabling non-boot CPUs...
kvm: disabling virtualization on CPU1
CPU 1 is now offline
SMP alternatives: switching to UP code
CPU0 attaching NULL sched-domain.
CPU1 attaching NULL sched-domain.
CPU0 attaching NULL sched-domain.
mmiotrace: CPU1 is down.
mmiotrace: enabled.
Symbol init_mm is marked as UNUSED, however this module is using it.
This symbol will go away in the future.
Please evalute if this is the right api to use and if it really is, submit a report the linux kernel mailinglist together with submitting your code for inclusion.
nvidia 0000:01:00.0: setting latency timer to 64
NVRM: loading NVIDIA UNIX x86_64 Kernel Module  173.14.09  Wed Jun  4 23:40:50 PDT 2008
mmiotrace: ioremap_*(0xfa000000, 0x1000000) = ffffc20010b80000
mmiotrace: ioremap_*(0xd0000000, 0x6000) = ffffc20010578000
mmiotrace: ioremap_*(0xe0000000, 0x1000) = ffffc200104fe000
mmiotrace: Unmapping ffffc200104fe000.
mmiotrace: ioremap_*(0xe0008000, 0x1000) = ffffc200104fe000
mmiotrace: ioremap_*(0xe0100000, 0x1000) = ffffc20010500000
mmiotrace: Unmapping ffffc20010500000.
mmiotrace: ioremap_*(0xf8000000, 0x1000000) = ffffc20011c00000
mmiotrace: ioremap_*(0xe0100000, 0x1000) = ffffc20010500000
mmiotrace: Unmapping ffffc20010500000.
mmiotrace: ioremap_*(0xd0504000, 0x1000) = ffffc20010500000
mmiotrace: ioremap_*(0xd0519000, 0x1000) = ffffc20010502000
mmiotrace: ioremap_*(0xd051a000, 0x1000) = ffffc20010572000
mmiotrace: Unmapping ffffc20010502000.
mmiotrace: Unmapping ffffc20010572000.
mmiotrace: Unmapping ffffc20010500000.
mmiotrace: Unmapping ffffc200104fe000.
mmiotrace: Unmapping ffffc20011c00000.
mmiotrace: Unmapping ffffc20010578000.
mmiotrace: Unmapping ffffc20010b80000.
in mmio_trace_reset
mmiotrace: Re-enabling CPUs...
SMP alternatives: switching to SMP code
Booting processor 1/1 ip 6000
Initializing CPU#1
Calibrating delay using timer specific routine.. <6>7200.61 BogoMIPS (lpj=3600306)
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 4096K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
CPU1: Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz stepping 06
checking TSC synchronization [CPU#0 -> CPU#1]: passed.
kvm: enabling virtualization on CPU1
CPU0 attaching NULL sched-domain.
Switched to high resolution mode on CPU 1
CPU0 attaching sched-domain:
 domain 0: span 0-1 level MC
  groups: 0 1
CPU1 attaching sched-domain:
 domain 0: span 0-1 level MC
  groups: 1 0
------------[ cut here ]------------
Kernel BUG at ffffffff8021a31d [verbose debug info unavailable]
invalid opcode: 0000 [1] PREEMPT SMP
CPU 0
Modules linked in: nvidia(P) rfcomm l2cap kvm_intel kvm ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack ip_tables x_tables bridge stp llc acpi_cpufreq freq_table coretemp 
hwmon snd_pcm_oss snd_mixer_oss firewire_sbp2 hci_usb bluetooth arc4 ecb crypto_blkcipher cryptomgr crypto_algapi usbhid zd1211rw mac80211 crypto cfg80211 snd_emu10k1 snd_rawmidi 
snd_ac97_codec ac97_bus snd_seq_device sg snd_util_mem snd_hda_intel snd_pcm snd_timer snd_hwdep snd i2c_i801 sr_mod firewire_ohci firewire_core soundcore r8169 ehci_hcd uhci_hcd 
snd_page_alloc crc_itu_t i2c_core usbcore cdrom [last unloaded: nvidia]
Pid: 2733, comm: bash Tainted: P       A  2.6.27-rc1-damocles #3
RIP: 0010:[<ffffffff8021a31d>]  [<ffffffff8021a31d>] __mc_sysdev_add+0xc3/0x1f1
RSP: 0018:ffff8800b7c1dce8  EFLAGS: 00010297
RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff880080a04000
RDX: ffffffff8062c680 RSI: 0000000000000003 RDI: ffffffff8059e830
RBP: ffff8800b7c1dd48 R08: ffff8800b7c1c000 R09: ffffffff80229ca4
R10: ffff8800010247b0 R11: ffff8800bf879de0 R12: 0000000000000018
R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000
FS:  00007fa4bf6176e0(0000) GS:ffffffff805da200(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00007f3a6cf05098 CR3: 00000000b7d64000 CR4: 00000000000026e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400
Process bash (pid: 2733, threadinfo ffff8800b7c1c000, task ffff8800bd06ab20)
Stack:  ffffffff80627040 0000000000000000 0000000000000008 ffffffff8048bb28
 0000000000000003 ffffffff802ce910 ffff8800b7c1dd28 0000000000000002
 00000000ffffffe8 0000000000000001 0000000000000001 ffff880001028418
Call Trace:
 [<ffffffff802ce910>] ? sysfs_add_file+0xc/0xe
 [<ffffffff8021a456>] mc_sysdev_add+0xb/0xd
 [<ffffffff8047baaf>] mc_cpu_callback+0x4b/0x208
 [<ffffffff8047b772>] ? mce_cpu_callback+0x3e/0xbc
 [<ffffffff8024b787>] notifier_call_chain+0x33/0x5b
 [<ffffffff8024b81f>] raw_notifier_call_chain+0xf/0x11
 [<ffffffff8047e1dc>] _cpu_up+0xce/0x119
 [<ffffffff8047e285>] cpu_up+0x5e/0x8a
 [<ffffffff80224967>] disable_mmiotrace+0xfe/0x173
 [<ffffffff80265279>] mmio_trace_reset+0x2d/0x44
 [<ffffffff80262c4d>] tracing_set_trace_write+0xd3/0x10f
 [<ffffffff80289cab>] ? filp_close+0x67/0x72
 [<ffffffff8028bee3>] vfs_write+0xa7/0xe1
 [<ffffffff8028bfe1>] sys_write+0x47/0x6f
 [<ffffffff8020b6db>] system_call_fastpath+0x16/0x1b
[  903.144002]
[  903.144002]
Code: e8 59 80 e8 fd 69 26 00 48 c7 c2 80 c6 62 80 48 8b 05 c0 00 3c 00 48 8b 04 d8 48 8b 48 08 65 8b 04 25 24 00 00 00 44 39 e8 74 04 <0f> 0b eb fe 4c 8d 04 0a 41 c7 84 24 7c 36 64 80 00 
00 00 00 41
RIP  [<ffffffff8021a31d>] __mc_sysdev_add+0xc3/0x1f1
 RSP <ffff8800b7c1dce8>
---[ end trace 39a5700403aca092 ]---

The box was vaguely usable and then choked to death a few minutes later. I was
initially confused by the multi-core stuff chiming in, but the functions
mc_cpu_callback and mc_sysdev_add are from the microcode driver. At a guess,
something is being done in a context it shouldn't be. I've not tested it
enough to say whether or not it will always crash.

Also, I'm sure this is reproducible without the NVIDIA garbage, but I was too lazy
to test it. If you want me to repeat the experiment without the driver I would be
more than happy to do so.

-- 
Cheers,
Alistair.

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 2.6.27-rc1: zd1211rw association fails
  2008-07-29 12:15         ` Johannes Berg
@ 2008-07-29 15:18           ` Theodore Tso
  2008-07-29 17:52           ` John W. Linville
  1 sibling, 0 replies; 42+ messages in thread
From: Theodore Tso @ 2008-07-29 15:18 UTC (permalink / raw)
  To: Johannes Berg
  Cc: Alistair John Strachan, Linus Torvalds,
	Linux Kernel Mailing List, dsd, kune, linux-wireless

On Tue, Jul 29, 2008 at 02:15:06PM +0200, Johannes Berg wrote:
> > If everybody's going to decide now to hit on _me_, I'll point out that
> > davem's MQ TX changes broke it
> 
> Of course that's not strictly true, it had been broken forever, it just
> happened to never show up before. And I mean forever, the original
> devicescape code that got in was already broken.

Sorry, no, I wasn't trying to blame you.  I understand that this was a
hard problem to fix, and it wasn't at all obvious that changes in one
part of the networking stack would break wireless stack due to bad
assumptions it had made, that had been hiding for quite some time.

The timing is just very unfortunate, since if -rc1 had been delayed by
just one more day so it could have incorporated it we would probably
reduce the large number of regression reports; a lot of people who
test -rc1 don't necessarily follow netdev or linux-wireless.

I'm of course also nervously building -rc1 and about to test it, since
I haven't had a chance to test anything since -git6, and I'm wondering
if some other regression may have been introduced since then.

Since it probably doesn't get said enough to everyone who works of
fixing bugs/regressions, thanks very much for your efforts; I (and
many other people) very much appreciate it!!

						- Ted

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Oops in microcode sysfs registration,
  2008-07-29 13:57 ` Oops in microcode sysfs registration, Alistair John Strachan
@ 2008-07-29 16:22   ` Pekka Paalanen
  2008-07-29 16:50     ` Alistair John Strachan
  0 siblings, 1 reply; 42+ messages in thread
From: Pekka Paalanen @ 2008-07-29 16:22 UTC (permalink / raw)
  To: Alistair John Strachan
  Cc: Linus Torvalds, Linux Kernel Mailing List, shaohua.li, tigran,
	Ingo Molnar, Thomas Gleixner, Steven Rostedt

On Tue, 29 Jul 2008 14:57:58 +0100
Alistair John Strachan <alistair@devzero.co.uk> wrote:

> Noticing pq's mmiotrace was merged I tried to get a trace of the proprietary
> NVIDIA blob. Normally I wouldn't waste your time posting a tainted oops,
> however in this case it doesn't look related to the proprietary garbage and I
> think there's a real bug somewhere.
> 
> As I understand it, the mmiotrace tracing framework requires only one logical
> CPU to be active, automatically offlining the other CPUs. When mmiotrace is
> disabled, it automatically re-enables the CPUs it offlined. If I offline the
> spare CPUs myself, prior to enabling mmiotrace, I do not see the issue I'm
> about to describe. That's why tracing people have been CCed, even though that
> could be a red herring.

I have a wild hunch...
Could you try the following:
1. with all cpus enabled, load the nvidia proprietary driver
2. start and quit X
3. disable a cpu by hand
4. unload the proprietary driver
5. enable the cpu by hand

I have a vague recollection of the nvidia blob doing something bad
with notifiers, so if that crashes, and it does not crash when you
leave step 4 out, it's an nvidia problem. I assume you unloaded the
blob before disabling mmiotrace, right?

You may need to alter the sequence of things, but my guess is that
the blob may leave a notifier registered even when it is unloaded,
so it crashes when the notifier chain is traversed. I'm not sure the
backtrace really supports this scenario, but worth to try.

> The full dmesg and kernel config are available from
> http://devzero.co.uk/~alistair/2.6.27-rc1-mc-oops/
...
> Also, I'm sure this is reproducible without the NVIDIA garbage, but I was too lazy
> to test it. If you want me to repeat the experiment without the driver I would be
> more than happy to do so.

I'm not sure people are willing to look into this without a clean report,
so this would be cool. There's even a test module for mmiotrace in the
kernel, but I doubt it would make difference to use it or not, when trying
to reproduce the crash without the blob.

Thanks.

-- 
Pekka Paalanen
http://www.iki.fi/pq/

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Linux v2.6.27-rc1
  2008-07-29  3:23 Linux v2.6.27-rc1 Linus Torvalds
                   ` (2 preceding siblings ...)
  2008-07-29 13:57 ` Oops in microcode sysfs registration, Alistair John Strachan
@ 2008-07-29 16:27 ` Jesse Barnes
  2008-07-29 16:59   ` Linus Torvalds
  2008-07-29 20:49 ` Linux v2.6.27-rc1: problem with firmware stuff Rafael J. Wysocki
                   ` (2 subsequent siblings)
  6 siblings, 1 reply; 42+ messages in thread
From: Jesse Barnes @ 2008-07-29 16:27 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List, Stephen Rothwell

On Monday, July 28, 2008 8:23 pm Linus Torvalds wrote:
> Much of -rc1 was in linux-next, but certainly not everything. We'll see
> how that whole thing ends up evolving - it certainly didn't solve all
> problems, and there was some bickering about things that weren't there
> (and some things that mostly were ;), but maybe it helped.

I think linux-next has been a *huge* help.  It's been great at catching merge 
conflicts and build bugs (though not so much when you don't use it[1]!), and 
Stephen is really easy to work with.  So I, for one, would love to see it 
continue.

Jesse

[1] http://marc.info/?t=121699085400001&r=1&w=2

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Oops in microcode sysfs registration,
  2008-07-29 16:22   ` Pekka Paalanen
@ 2008-07-29 16:50     ` Alistair John Strachan
  2008-07-30  9:07       ` Dmitry Adamushko
  0 siblings, 1 reply; 42+ messages in thread
From: Alistair John Strachan @ 2008-07-29 16:50 UTC (permalink / raw)
  To: Pekka Paalanen
  Cc: Linus Torvalds, Linux Kernel Mailing List, shaohua.li, tigran,
	Ingo Molnar, Thomas Gleixner, Steven Rostedt

On Tuesday 29 July 2008 17:22:14 Pekka Paalanen wrote:
> > Also, I'm sure this is reproducible without the NVIDIA garbage, but I was
> > too lazy to test it. If you want me to repeat the experiment without the
> > driver I would be more than happy to do so.
>
> I'm not sure people are willing to look into this without a clean report,
> so this would be cool. There's even a test module for mmiotrace in the
> kernel, but I doubt it would make difference to use it or not, when trying
> to reproduce the crash without the blob.

Of course, and I should have attempted to reproduce without the driver.
Fortunately that was easy: it is not an NVIDIA driver bug.

Steps to reproduce: have CONFIG_MICROCODE=y and a suitable Intel
processor, then do:

echo mmiotrace >/debug/tracing/current_tracer
echo none >/debug/tracing/current_tracer

And you get this (snipped) oops:

in mmio_trace_init
mmiotrace: Disabling non-boot CPUs...
kvm: disabling virtualization on CPU1
CPU 1 is now offline
SMP alternatives: switching to UP code
CPU0 attaching NULL sched-domain.
CPU1 attaching NULL sched-domain.
CPU0 attaching NULL sched-domain.
mmiotrace: CPU1 is down.
mmiotrace: enabled.
in mmio_trace_reset
mmiotrace: Re-enabling CPUs...
SMP alternatives: switching to SMP code
Booting processor 1/1 ip 6000
Initializing CPU#1
Calibrating delay using timer specific routine.. <6>7204.76 BogoMIPS (lpj=3602381)
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 4096K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
CPU1: Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz stepping 06
checking TSC synchronization [CPU#0 -> CPU#1]: passed.
kvm: enabling virtualization on CPU1
CPU0 attaching NULL sched-domain.
Switched to high resolution mode on CPU 1
CPU0 attaching sched-domain:
 domain 0: span 0-1 level MC
  groups: 0 1
CPU1 attaching sched-domain:
 domain 0: span 0-1 level MC
  groups: 1 0
------------[ cut here ]------------
Kernel BUG at ffffffff8021a31d [verbose debug info unavailable]
invalid opcode: 0000 [1] PREEMPT SMP
CPU 0
Modules linked in: rfcomm l2cap kvm_intel kvm ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack ip_tables x_tables bridge stp llc acpi_cpufreq freq_table coretemp hwmon 
snd_pcm_oss snd_mixer_oss firewire_sbp2 hci_usb bluetooth arc4 ecb crypto_blkcipher cryptomgr crypto_algapi usbhid zd1211rw mac80211 crypto cfg80211 snd_emu10k1 snd_rawmidi 
snd_ac97_codec ac97_bus sg snd_seq_device snd_hda_intel snd_pcm snd_util_mem snd_timer sr_mod snd_hwdep i2c_i801 ehci_hcd firewire_ohci uhci_hcd snd snd_page_alloc firewire_core 
soundcore r8169 cdrom usbcore i2c_core crc_itu_t
Pid: 2757, comm: bash Tainted: G       A  2.6.27-rc1-damocles #3
RIP: 0010:[<ffffffff8021a31d>]  [<ffffffff8021a31d>] __mc_sysdev_add+0xc3/0x1f1
RSP: 0018:ffff8800b8905ce8  EFLAGS: 00010297
RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff880080a04000
RDX: ffffffff8062c680 RSI: 0000000000000003 RDI: ffffffff8059e830
RBP: ffff8800b8905d48 R08: ffff8800b8904000 R09: ffffffff80229ca4
R10: ffff8800010247b0 R11: ffff8800bf879de0 R12: 0000000000000018
R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000
FS:  00007f8ddc78f6e0(0000) GS:ffffffff805da200(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00007f57cb9b2098 CR3: 00000000b8985000 CR4: 00000000000026e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process bash (pid: 2757, threadinfo ffff8800b8904000, task ffff8800bd125640)
Stack:  ffffffff80627040 0000000000000000 0000000000000008 ffffffff8048bb28
 0000000000000003 ffffffff802ce910 ffff8800b8905d28 0000000000000002
 00000000ffffffe8 0000000000000001 0000000000000001 ffff880001028418
Call Trace:
 [<ffffffff802ce910>] ? sysfs_add_file+0xc/0xe
 [<ffffffff8021a456>] mc_sysdev_add+0xb/0xd
 [<ffffffff8047baaf>] mc_cpu_callback+0x4b/0x208
 [<ffffffff8047b772>] ? mce_cpu_callback+0x3e/0xbc
 [<ffffffff8024b787>] notifier_call_chain+0x33/0x5b
 [<ffffffff8024b81f>] raw_notifier_call_chain+0xf/0x11
 [<ffffffff8047e1dc>] _cpu_up+0xce/0x119
 [<ffffffff8047e285>] cpu_up+0x5e/0x8a
 [<ffffffff80224967>] disable_mmiotrace+0xfe/0x173
 [<ffffffff80265279>] mmio_trace_reset+0x2d/0x44
 [<ffffffff80262c4d>] tracing_set_trace_write+0xd3/0x10f
 [<ffffffff80289cab>] ? filp_close+0x67/0x72
 [<ffffffff8028bee3>] vfs_write+0xa7/0xe1
 [<ffffffff8028bfe1>] sys_write+0x47/0x6f
 [<ffffffff8020b6db>] system_call_fastpath+0x16/0x1b
[   68.405002]
[   68.405002]
Code: e8 59 80 e8 fd 69 26 00 48 c7 c2 80 c6 62 80 48 8b 05 c0 00 3c 00 48 8b 04 d8 48 8b 48 08 65 8b 04 25 24 00 00 00 44 39 e8 74 04 <0f> 0b eb fe 4c 8d 04 0a 41 c7 84 24 7c 36 64 80 00 
00 00 00 41
RIP  [<ffffffff8021a31d>] __mc_sysdev_add+0xc3/0x1f1
 RSP <ffff8800b8905ce8>
---[ end trace ee9c9240024cb48c ]---

I've replaced the originally tainted dmesg with this new clean one, so
there's no proprietary smell about it :-)

http://devzero.co.uk/~alistair/2.6.27-rc1-mc-oops/

-- 
Cheers,
Alistair.

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Linux v2.6.27-rc1
  2008-07-29 16:27 ` Linux v2.6.27-rc1 Jesse Barnes
@ 2008-07-29 16:59   ` Linus Torvalds
  2008-07-29 17:31     ` Roland Dreier
  2008-07-30  9:03     ` Andrew Morton
  0 siblings, 2 replies; 42+ messages in thread
From: Linus Torvalds @ 2008-07-29 16:59 UTC (permalink / raw)
  To: Jesse Barnes; +Cc: Linux Kernel Mailing List, Stephen Rothwell



On Tue, 29 Jul 2008, Jesse Barnes wrote:
> 
> I think linux-next has been a *huge* help.  It's been great at catching merge 
> conflicts and build bugs (though not so much when you don't use it[1]!), and 
> Stephen is really easy to work with.  So I, for one, would love to see it 
> continue.

I don't think anybody wants it to go away. The question in my mind is more 
along the way of how/whether it should be changed. There was some 
bickering about patches that weren't there, and some about how _partial_ 
series were there but then the finishing touches broke things.

I don't personally really think that it's reasonable to expect everything 
to be in -next (but hey, I'm willing to be convinced otherwise). And don't 
get me wrong - it certainly wouldn't bother _me_ to have everything go 
through next, since it just makes it likelier that I have less to worry 
about.

BUT. I do think 'next' as it is has a few issues that either need to be 
fixed (unlikely - it's not the point of next) or just need to be aired as 
issues and understood:

 - I don't think it does 'quality control', and I think that's pretty 
   fundamental.

   Now, admittedly I don't look much at the patches of people I trust 
   either (that's what the whole point of that 'trust' is, after all - to 
   make me not be the part that limits development speed), but that's 
   still different from 'largely automated merging'.

   So I _do_ check the things that aren't obvious "maintainer works on his 
   own subsystem" or are so core that I really feel like I need to know 
   what's up. I seldom actually say "that's so broken that I refuse to 
   pull it", but I tend to do that a couple of times per release.

   That may not sound like much, but it's enough to make me worry about 
   'next'. I worry that 'it has been in next' has become a code-word for 
   "pull this, because it's good", and I'm not at all convinced that 
   'next' sees any real critical checking.

 - I don't think the 'next' thing works as well for the occasional 
   developer that just has a few patches pending as it works for subsystem 
   maintainers that are used to it.

   IOW, I think 'next' needs enough infrastructure setup from the 
   developer side that I don't think it's reasonable for _everything_ to 
   go through next. And that in turn means that I'm not entirely thrilled 
   when people then complain "that wasn't in next". I think people should 
   accept that not everything will be in next.

But I don't think either of the above issues is a 'problem' - I just think 
they should be acknowledged. I think 'next' is a good way for the big 
subsystem developers to be able to see problems early, but I really hope 
that nobody will _ever_ see next as a "that's the way into Linus' tree", 
because for the above two reasons I do not think it can really work that 
way.

			Linus

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Linux v2.6.27-rc1
  2008-07-29 16:59   ` Linus Torvalds
@ 2008-07-29 17:31     ` Roland Dreier
  2008-07-30  9:03     ` Andrew Morton
  1 sibling, 0 replies; 42+ messages in thread
From: Roland Dreier @ 2008-07-29 17:31 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Jesse Barnes, Linux Kernel Mailing List, Stephen Rothwell

 >    That may not sound like much, but it's enough to make me worry about 
 >    'next'. I worry that 'it has been in next' has become a code-word for 
 >    "pull this, because it's good", and I'm not at all convinced that 
 >    'next' sees any real critical checking.

I've been mentioning that my trees have been in next as code for, "I
don't think this should break the build or clash too badly with anything
else."  And next has been useful to me on several occasions for catching
that sort of problem before things hit mainline.

 - R.

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 2.6.27-rc1: zd1211rw association fails
  2008-07-29 12:15         ` Johannes Berg
  2008-07-29 15:18           ` Theodore Tso
@ 2008-07-29 17:52           ` John W. Linville
  2008-07-30  4:48             ` David Miller
  1 sibling, 1 reply; 42+ messages in thread
From: John W. Linville @ 2008-07-29 17:52 UTC (permalink / raw)
  To: Johannes Berg
  Cc: Theodore Tso, Alistair John Strachan, Linus Torvalds,
	Linux Kernel Mailing List, dsd, kune, linux-wireless

On Tue, Jul 29, 2008 at 02:15:06PM +0200, Johannes Berg wrote:
> 
> > > Yeah, it's really too bad -rc1 got released just before you were able
> > > to post the fix to this, since if there were 100 million people who
> > > were trying out kernels starting with -git7 that use wireless, there
> > > will probably be 200 million people trying out -rc1.  :-)
> > > 
> > > Thanks for finding and fixing it, though.  I stopped trying out
> > > kernels after -git6 since I was travelling at OSCON, and not having
> > > wireless was a show-stopper for me....
> > 
> > If everybody's going to decide now to hit on _me_, I'll point out that
> > davem's MQ TX changes broke it
> 
> Of course that's not strictly true, it had been broken forever, it just
> happened to never show up before. And I mean forever, the original
> devicescape code that got in was already broken.

FWIW, I think the MQ stuff didn't spend much (or any) time in -next...

-- 
John W. Linville
linville@tuxdriver.com

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Linux v2.6.27-rc1: problem with firmware stuff
  2008-07-29  3:23 Linux v2.6.27-rc1 Linus Torvalds
                   ` (3 preceding siblings ...)
  2008-07-29 16:27 ` Linux v2.6.27-rc1 Jesse Barnes
@ 2008-07-29 20:49 ` Rafael J. Wysocki
  2008-07-29 21:01   ` Rafael J. Wysocki
  2008-07-29 21:37 ` Linux v2.6.27-rc1 Sam Ravnborg
  2008-07-29 22:03 ` Linux v2.6.27-rc1: fails to compile Grant Coady
  6 siblings, 1 reply; 42+ messages in thread
From: Rafael J. Wysocki @ 2008-07-29 20:49 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List, David Woodhouse, Andrew Morton

On Tuesday, 29 of July 2008, Linus Torvalds wrote:
> 
> It's two weeks (and one day), and the merge window is over.
> 
> Finally. I don't know why, but this one really did feel pretty dang busy. 
> And the size of the -rc1 patch bears that out - at 12MB, it's about 50% 
> bigger than 26-rc1 (but not that much bigger than 24/25-rc1, so it's not 
> like it's anything unheard of).
> 
> The pure size of the -rc's _is_ making me a bit nervous, though. Sure, it 
> means that we are good at merging it all, but I have to say that I 
> sometimes wonder if we don't merge too much in one go, and even our 
> current (fairly short) release cycle is actually too big.
> 
> Anyway, that's a discussion for some other event.
> 
> Much of -rc1 was in linux-next, but certainly not everything. We'll see 
> how that whole thing ends up evolving - it certainly didn't solve all 
> problems, and there was some bickering about things that weren't there 
> (and some things that mostly were ;), but maybe it helped.
> 
> There's a ton of new stuff in there, but at least personally the 
> interesting things are the BKL pushdown and perhaps the introduction of 
> the lockless get_user_pages_fast(). The build system also got updated to 
> allow moving the architecture include files ("include/asm-xyz") into the 
> architecture subdirectories ("arch/xyz/include/asm"), and sparc seems to 
> have taken advantage of that already.
> 
> But those changes are just small details in the end. As usual, the bulk of 
> changes are all to device drivers (roughly half, as usual), with the arch 
> directory amounting to about half of the remainder. Dirstat:
> 
>    3.2% arch/arm/
>    9.2% arch/ppc/
>   24.6% arch/
>    5.2% drivers/char/drm/
>    6.3% drivers/char/
>    4.5% drivers/gpu/drm/
>    4.5% drivers/gpu/
>    4.6% drivers/media/video/
>    5.5% drivers/media/
>    3.0% drivers/net/wireless/
>   10.7% drivers/net/
>    6.4% drivers/usb/misc/
>    4.7% drivers/usb/serial/
>   12.9% drivers/usb/
>   51.2% drivers/
>    4.4% firmware/
>    3.7% fs/
>    9.2% include/
> 
> where the bulk of that fs/ update is the merge of the UBI filesystem, to 
> pick one fairly sizeable chunk outside of arch or drivers (there's omfs 
> too, but that's tiny in comparison).
> 
> Other stuff? tracing. firmware loading.

That one happens to break things for me badly:

rafael@chimera:~/src/linux-2.6> make O=../build/mainline/chimera -j5
  GEN     /home/rafael/src/build/mainline/chimera/Makefile
  CHK     include/linux/version.h
  CHK     include/linux/utsrelease.h
  Using /home/rafael/src/linux-2.6 as source for kernel
  CALL    /home/rafael/src/linux-2.6/scripts/checksyscalls.sh
  CHK     include/linux/compile.h
  Building modules, stage 2.
Kernel: arch/x86/boot/bzImage is ready  (#208)
  MODPOST 564 modules
  IHEX2FW firmware/emi26/loader.fw
Failed to open destination file: Permission deniedihex2fw: Convert ihex files into binary representation for use by Linux kernel
usage: ihex2fw [<options>] <src.HEX> <dst.fw>
       -w: wide records (16-bit length)
       -s: sort records by address
  IHEX2FW firmware/emi26/bitstream.fw
  IHEX2FW firmware/emi26/firmware.fw
Failed to open destination file: Permission deniedihex2fw: Convert ihex files into binary representation for use by Linux kernel
usage: ihex2fw [<options>] <src.HEX> <dst.fw>
       -w: wide records (16-bit length)
       -s: sort records by address
make[2]: *** [firmware/emi26/loader.fw] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [firmware/emi26/bitstream.fw] Error 1
Failed to open destination file: Permission deniedihex2fw: Convert ihex files into binary representation for use by Linux kernel
usage: ihex2fw [<options>] <src.HEX> <dst.fw>
       -w: wide records (16-bit length)
       -s: sort records by address
make[2]: *** [firmware/emi26/firmware.fw] Error 1
make[1]: *** [modules] Error 2
make: *** [sub-make] Error 2

Thanks,
Rafael

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Linux v2.6.27-rc1: problem with firmware stuff
  2008-07-29 21:01   ` Rafael J. Wysocki
@ 2008-07-29 21:01     ` Linus Torvalds
  2008-07-29 22:26       ` David Woodhouse
  0 siblings, 1 reply; 42+ messages in thread
From: Linus Torvalds @ 2008-07-29 21:01 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Linux Kernel Mailing List, David Woodhouse, Andrew Morton



On Tue, 29 Jul 2008, Rafael J. Wysocki wrote:
> 
> Actually, this happened due to some firmware files being created as root during
> installations of pre-rc -git kernels from the O= directory.  So, not a real
> problem, but somewhat confusing.

Yeah, I've had that happen myself. It used to be that "make 
modules_install" (as root, obviously) would try build a new version of the 
kernel, and as a result subsequent build attempts would fail horribly 
because of various random files being now owned-by-root.

I don't know if there is a whole lot we can do about it in general..

			Linus

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Linux v2.6.27-rc1: problem with firmware stuff
  2008-07-29 20:49 ` Linux v2.6.27-rc1: problem with firmware stuff Rafael J. Wysocki
@ 2008-07-29 21:01   ` Rafael J. Wysocki
  2008-07-29 21:01     ` Linus Torvalds
  0 siblings, 1 reply; 42+ messages in thread
From: Rafael J. Wysocki @ 2008-07-29 21:01 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List, David Woodhouse, Andrew Morton

On Tuesday, 29 of July 2008, Rafael J. Wysocki wrote:
> On Tuesday, 29 of July 2008, Linus Torvalds wrote:
> > 
> > It's two weeks (and one day), and the merge window is over.
> > 
> > Finally. I don't know why, but this one really did feel pretty dang busy. 
> > And the size of the -rc1 patch bears that out - at 12MB, it's about 50% 
> > bigger than 26-rc1 (but not that much bigger than 24/25-rc1, so it's not 
> > like it's anything unheard of).
> > 
> > The pure size of the -rc's _is_ making me a bit nervous, though. Sure, it 
> > means that we are good at merging it all, but I have to say that I 
> > sometimes wonder if we don't merge too much in one go, and even our 
> > current (fairly short) release cycle is actually too big.
> > 
> > Anyway, that's a discussion for some other event.
> > 
> > Much of -rc1 was in linux-next, but certainly not everything. We'll see 
> > how that whole thing ends up evolving - it certainly didn't solve all 
> > problems, and there was some bickering about things that weren't there 
> > (and some things that mostly were ;), but maybe it helped.
> > 
> > There's a ton of new stuff in there, but at least personally the 
> > interesting things are the BKL pushdown and perhaps the introduction of 
> > the lockless get_user_pages_fast(). The build system also got updated to 
> > allow moving the architecture include files ("include/asm-xyz") into the 
> > architecture subdirectories ("arch/xyz/include/asm"), and sparc seems to 
> > have taken advantage of that already.
> > 
> > But those changes are just small details in the end. As usual, the bulk of 
> > changes are all to device drivers (roughly half, as usual), with the arch 
> > directory amounting to about half of the remainder. Dirstat:
> > 
> >    3.2% arch/arm/
> >    9.2% arch/ppc/
> >   24.6% arch/
> >    5.2% drivers/char/drm/
> >    6.3% drivers/char/
> >    4.5% drivers/gpu/drm/
> >    4.5% drivers/gpu/
> >    4.6% drivers/media/video/
> >    5.5% drivers/media/
> >    3.0% drivers/net/wireless/
> >   10.7% drivers/net/
> >    6.4% drivers/usb/misc/
> >    4.7% drivers/usb/serial/
> >   12.9% drivers/usb/
> >   51.2% drivers/
> >    4.4% firmware/
> >    3.7% fs/
> >    9.2% include/
> > 
> > where the bulk of that fs/ update is the merge of the UBI filesystem, to 
> > pick one fairly sizeable chunk outside of arch or drivers (there's omfs 
> > too, but that's tiny in comparison).
> > 
> > Other stuff? tracing. firmware loading.
> 
> That one happens to break things for me badly:
> 
> rafael@chimera:~/src/linux-2.6> make O=../build/mainline/chimera -j5
>   GEN     /home/rafael/src/build/mainline/chimera/Makefile
>   CHK     include/linux/version.h
>   CHK     include/linux/utsrelease.h
>   Using /home/rafael/src/linux-2.6 as source for kernel
>   CALL    /home/rafael/src/linux-2.6/scripts/checksyscalls.sh
>   CHK     include/linux/compile.h
>   Building modules, stage 2.
> Kernel: arch/x86/boot/bzImage is ready  (#208)
>   MODPOST 564 modules
>   IHEX2FW firmware/emi26/loader.fw
> Failed to open destination file: Permission deniedihex2fw: Convert ihex files into binary representation for use by Linux kernel
> usage: ihex2fw [<options>] <src.HEX> <dst.fw>
>        -w: wide records (16-bit length)
>        -s: sort records by address
>   IHEX2FW firmware/emi26/bitstream.fw
>   IHEX2FW firmware/emi26/firmware.fw
> Failed to open destination file: Permission deniedihex2fw: Convert ihex files into binary representation for use by Linux kernel
> usage: ihex2fw [<options>] <src.HEX> <dst.fw>
>        -w: wide records (16-bit length)
>        -s: sort records by address
> make[2]: *** [firmware/emi26/loader.fw] Error 1
> make[2]: *** Waiting for unfinished jobs....
> make[2]: *** [firmware/emi26/bitstream.fw] Error 1
> Failed to open destination file: Permission deniedihex2fw: Convert ihex files into binary representation for use by Linux kernel
> usage: ihex2fw [<options>] <src.HEX> <dst.fw>
>        -w: wide records (16-bit length)
>        -s: sort records by address
> make[2]: *** [firmware/emi26/firmware.fw] Error 1
> make[1]: *** [modules] Error 2
> make: *** [sub-make] Error 2

Actually, this happened due to some firmware files being created as root during
installations of pre-rc -git kernels from the O= directory.  So, not a real
problem, but somewhat confusing.

Thanks,
Rafael

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Linux v2.6.27-rc1
  2008-07-29  3:23 Linux v2.6.27-rc1 Linus Torvalds
                   ` (4 preceding siblings ...)
  2008-07-29 20:49 ` Linux v2.6.27-rc1: problem with firmware stuff Rafael J. Wysocki
@ 2008-07-29 21:37 ` Sam Ravnborg
  2008-07-29 21:42   ` Linus Torvalds
  2008-07-29 22:03 ` Linux v2.6.27-rc1: fails to compile Grant Coady
  6 siblings, 1 reply; 42+ messages in thread
From: Sam Ravnborg @ 2008-07-29 21:37 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List

On Mon, Jul 28, 2008 at 08:23:21PM -0700, Linus Torvalds wrote:

> The build system also got updated to 
> allow moving the architecture include files ("include/asm-xyz") into the 
> architecture subdirectories ("arch/xyz/include/asm"), and sparc seems to 
> have taken advantage of that already.

Most architectures are easy to convert. But those that uses
symlinks to select between different platforms etc needs a bit more
care if we shall get rid of all symlinks.

Paul already fixed up sh and sent you a pull request.
I have something ready for arm (not yet posted).
And I sent Harvaard a small script that can fix avr32 when arm is done.
cris looks similar and I can take care too.

The rest that does not use additiona symlinks are in general much simpler.

Kyle already fixed up parisc (simple).
x86 is simple - only a small patch needed to arch/x86/Makefile.
I have not dared looking at um.

But will you accept this stuff now or will we have to wait until
next merge window?
Now is a good time as development just started for next kernel.
And testing is simple - does it build?

It will come in via arch maintainers but I will assist.

	Sam

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Linux v2.6.27-rc1
  2008-07-29 21:37 ` Linux v2.6.27-rc1 Sam Ravnborg
@ 2008-07-29 21:42   ` Linus Torvalds
  2008-07-29 21:59     ` Sam Ravnborg
  0 siblings, 1 reply; 42+ messages in thread
From: Linus Torvalds @ 2008-07-29 21:42 UTC (permalink / raw)
  To: Sam Ravnborg; +Cc: Linux Kernel Mailing List



On Tue, 29 Jul 2008, Sam Ravnborg wrote:
> 
> But will you accept this stuff now or will we have to wait until
> next merge window?

if the patches are really small adn the resulting build is well tested 
(ignoring the actual _move_ operation), I'm ok with taking them.

In fact, in many ways I'd _prefer_ to do it now, rather than have it 
pending and then do it durign the next merge window when there are a lot 
of non-movement changes too.

> Now is a good time as development just started for next kernel.
> And testing is simple - does it build?

Well, simple and simple. I'd love to see x86 done, but you yourself said 
you haven't even dared look at UM. Which is the thing that is most likely 
to have odd build things with direct symlinks etc.

(But I haven't looked either. Maybe I'm wrong, and it's all trivial).

		Linus

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Linux v2.6.27-rc1
  2008-07-29 21:42   ` Linus Torvalds
@ 2008-07-29 21:59     ` Sam Ravnborg
  2008-07-29 22:03       ` Linus Torvalds
  0 siblings, 1 reply; 42+ messages in thread
From: Sam Ravnborg @ 2008-07-29 21:59 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List

On Tue, Jul 29, 2008 at 02:42:00PM -0700, Linus Torvalds wrote:
> 
> 
> On Tue, 29 Jul 2008, Sam Ravnborg wrote:
> > 
> > But will you accept this stuff now or will we have to wait until
> > next merge window?
> 
> if the patches are really small adn the resulting build is well tested 
> (ignoring the actual _move_ operation), I'm ok with taking them.

For arm the actual diff is:
 Makefile                 |   20 +++++++-------------
 boot/compressed/Makefile |    3 ---
 tools/Makefile           |    1 +
 3 files changed, 8 insertions(+), 16 deletions(-)

But on top of this there are ~600 files that needed a
replacement of:
#include <asm/arch/foo.h>
to
#include <arch/foo.h>

So maybe not such a minimal patch - because I wanted to drop all
the symlink stuff.

> 
> In fact, in many ways I'd _prefer_ to do it now, rather than have it 
> pending and then do it durign the next merge window when there are a lot 
> of non-movement changes too.
> 
> > Now is a good time as development just started for next kernel.
> > And testing is simple - does it build?
> 
> Well, simple and simple. I'd love to see x86 done, but you yourself said 
> you haven't even dared look at UM. Which is the thing that is most likely 
> to have odd build things with direct symlinks etc.
> 
> (But I haven't looked either. Maybe I'm wrong, and it's all trivial).
um i never trivial :-(
But I will give it a try - but I have to sleep first.

	Sam

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Linux v2.6.27-rc1: fails to compile
  2008-07-29  3:23 Linux v2.6.27-rc1 Linus Torvalds
                   ` (5 preceding siblings ...)
  2008-07-29 21:37 ` Linux v2.6.27-rc1 Sam Ravnborg
@ 2008-07-29 22:03 ` Grant Coady
  2008-07-29 22:40   ` Frederik Deweerdt
  6 siblings, 1 reply; 42+ messages in thread
From: Grant Coady @ 2008-07-29 22:03 UTC (permalink / raw)
  To: Linux Kernel Mailing List

On Mon, 28 Jul 2008 20:23:21 -0700 (PDT), Linus Torvalds <torvalds@linux-foundation.org> wrote:

>
>It's two weeks (and one day), and the merge window is over.
>
>Finally. I don't know why, but this one really did feel pretty dang busy. 
>And the size of the -rc1 patch bears that out - at 12MB, it's about 50% 
>bigger than 26-rc1 (but not that much bigger than 24/25-rc1, so it's not 
>like it's anything unheard of).

Couple machines failed to compile with same error in different place:

  CC      arch/x86/kernel/acpi/cstate.o
arch/x86/kernel/acpi/cstate.c: In function `acpi_processor_ffh_cstate_probe':
arch/x86/kernel/acpi/cstate.c:94: error: invalid lvalue in unary `&'
make[2]: *** [arch/x86/kernel/acpi/cstate.o] Error 1
make[1]: *** [arch/x86/kernel/acpi] Error 2
make: *** [arch/x86/kernel] Error 2
grant@peetoo:~/linux/linux-2.6.27-rc1a$

Linux peetoo 2.6.25.13a #15 Tue Jul 29 07:41:48 EST 2008 i686 pentium3 i386 GNU/Linux

Gnu C                  3.4.6
Gnu make               3.81
binutils               2.15.92.0.2
util-linux             2.12r
mount                  2.12r
module-init-tools      3.2.2
e2fsprogs              1.38
reiserfsprogs          3.6.19
quota-tools            3.13.
PPP                    2.4.4
Linux C Library        2.3.6
Dynamic linker (ldd)   2.3.6
Linux C++ Library      6.0.3
Procps                 3.2.7
Net-tools              1.60
Kbd                    1.12
oprofile               0.9.1
Sh-utils               5.97
udev                   097
Modules Loaded         adm9240 hwmon_vid nfsd exportfs tulip e100
- - -

  CC      arch/x86/kernel/ldt.o
arch/x86/kernel/ldt.c: In function `alloc_ldt':
arch/x86/kernel/ldt.c:67: error: invalid lvalue in unary `&'
make[1]: *** [arch/x86/kernel/ldt.o] Error 1
make: *** [arch/x86/kernel] Error 2
grant@black:~/linux/linux-2.6.27-rc1a$

Linux black 2.6.26a #1 SMP Fri Jul 25 08:49:49 EST 2008 i686 pentium4 i386 GNU/Linux

Gnu C                  3.4.6
Gnu make               3.81
binutils               2.15.92.0.2
util-linux             2.12r
mount                  2.12r
module-init-tools      3.2.2
e2fsprogs              1.38
jfsutils               1.1.11
reiserfsprogs          3.6.19
xfsprogs               2.8.10
pcmciautils            014
pcmcia-cs              3.2.8
quota-tools            3.13.
PPP                    2.4.4
Linux C Library        2.3.6
Dynamic linker (ldd)   2.3.6
Linux C++ Library      6.0.3
Procps                 3.2.7
Net-tools              1.60
Kbd                    1.12
oprofile               0.9.1
Sh-utils               5.97
udev                   097
Modules Loaded         snd_pcm_oss snd_mixer_oss e100 ide_cd_mod snd_intel8x0 snd_ac97_codec cdrom ac97_bus snd_pcm snd_timer snd soundcore snd_page_alloc r8169

Common factor is they're running slackware-11.0, but they both ran fairly 
recent -git11 or so.
- - -

Machine that compiled and booted 27-rc1 running slackware 12.1 with:
Linux pooh 2.6.27-rc1a #1 SMP Wed Jul 30 17:37:16 EST 2008 i686 Intel(R) Core(TM)2 CPU          6400  @ 2.13GHz GenuineIntel GNU/Linux

Gnu C                  4.2.3
Gnu make               3.81
binutils               2.17.50.0.17.20070615
util-linux             2.13.1
mount                  2.13.1
module-init-tools      3.4
e2fsprogs              1.41.0
reiserfsprogs          3.6.19
Linux C Library        2.7
Dynamic linker (ldd)   2.7
Linux C++ Library      6.0.9
Procps                 3.2.7
Net-tools              1.60
Kbd                    1.12
oprofile               0.9.2
Sh-utils               6.9
udev                   118
Modules Loaded         fuse sg

Grant.

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Linux v2.6.27-rc1
  2008-07-29 21:59     ` Sam Ravnborg
@ 2008-07-29 22:03       ` Linus Torvalds
  2008-07-29 22:30         ` Sam Ravnborg
  0 siblings, 1 reply; 42+ messages in thread
From: Linus Torvalds @ 2008-07-29 22:03 UTC (permalink / raw)
  To: Sam Ravnborg; +Cc: Linux Kernel Mailing List



On Tue, 29 Jul 2008, Sam Ravnborg wrote:
> 
> For arm the actual diff is:
>  Makefile                 |   20 +++++++-------------
>  boot/compressed/Makefile |    3 ---
>  tools/Makefile           |    1 +
>  3 files changed, 8 insertions(+), 16 deletions(-)
> 
> But on top of this there are ~600 files that needed a
> replacement of:
> #include <asm/arch/foo.h>
> to
> #include <arch/foo.h>

Yeah, that latter part doesn't strike me as wonderful.

> So maybe not such a minimal patch - because I wanted to drop all
> the symlink stuff.

Why? There's nothing wrong with symlinks.

The problem with 'include/asm' isn't the symlink per se, it's that it 
split up the architecture parts in two separate areas - arch and include.

			Linus

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Linux v2.6.27-rc1: problem with firmware stuff
  2008-07-29 21:01     ` Linus Torvalds
@ 2008-07-29 22:26       ` David Woodhouse
  0 siblings, 0 replies; 42+ messages in thread
From: David Woodhouse @ 2008-07-29 22:26 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Andrew Morton

On Tue, 2008-07-29 at 14:01 -0700, Linus Torvalds wrote:
> 
> On Tue, 29 Jul 2008, Rafael J. Wysocki wrote:
> > 
> > Actually, this happened due to some firmware files being created as root during
> > installations of pre-rc -git kernels from the O= directory.  So, not a real
> > problem, but somewhat confusing.
> 
> Yeah, I've had that happen myself. It used to be that "make 
> modules_install" (as root, obviously) would try build a new version of the 
> kernel, and as a result subsequent build attempts would fail horribly 
> because of various random files being now owned-by-root.
> 
> I don't know if there is a whole lot we can do about it in general..

Not in general. I _think_ I fixed the specific problem which led to
Rafael's situation, but I'm still waiting for confirmation of that.

-- 
dwmw2


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Linux v2.6.27-rc1
  2008-07-29 22:03       ` Linus Torvalds
@ 2008-07-29 22:30         ` Sam Ravnborg
  0 siblings, 0 replies; 42+ messages in thread
From: Sam Ravnborg @ 2008-07-29 22:30 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List

On Tue, Jul 29, 2008 at 03:03:47PM -0700, Linus Torvalds wrote:
> 
> 
> On Tue, 29 Jul 2008, Sam Ravnborg wrote:
> > 
> > For arm the actual diff is:
> >  Makefile                 |   20 +++++++-------------
> >  boot/compressed/Makefile |    3 ---
> >  tools/Makefile           |    1 +
> >  3 files changed, 8 insertions(+), 16 deletions(-)
> > 
> > But on top of this there are ~600 files that needed a
> > replacement of:
> > #include <asm/arch/foo.h>
> > to
> > #include <arch/foo.h>
> 
> Yeah, that latter part doesn't strike me as wonderful.
> 
> > So maybe not such a minimal patch - because I wanted to drop all
> > the symlink stuff.
> 
> Why? There's nothing wrong with symlinks.
> 
> The problem with 'include/asm' isn't the symlink per se, it's that it 
> split up the architecture parts in two separate areas - arch and include.

I agree that we do this to combine all arch files. But we then have the
possibility to get rid of some build stuff that is fragile and needs
special care for O=.. builds etc.
So when we anyway do the renames I saw the opportunity to go one step
further.
Lets see how the x86 + um stuff looks like.

For x86 alone the patchs looks like this:

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index f5631da..c7493e7 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -110,16 +110,16 @@ KBUILD_CFLAGS += $(call cc-option,-mno-sse -mno-mmx -mno-sse2 -mno-3dnow,)
 mcore-y  := arch/x86/mach-default/
 
 # Voyager subarch support
-mflags-$(CONFIG_X86_VOYAGER)	:= -Iinclude/asm-x86/mach-voyager
+mflags-$(CONFIG_X86_VOYAGER)	:= -Iarch/x86/include/mach-voyager
 mcore-$(CONFIG_X86_VOYAGER)	:= arch/x86/mach-voyager/
 
 # generic subarchitecture
-mflags-$(CONFIG_X86_GENERICARCH):= -Iinclude/asm-x86/mach-generic
+mflags-$(CONFIG_X86_GENERICARCH):= -Iarch/x86/include/mach-generic
 fcore-$(CONFIG_X86_GENERICARCH)	+= arch/x86/mach-generic/
 mcore-$(CONFIG_X86_GENERICARCH)	:= arch/x86/mach-default/
 
 # default subarch .h files
-mflags-y += -Iinclude/asm-x86/mach-default
+mflags-y += -Iarch/x86/include/mach-default
 
 # 64 bit does not support subarch support - clear sub arch variables
 fcore-$(CONFIG_X86_64)  :=

And the script to move the files looks like this:
set -e
for D in include/asm-x86/mach-*; do
	echo $D
	DD=$(echo $D | cut -d '-' -f 3)
        mkdir -p arch/x86/include/mach-$DD/arch
        git mv include/asm-x86/mach-$DD/* arch/x86/include/mach-$DD
        rmdir include/asm-x86/mach-$DD
done

mkdir -p arch/x86/include/asm
git mv include/asm-x86/* arch/x86/include/asm

But I have not yet looked at um.

	Sam

^ permalink raw reply related	[flat|nested] 42+ messages in thread

* Re: Linux v2.6.27-rc1: fails to compile
  2008-07-29 22:03 ` Linux v2.6.27-rc1: fails to compile Grant Coady
@ 2008-07-29 22:40   ` Frederik Deweerdt
  2008-07-29 23:46     ` Grant Coady
  0 siblings, 1 reply; 42+ messages in thread
From: Frederik Deweerdt @ 2008-07-29 22:40 UTC (permalink / raw)
  To: Grant Coady; +Cc: Linux Kernel Mailing List

Hello Grant,
On Wed, Jul 30, 2008 at 08:03:42AM +1000, Grant Coady wrote:
> On Mon, 28 Jul 2008 20:23:21 -0700 (PDT), Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> >
> >It's two weeks (and one day), and the merge window is over.
> >
> >Finally. I don't know why, but this one really did feel pretty dang busy. 
> >And the size of the -rc1 patch bears that out - at 12MB, it's about 50% 
> >bigger than 26-rc1 (but not that much bigger than 24/25-rc1, so it's not 
> >like it's anything unheard of).
> 
> Couple machines failed to compile with same error in different place:
> 
>   CC      arch/x86/kernel/acpi/cstate.o
> arch/x86/kernel/acpi/cstate.c: In function `acpi_processor_ffh_cstate_probe':
> arch/x86/kernel/acpi/cstate.c:94: error: invalid lvalue in unary `&'
> make[2]: *** [arch/x86/kernel/acpi/cstate.o] Error 1
> make[1]: *** [arch/x86/kernel/acpi] Error 2
> make: *** [arch/x86/kernel] Error 2
> grant@peetoo:~/linux/linux-2.6.27-rc1a$
> 
This issue has been reported, this is due to your old compiler.
Fix here:
http://lkml.org/lkml/2008/7/29/48

Regards,
Frederik

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Linux v2.6.27-rc1: fails to compile
  2008-07-29 22:40   ` Frederik Deweerdt
@ 2008-07-29 23:46     ` Grant Coady
  0 siblings, 0 replies; 42+ messages in thread
From: Grant Coady @ 2008-07-29 23:46 UTC (permalink / raw)
  To: Frederik Deweerdt; +Cc: Grant Coady, Linux Kernel Mailing List

On Wed, 30 Jul 2008 00:40:49 +0200, Frederik Deweerdt <deweerdt@free.fr> wrote:

>Hello Grant,
>On Wed, Jul 30, 2008 at 08:03:42AM +1000, Grant Coady wrote:
>> On Mon, 28 Jul 2008 20:23:21 -0700 (PDT), Linus Torvalds <torvalds@linux-foundation.org> wrote:
>> 
>> >
>> >It's two weeks (and one day), and the merge window is over.
>> >
>> >Finally. I don't know why, but this one really did feel pretty dang busy. 
>> >And the size of the -rc1 patch bears that out - at 12MB, it's about 50% 
>> >bigger than 26-rc1 (but not that much bigger than 24/25-rc1, so it's not 
>> >like it's anything unheard of).
>> 
>> Couple machines failed to compile with same error in different place:
>> 
>>   CC      arch/x86/kernel/acpi/cstate.o
>> arch/x86/kernel/acpi/cstate.c: In function `acpi_processor_ffh_cstate_probe':
>> arch/x86/kernel/acpi/cstate.c:94: error: invalid lvalue in unary `&'
>> make[2]: *** [arch/x86/kernel/acpi/cstate.o] Error 1
>> make[1]: *** [arch/x86/kernel/acpi] Error 2
>> make: *** [arch/x86/kernel] Error 2
>> grant@peetoo:~/linux/linux-2.6.27-rc1a$
>> 
>This issue has been reported, this is due to your old compiler.
>Fix here:
>http://lkml.org/lkml/2008/7/29/48

Thanks, that does the trick :)

Grant.
>
>Regards,
>Frederik


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: 2.6.27-rc1: zd1211rw association fails
  2008-07-29 17:52           ` John W. Linville
@ 2008-07-30  4:48             ` David Miller
  0 siblings, 0 replies; 42+ messages in thread
From: David Miller @ 2008-07-30  4:48 UTC (permalink / raw)
  To: linville
  Cc: johannes, tytso, alistair, torvalds, linux-kernel, dsd, kune,
	linux-wireless

From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 29 Jul 2008 13:52:06 -0400

> On Tue, Jul 29, 2008 at 02:15:06PM +0200, Johannes Berg wrote:
> > 
> > > > Yeah, it's really too bad -rc1 got released just before you were able
> > > > to post the fix to this, since if there were 100 million people who
> > > > were trying out kernels starting with -git7 that use wireless, there
> > > > will probably be 200 million people trying out -rc1.  :-)
> > > > 
> > > > Thanks for finding and fixing it, though.  I stopped trying out
> > > > kernels after -git6 since I was travelling at OSCON, and not having
> > > > wireless was a show-stopper for me....
> > > 
> > > If everybody's going to decide now to hit on _me_, I'll point out that
> > > davem's MQ TX changes broke it
> > 
> > Of course that's not strictly true, it had been broken forever, it just
> > happened to never show up before. And I mean forever, the original
> > devicescape code that got in was already broken.
> 
> FWIW, I think the MQ stuff didn't spend much (or any) time in -next...

It did in a few formats, but then Patrick McHardy pointed out something
that required my rewriting large swaths of it in the days leading up to
the merge window.

And the problem this showed up was a bug that existed in mac80211 long
before I made any TX multiqueue changes :-)

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Linux v2.6.27-rc1
  2008-07-29 16:59   ` Linus Torvalds
  2008-07-29 17:31     ` Roland Dreier
@ 2008-07-30  9:03     ` Andrew Morton
  2008-07-31 22:22       ` Linux v2.6.27-rc1: linux-next Rafael J. Wysocki
  1 sibling, 1 reply; 42+ messages in thread
From: Andrew Morton @ 2008-07-30  9:03 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Jesse Barnes, Linux Kernel Mailing List, Stephen Rothwell

On Tue, 29 Jul 2008 09:59:18 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:

>  - I don't think the 'next' thing works as well for the occasional 
>    developer that just has a few patches pending as it works for subsystem 
>    maintainers that are used to it.

Those people's patches are in -mm, which now holds maybe 100 or more
"trees", many of which are small or empty.

My project within the next couple of weeks is to get most of that
material into linux-next.  Stephen will be involved ;)

>    IOW, I think 'next' needs enough infrastructure setup from the 
>    developer side that I don't think it's reasonable for _everything_ to 
>    go through next.

True.  But

a) some of the problematic changes which we've seen simply _should_
   have been in linux-next.  Some of them were even coming from
   developers whose trees are already in linux-next.

b) A lot of the bugs which hit your tree would have been quickly
   found in linux-next too.


But it's all shuffling deckchairs, really.  Are we actually merging
better code as a reasult of all of this?  Are we being more careful and
reviewing better and testing better?

Don't think so.

> And that in turn means that I'm not entirely thrilled 
>    when people then complain "that wasn't in next". I think people should 
>    accept that not everything will be in next.

Oh sure.  But it depends on the _reason_ why it wasn't in linux-next. 
If the reason is a good one then fine.  But if the reason is "I was too
slack", or "I only wrote it five minutes ago" then the system is good,
and the developer isn't.


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Oops in microcode sysfs registration,
  2008-07-29 16:50     ` Alistair John Strachan
@ 2008-07-30  9:07       ` Dmitry Adamushko
  2008-07-30 10:35         ` Dmitry Adamushko
  0 siblings, 1 reply; 42+ messages in thread
From: Dmitry Adamushko @ 2008-07-30  9:07 UTC (permalink / raw)
  To: Alistair John Strachan
  Cc: Pekka Paalanen, Linus Torvalds, Linux Kernel Mailing List,
	shaohua.li, tigran, Ingo Molnar, Thomas Gleixner, Steven Rostedt,
	Max Krasnyansky

2008/7/29 Alistair John Strachan <alistair@devzero.co.uk>:
> On Tuesday 29 July 2008 17:22:14 Pekka Paalanen wrote:
>> > Also, I'm sure this is reproducible without the NVIDIA garbage, but I was
>> > too lazy to test it. If you want me to repeat the experiment without the
>> > driver I would be more than happy to do so.
>>
>> I'm not sure people are willing to look into this without a clean report,
>> so this would be cool. There's even a test module for mmiotrace in the
>> kernel, but I doubt it would make difference to use it or not, when trying
>> to reproduce the crash without the blob.
>
> Of course, and I should have attempted to reproduce without the driver.
> Fortunately that was easy: it is not an NVIDIA driver bug.
>
> Steps to reproduce: have CONFIG_MICROCODE=y and a suitable Intel
> processor, then do:
>
> echo mmiotrace >/debug/tracing/current_tracer
> echo none >/debug/tracing/current_tracer
>
> And you get this (snipped) oops:
>
> in mmio_trace_init
> mmiotrace: Disabling non-boot CPUs...
> kvm: disabling virtualization on CPU1
> CPU 1 is now offline
> SMP alternatives: switching to UP code
> CPU0 attaching NULL sched-domain.
> CPU1 attaching NULL sched-domain.
> CPU0 attaching NULL sched-domain.
> mmiotrace: CPU1 is down.
> mmiotrace: enabled.
> in mmio_trace_reset
> mmiotrace: Re-enabling CPUs...
> SMP alternatives: switching to SMP code
> Booting processor 1/1 ip 6000
> Initializing CPU#1
> Calibrating delay using timer specific routine.. <6>7204.76 BogoMIPS (lpj=3602381)
> CPU: L1 I cache: 32K, L1 D cache: 32K
> CPU: L2 cache: 4096K
> CPU: Physical Processor ID: 0
> CPU: Processor Core ID: 1
> x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
> CPU1: Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz stepping 06
> checking TSC synchronization [CPU#0 -> CPU#1]: passed.
> kvm: enabling virtualization on CPU1
> CPU0 attaching NULL sched-domain.
> Switched to high resolution mode on CPU 1
> CPU0 attaching sched-domain:
>  domain 0: span 0-1 level MC
>  groups: 0 1
> CPU1 attaching sched-domain:
>  domain 0: span 0-1 level MC
>  groups: 1 0
> ------------[ cut here ]------------
> Kernel BUG at ffffffff8021a31d [verbose debug info unavailable]
> invalid opcode: 0000 [1] PREEMPT SMP
> CPU 0
> Modules linked in: rfcomm l2cap kvm_intel kvm ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack ip_tables x_tables bridge stp llc acpi_cpufreq freq_table coretemp hwmon
> snd_pcm_oss snd_mixer_oss firewire_sbp2 hci_usb bluetooth arc4 ecb crypto_blkcipher cryptomgr crypto_algapi usbhid zd1211rw mac80211 crypto cfg80211 snd_emu10k1 snd_rawmidi
> snd_ac97_codec ac97_bus sg snd_seq_device snd_hda_intel snd_pcm snd_util_mem snd_timer sr_mod snd_hwdep i2c_i801 ehci_hcd firewire_ohci uhci_hcd snd snd_page_alloc firewire_core
> soundcore r8169 cdrom usbcore i2c_core crc_itu_t
> Pid: 2757, comm: bash Tainted: G       A  2.6.27-rc1-damocles #3
> RIP: 0010:[<ffffffff8021a31d>]  [<ffffffff8021a31d>] __mc_sysdev_add+0xc3/0x1f1
> RSP: 0018:ffff8800b8905ce8  EFLAGS: 00010297
> RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff880080a04000
> RDX: ffffffff8062c680 RSI: 0000000000000003 RDI: ffffffff8059e830
> RBP: ffff8800b8905d48 R08: ffff8800b8904000 R09: ffffffff80229ca4
> R10: ffff8800010247b0 R11: ffff8800bf879de0 R12: 0000000000000018
> R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000
> FS:  00007f8ddc78f6e0(0000) GS:ffffffff805da200(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 00007f57cb9b2098 CR3: 00000000b8985000 CR4: 00000000000026e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process bash (pid: 2757, threadinfo ffff8800b8904000, task ffff8800bd125640)
> Stack:  ffffffff80627040 0000000000000000 0000000000000008 ffffffff8048bb28
>  0000000000000003 ffffffff802ce910 ffff8800b8905d28 0000000000000002
>  00000000ffffffe8 0000000000000001 0000000000000001 ffff880001028418
> Call Trace:
>  [<ffffffff802ce910>] ? sysfs_add_file+0xc/0xe
>  [<ffffffff8021a456>] mc_sysdev_add+0xb/0xd
>  [<ffffffff8047baaf>] mc_cpu_callback+0x4b/0x208
>  [<ffffffff8047b772>] ? mce_cpu_callback+0x3e/0xbc
>  [<ffffffff8024b787>] notifier_call_chain+0x33/0x5b
>  [<ffffffff8024b81f>] raw_notifier_call_chain+0xf/0x11
>  [<ffffffff8047e1dc>] _cpu_up+0xce/0x119
>  [<ffffffff8047e285>] cpu_up+0x5e/0x8a
>  [<ffffffff80224967>] disable_mmiotrace+0xfe/0x173
>  [<ffffffff80265279>] mmio_trace_reset+0x2d/0x44
>  [<ffffffff80262c4d>] tracing_set_trace_write+0xd3/0x10f
>  [<ffffffff80289cab>] ? filp_close+0x67/0x72
>  [<ffffffff8028bee3>] vfs_write+0xa7/0xe1
>  [<ffffffff8028bfe1>] sys_write+0x47/0x6f
>  [<ffffffff8020b6db>] system_call_fastpath+0x16/0x1b
> [   68.405002]
> [   68.405002]
> Code: e8 59 80 e8 fd 69 26 00 48 c7 c2 80 c6 62 80 48 8b 05 c0 00 3c 00 48 8b 04 d8 48 8b 48 08 65 8b 04 25 24 00 00 00 44 39 e8 74 04 <0f> 0b eb fe 4c 8d 04 0a 41 c7 84 24 7c 36 64 80 00
> 00 00 00 41
> RIP  [<ffffffff8021a31d>] __mc_sysdev_add+0xc3/0x1f1
>  RSP <ffff8800b8905ce8>
> ---[ end trace ee9c9240024cb48c ]---
>
> I've replaced the originally tainted dmesg with this new clean one, so
> there's no proprietary smell about it :-)

Yes, it's kind of a known issue. Take a look at this explanation:
http://lkml.org/lkml/2008/7/24/260

There were a few related discussions in other threads (mainly, Max
Krasnyansky and I were asking for additional info on possible
requirements from the 'microcode' driver...) heh, I think, we'd be
better off just fixing it one way or another.



-- 
Best regards,
Dmitry Adamushko

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Oops in microcode sysfs registration,
  2008-07-30  9:07       ` Dmitry Adamushko
@ 2008-07-30 10:35         ` Dmitry Adamushko
  2008-07-30 13:28           ` Peter Oruba
                             ` (2 more replies)
  0 siblings, 3 replies; 42+ messages in thread
From: Dmitry Adamushko @ 2008-07-30 10:35 UTC (permalink / raw)
  To: Alistair John Strachan
  Cc: Pekka Paalanen, Linus Torvalds, Linux Kernel Mailing List,
	shaohua.li, tigran, Ingo Molnar, Thomas Gleixner, Steven Rostedt,
	Max Krasnyansky

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

2008/7/30 Dmitry Adamushko <dmitry.adamushko@gmail.com>:
> 2008/7/29 Alistair John Strachan <alistair@devzero.co.uk>:
>> On Tuesday 29 July 2008 17:22:14 Pekka Paalanen wrote:
>>> > Also, I'm sure this is reproducible without the NVIDIA garbage, but I was
>>> > too lazy to test it. If you want me to repeat the experiment without the
>>> > driver I would be more than happy to do so.
>>>
>>> I'm not sure people are willing to look into this without a clean report,
>>> so this would be cool. There's even a test module for mmiotrace in the
>>> kernel, but I doubt it would make difference to use it or not, when trying
>>> to reproduce the crash without the blob.
>>
>> Of course, and I should have attempted to reproduce without the driver.
>> Fortunately that was easy: it is not an NVIDIA driver bug.
>>
>> Steps to reproduce: have CONFIG_MICROCODE=y and a suitable Intel
>> processor, then do:
>>
>> echo mmiotrace >/debug/tracing/current_tracer
>> echo none >/debug/tracing/current_tracer
>>
>> And you get this (snipped) oops:
>>
>> in mmio_trace_init
>> mmiotrace: Disabling non-boot CPUs...
>> kvm: disabling virtualization on CPU1
>> CPU 1 is now offline
>> SMP alternatives: switching to UP code
>> CPU0 attaching NULL sched-domain.
>> CPU1 attaching NULL sched-domain.
>> CPU0 attaching NULL sched-domain.
>> mmiotrace: CPU1 is down.
>> mmiotrace: enabled.
>> in mmio_trace_reset
>> mmiotrace: Re-enabling CPUs...
>> SMP alternatives: switching to SMP code
>> Booting processor 1/1 ip 6000
>> Initializing CPU#1
>> Calibrating delay using timer specific routine.. <6>7204.76 BogoMIPS (lpj=3602381)
>> CPU: L1 I cache: 32K, L1 D cache: 32K
>> CPU: L2 cache: 4096K
>> CPU: Physical Processor ID: 0
>> CPU: Processor Core ID: 1
>> x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
>> CPU1: Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz stepping 06
>> checking TSC synchronization [CPU#0 -> CPU#1]: passed.
>> kvm: enabling virtualization on CPU1
>> CPU0 attaching NULL sched-domain.
>> Switched to high resolution mode on CPU 1
>> CPU0 attaching sched-domain:
>>  domain 0: span 0-1 level MC
>>  groups: 0 1
>> CPU1 attaching sched-domain:
>>  domain 0: span 0-1 level MC
>>  groups: 1 0
>> ------------[ cut here ]------------
>> Kernel BUG at ffffffff8021a31d [verbose debug info unavailable]
>> invalid opcode: 0000 [1] PREEMPT SMP
>> CPU 0
>> Modules linked in: rfcomm l2cap kvm_intel kvm ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack ip_tables x_tables bridge stp llc acpi_cpufreq freq_table coretemp hwmon
>> snd_pcm_oss snd_mixer_oss firewire_sbp2 hci_usb bluetooth arc4 ecb crypto_blkcipher cryptomgr crypto_algapi usbhid zd1211rw mac80211 crypto cfg80211 snd_emu10k1 snd_rawmidi
>> snd_ac97_codec ac97_bus sg snd_seq_device snd_hda_intel snd_pcm snd_util_mem snd_timer sr_mod snd_hwdep i2c_i801 ehci_hcd firewire_ohci uhci_hcd snd snd_page_alloc firewire_core
>> soundcore r8169 cdrom usbcore i2c_core crc_itu_t
>> Pid: 2757, comm: bash Tainted: G       A  2.6.27-rc1-damocles #3
>> RIP: 0010:[<ffffffff8021a31d>]  [<ffffffff8021a31d>] __mc_sysdev_add+0xc3/0x1f1
>> RSP: 0018:ffff8800b8905ce8  EFLAGS: 00010297
>> RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff880080a04000
>> RDX: ffffffff8062c680 RSI: 0000000000000003 RDI: ffffffff8059e830
>> RBP: ffff8800b8905d48 R08: ffff8800b8904000 R09: ffffffff80229ca4
>> R10: ffff8800010247b0 R11: ffff8800bf879de0 R12: 0000000000000018
>> R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000
>> FS:  00007f8ddc78f6e0(0000) GS:ffffffff805da200(0000) knlGS:0000000000000000
>> CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>> CR2: 00007f57cb9b2098 CR3: 00000000b8985000 CR4: 00000000000026e0
>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> Process bash (pid: 2757, threadinfo ffff8800b8904000, task ffff8800bd125640)
>> Stack:  ffffffff80627040 0000000000000000 0000000000000008 ffffffff8048bb28
>>  0000000000000003 ffffffff802ce910 ffff8800b8905d28 0000000000000002
>>  00000000ffffffe8 0000000000000001 0000000000000001 ffff880001028418
>> Call Trace:
>>  [<ffffffff802ce910>] ? sysfs_add_file+0xc/0xe
>>  [<ffffffff8021a456>] mc_sysdev_add+0xb/0xd
>>  [<ffffffff8047baaf>] mc_cpu_callback+0x4b/0x208
>>  [<ffffffff8047b772>] ? mce_cpu_callback+0x3e/0xbc
>>  [<ffffffff8024b787>] notifier_call_chain+0x33/0x5b
>>  [<ffffffff8024b81f>] raw_notifier_call_chain+0xf/0x11
>>  [<ffffffff8047e1dc>] _cpu_up+0xce/0x119
>>  [<ffffffff8047e285>] cpu_up+0x5e/0x8a
>>  [<ffffffff80224967>] disable_mmiotrace+0xfe/0x173
>>  [<ffffffff80265279>] mmio_trace_reset+0x2d/0x44
>>  [<ffffffff80262c4d>] tracing_set_trace_write+0xd3/0x10f
>>  [<ffffffff80289cab>] ? filp_close+0x67/0x72
>>  [<ffffffff8028bee3>] vfs_write+0xa7/0xe1
>>  [<ffffffff8028bfe1>] sys_write+0x47/0x6f
>>  [<ffffffff8020b6db>] system_call_fastpath+0x16/0x1b
>> [   68.405002]
>> [   68.405002]
>> Code: e8 59 80 e8 fd 69 26 00 48 c7 c2 80 c6 62 80 48 8b 05 c0 00 3c 00 48 8b 04 d8 48 8b 48 08 65 8b 04 25 24 00 00 00 44 39 e8 74 04 <0f> 0b eb fe 4c 8d 04 0a 41 c7 84 24 7c 36 64 80 00
>> 00 00 00 41
>> RIP  [<ffffffff8021a31d>] __mc_sysdev_add+0xc3/0x1f1
>>  RSP <ffff8800b8905ce8>
>> ---[ end trace ee9c9240024cb48c ]---
>>
>> I've replaced the originally tainted dmesg with this new clean one, so
>> there's no proprietary smell about it :-)
>
> Yes, it's kind of a known issue. Take a look at this explanation:
> http://lkml.org/lkml/2008/7/24/260
>
> There were a few related discussions in other threads (mainly, Max
> Krasnyansky and I were asking for additional info on possible
> requirements from the 'microcode' driver...) heh, I think, we'd be
> better off just fixing it one way or another.

does a patch below fix it for you?
[ not really what we wanted ]

(non-white-space-damaged version is enclosed)
--- kernel/cpu.c-old    2008-07-30 12:31:15.000000000 +0200
+++ kernel/cpu.c        2008-07-30 12:32:02.000000000 +0200
@@ -349,6 +349,8 @@ static int __cpuinit _cpu_up(unsigned in
                goto out_notify;
        BUG_ON(!cpu_online(cpu));

+       cpu_set(cpu, cpu_active_map);
+
        /* Now call notifier in preparation. */
        raw_notifier_call_chain(&cpu_chain, CPU_ONLINE | mod, hcpu);

@@ -383,9 +385,6 @@ int __cpuinit cpu_up(unsigned int cpu)

        err = _cpu_up(cpu, 0);

-       if (cpu_online(cpu))
-               cpu_set(cpu, cpu_active_map);
-
 out:
        cpu_maps_update_done();
        return err;


-- 
Best regards,
Dmitry Adamushko

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: move-cpu_set-cpu_active_map.patch --]
[-- Type: text/x-patch; name=move-cpu_set-cpu_active_map.patch, Size: 554 bytes --]

--- kernel/cpu.c-old	2008-07-30 12:31:15.000000000 +0200
+++ kernel/cpu.c	2008-07-30 12:32:02.000000000 +0200
@@ -349,6 +349,8 @@ static int __cpuinit _cpu_up(unsigned in
 		goto out_notify;
 	BUG_ON(!cpu_online(cpu));
 
+	cpu_set(cpu, cpu_active_map);
+
 	/* Now call notifier in preparation. */
 	raw_notifier_call_chain(&cpu_chain, CPU_ONLINE | mod, hcpu);
 
@@ -383,9 +385,6 @@ int __cpuinit cpu_up(unsigned int cpu)
 
 	err = _cpu_up(cpu, 0);
 
-	if (cpu_online(cpu))
-		cpu_set(cpu, cpu_active_map);
-
 out:
 	cpu_maps_update_done();
 	return err;

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Oops in microcode sysfs registration,
  2008-07-30 10:35         ` Dmitry Adamushko
@ 2008-07-30 13:28           ` Peter Oruba
  2008-07-31 12:49           ` Alistair John Strachan
  2008-07-31 16:56           ` Ingo Molnar
  2 siblings, 0 replies; 42+ messages in thread
From: Peter Oruba @ 2008-07-30 13:28 UTC (permalink / raw)
  To: Dmitry Adamushko
  Cc: Alistair John Strachan, Pekka Paalanen, Linus Torvalds,
	Linux Kernel Mailing List, shaohua.li, tigran, Ingo Molnar,
	Thomas Gleixner, Steven Rostedt, Max Krasnyansky


Dmitry Adamushko schrieb:
> 2008/7/30 Dmitry Adamushko <dmitry.adamushko@gmail.com>:
>> 2008/7/29 Alistair John Strachan <alistair@devzero.co.uk>:
>>> On Tuesday 29 July 2008 17:22:14 Pekka Paalanen wrote:
>>>>> Also, I'm sure this is reproducible without the NVIDIA garbage, but I was
>>>>> too lazy to test it. If you want me to repeat the experiment without the
>>>>> driver I would be more than happy to do so.
>>>> I'm not sure people are willing to look into this without a clean report,
>>>> so this would be cool. There's even a test module for mmiotrace in the
>>>> kernel, but I doubt it would make difference to use it or not, when trying
>>>> to reproduce the crash without the blob.
>>> Of course, and I should have attempted to reproduce without the driver.
>>> Fortunately that was easy: it is not an NVIDIA driver bug.
>>>
>>> Steps to reproduce: have CONFIG_MICROCODE=y and a suitable Intel
>>> processor, then do:
>>>
>>> echo mmiotrace >/debug/tracing/current_tracer
>>> echo none >/debug/tracing/current_tracer
>>>
>>> And you get this (snipped) oops:
>>>
>>> in mmio_trace_init
>>> mmiotrace: Disabling non-boot CPUs...
>>> kvm: disabling virtualization on CPU1
>>> CPU 1 is now offline
>>> SMP alternatives: switching to UP code
>>> CPU0 attaching NULL sched-domain.
>>> CPU1 attaching NULL sched-domain.
>>> CPU0 attaching NULL sched-domain.
>>> mmiotrace: CPU1 is down.
>>> mmiotrace: enabled.
>>> in mmio_trace_reset
>>> mmiotrace: Re-enabling CPUs...
>>> SMP alternatives: switching to SMP code
>>> Booting processor 1/1 ip 6000
>>> Initializing CPU#1
>>> Calibrating delay using timer specific routine.. <6>7204.76 BogoMIPS (lpj=3602381)
>>> CPU: L1 I cache: 32K, L1 D cache: 32K
>>> CPU: L2 cache: 4096K
>>> CPU: Physical Processor ID: 0
>>> CPU: Processor Core ID: 1
>>> x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
>>> CPU1: Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz stepping 06
>>> checking TSC synchronization [CPU#0 -> CPU#1]: passed.
>>> kvm: enabling virtualization on CPU1
>>> CPU0 attaching NULL sched-domain.
>>> Switched to high resolution mode on CPU 1
>>> CPU0 attaching sched-domain:
>>>  domain 0: span 0-1 level MC
>>>  groups: 0 1
>>> CPU1 attaching sched-domain:
>>>  domain 0: span 0-1 level MC
>>>  groups: 1 0
>>> ------------[ cut here ]------------
>>> Kernel BUG at ffffffff8021a31d [verbose debug info unavailable]
>>> invalid opcode: 0000 [1] PREEMPT SMP
>>> CPU 0
>>> Modules linked in: rfcomm l2cap kvm_intel kvm ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack ip_tables x_tables bridge stp llc acpi_cpufreq freq_table coretemp hwmon
>>> snd_pcm_oss snd_mixer_oss firewire_sbp2 hci_usb bluetooth arc4 ecb crypto_blkcipher cryptomgr crypto_algapi usbhid zd1211rw mac80211 crypto cfg80211 snd_emu10k1 snd_rawmidi
>>> snd_ac97_codec ac97_bus sg snd_seq_device snd_hda_intel snd_pcm snd_util_mem snd_timer sr_mod snd_hwdep i2c_i801 ehci_hcd firewire_ohci uhci_hcd snd snd_page_alloc firewire_core
>>> soundcore r8169 cdrom usbcore i2c_core crc_itu_t
>>> Pid: 2757, comm: bash Tainted: G       A  2.6.27-rc1-damocles #3
>>> RIP: 0010:[<ffffffff8021a31d>]  [<ffffffff8021a31d>] __mc_sysdev_add+0xc3/0x1f1
>>> RSP: 0018:ffff8800b8905ce8  EFLAGS: 00010297
>>> RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff880080a04000
>>> RDX: ffffffff8062c680 RSI: 0000000000000003 RDI: ffffffff8059e830
>>> RBP: ffff8800b8905d48 R08: ffff8800b8904000 R09: ffffffff80229ca4
>>> R10: ffff8800010247b0 R11: ffff8800bf879de0 R12: 0000000000000018
>>> R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000
>>> FS:  00007f8ddc78f6e0(0000) GS:ffffffff805da200(0000) knlGS:0000000000000000
>>> CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>>> CR2: 00007f57cb9b2098 CR3: 00000000b8985000 CR4: 00000000000026e0
>>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>>> Process bash (pid: 2757, threadinfo ffff8800b8904000, task ffff8800bd125640)
>>> Stack:  ffffffff80627040 0000000000000000 0000000000000008 ffffffff8048bb28
>>>  0000000000000003 ffffffff802ce910 ffff8800b8905d28 0000000000000002
>>>  00000000ffffffe8 0000000000000001 0000000000000001 ffff880001028418
>>> Call Trace:
>>>  [<ffffffff802ce910>] ? sysfs_add_file+0xc/0xe
>>>  [<ffffffff8021a456>] mc_sysdev_add+0xb/0xd
>>>  [<ffffffff8047baaf>] mc_cpu_callback+0x4b/0x208
>>>  [<ffffffff8047b772>] ? mce_cpu_callback+0x3e/0xbc
>>>  [<ffffffff8024b787>] notifier_call_chain+0x33/0x5b
>>>  [<ffffffff8024b81f>] raw_notifier_call_chain+0xf/0x11
>>>  [<ffffffff8047e1dc>] _cpu_up+0xce/0x119
>>>  [<ffffffff8047e285>] cpu_up+0x5e/0x8a
>>>  [<ffffffff80224967>] disable_mmiotrace+0xfe/0x173
>>>  [<ffffffff80265279>] mmio_trace_reset+0x2d/0x44
>>>  [<ffffffff80262c4d>] tracing_set_trace_write+0xd3/0x10f
>>>  [<ffffffff80289cab>] ? filp_close+0x67/0x72
>>>  [<ffffffff8028bee3>] vfs_write+0xa7/0xe1
>>>  [<ffffffff8028bfe1>] sys_write+0x47/0x6f
>>>  [<ffffffff8020b6db>] system_call_fastpath+0x16/0x1b
>>> [   68.405002]
>>> [   68.405002]
>>> Code: e8 59 80 e8 fd 69 26 00 48 c7 c2 80 c6 62 80 48 8b 05 c0 00 3c 00 48 8b 04 d8 48 8b 48 08 65 8b 04 25 24 00 00 00 44 39 e8 74 04 <0f> 0b eb fe 4c 8d 04 0a 41 c7 84 24 7c 36 64 80 00
>>> 00 00 00 41
>>> RIP  [<ffffffff8021a31d>] __mc_sysdev_add+0xc3/0x1f1
>>>  RSP <ffff8800b8905ce8>
>>> ---[ end trace ee9c9240024cb48c ]---
>>>
>>> I've replaced the originally tainted dmesg with this new clean one, so
>>> there's no proprietary smell about it :-)
>> Yes, it's kind of a known issue. Take a look at this explanation:
>> http://lkml.org/lkml/2008/7/24/260
>>
>> There were a few related discussions in other threads (mainly, Max
>> Krasnyansky and I were asking for additional info on possible
>> requirements from the 'microcode' driver...) heh, I think, we'd be
>> better off just fixing it one way or another.
> 
> does a patch below fix it for you?
> [ not really what we wanted ]
> 
> (non-white-space-damaged version is enclosed)
> --- kernel/cpu.c-old    2008-07-30 12:31:15.000000000 +0200
> +++ kernel/cpu.c        2008-07-30 12:32:02.000000000 +0200
> @@ -349,6 +349,8 @@ static int __cpuinit _cpu_up(unsigned in
>                 goto out_notify;
>         BUG_ON(!cpu_online(cpu));
> 
> +       cpu_set(cpu, cpu_active_map);
> +
>         /* Now call notifier in preparation. */
>         raw_notifier_call_chain(&cpu_chain, CPU_ONLINE | mod, hcpu);
> 
> @@ -383,9 +385,6 @@ int __cpuinit cpu_up(unsigned int cpu)
> 
>         err = _cpu_up(cpu, 0);
> 
> -       if (cpu_online(cpu))
> -               cpu_set(cpu, cpu_active_map);
> -
>  out:
>         cpu_maps_update_done();
>         return err;
> 
> 
> 

Dmitry,

works for me...

Thanks,
Peter


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Oops in microcode sysfs registration,
  2008-07-30 10:35         ` Dmitry Adamushko
  2008-07-30 13:28           ` Peter Oruba
@ 2008-07-31 12:49           ` Alistair John Strachan
  2008-07-31 16:56           ` Ingo Molnar
  2 siblings, 0 replies; 42+ messages in thread
From: Alistair John Strachan @ 2008-07-31 12:49 UTC (permalink / raw)
  To: Dmitry Adamushko
  Cc: Pekka Paalanen, Linus Torvalds, Linux Kernel Mailing List,
	shaohua.li, tigran, Ingo Molnar, Thomas Gleixner, Steven Rostedt,
	Max Krasnyansky

On Wednesday 30 July 2008 11:35:54 Dmitry Adamushko wrote:
> 2008/7/30 Dmitry Adamushko <dmitry.adamushko@gmail.com>:
> > 2008/7/29 Alistair John Strachan <alistair@devzero.co.uk>:
> >> On Tuesday 29 July 2008 17:22:14 Pekka Paalanen wrote:
> >>> > Also, I'm sure this is reproducible without the NVIDIA garbage, but I
> >>> > was too lazy to test it. If you want me to repeat the experiment
> >>> > without the driver I would be more than happy to do so.
> >>>
> >>> I'm not sure people are willing to look into this without a clean
> >>> report, so this would be cool. There's even a test module for mmiotrace
> >>> in the kernel, but I doubt it would make difference to use it or not,
> >>> when trying to reproduce the crash without the blob.
> >>
> >> Of course, and I should have attempted to reproduce without the driver.
> >> Fortunately that was easy: it is not an NVIDIA driver bug.
> >>
> >> Steps to reproduce: have CONFIG_MICROCODE=y and a suitable Intel
> >> processor, then do:
> >>
> >> echo mmiotrace >/debug/tracing/current_tracer
> >> echo none >/debug/tracing/current_tracer
> >>
> >> And you get this (snipped) oops:
> >>
> >> in mmio_trace_init
> >> mmiotrace: Disabling non-boot CPUs...
> >> kvm: disabling virtualization on CPU1
> >> CPU 1 is now offline
> >> SMP alternatives: switching to UP code
> >> CPU0 attaching NULL sched-domain.
> >> CPU1 attaching NULL sched-domain.
> >> CPU0 attaching NULL sched-domain.
> >> mmiotrace: CPU1 is down.
> >> mmiotrace: enabled.
> >> in mmio_trace_reset
> >> mmiotrace: Re-enabling CPUs...
> >> SMP alternatives: switching to SMP code
> >> Booting processor 1/1 ip 6000
> >> Initializing CPU#1
> >> Calibrating delay using timer specific routine.. <6>7204.76 BogoMIPS
> >> (lpj=3602381) CPU: L1 I cache: 32K, L1 D cache: 32K
> >> CPU: L2 cache: 4096K
> >> CPU: Physical Processor ID: 0
> >> CPU: Processor Core ID: 1
> >> x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
> >> CPU1: Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz stepping 06
> >> checking TSC synchronization [CPU#0 -> CPU#1]: passed.
> >> kvm: enabling virtualization on CPU1
> >> CPU0 attaching NULL sched-domain.
> >> Switched to high resolution mode on CPU 1
> >> CPU0 attaching sched-domain:
> >>  domain 0: span 0-1 level MC
> >>  groups: 0 1
> >> CPU1 attaching sched-domain:
> >>  domain 0: span 0-1 level MC
> >>  groups: 1 0
> >> ------------[ cut here ]------------
> >> Kernel BUG at ffffffff8021a31d [verbose debug info unavailable]
> >> invalid opcode: 0000 [1] PREEMPT SMP
> >> CPU 0
> >> Modules linked in: rfcomm l2cap kvm_intel kvm ipt_MASQUERADE iptable_nat
> >> nf_nat nf_conntrack_ipv4 nf_conntrack ip_tables x_tables bridge stp llc
> >> acpi_cpufreq freq_table coretemp hwmon snd_pcm_oss snd_mixer_oss
> >> firewire_sbp2 hci_usb bluetooth arc4 ecb crypto_blkcipher cryptomgr
> >> crypto_algapi usbhid zd1211rw mac80211 crypto cfg80211 snd_emu10k1
> >> snd_rawmidi snd_ac97_codec ac97_bus sg snd_seq_device snd_hda_intel
> >> snd_pcm snd_util_mem snd_timer sr_mod snd_hwdep i2c_i801 ehci_hcd
> >> firewire_ohci uhci_hcd snd snd_page_alloc firewire_core soundcore r8169
> >> cdrom usbcore i2c_core crc_itu_t
> >> Pid: 2757, comm: bash Tainted: G       A  2.6.27-rc1-damocles #3
> >> RIP: 0010:[<ffffffff8021a31d>]  [<ffffffff8021a31d>]
> >> __mc_sysdev_add+0xc3/0x1f1 RSP: 0018:ffff8800b8905ce8  EFLAGS: 00010297
> >> RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff880080a04000
> >> RDX: ffffffff8062c680 RSI: 0000000000000003 RDI: ffffffff8059e830
> >> RBP: ffff8800b8905d48 R08: ffff8800b8904000 R09: ffffffff80229ca4
> >> R10: ffff8800010247b0 R11: ffff8800bf879de0 R12: 0000000000000018
> >> R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000
> >> FS:  00007f8ddc78f6e0(0000) GS:ffffffff805da200(0000)
> >> knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> >> CR2: 00007f57cb9b2098 CR3: 00000000b8985000 CR4: 00000000000026e0
> >> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> >> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> >> Process bash (pid: 2757, threadinfo ffff8800b8904000, task
> >> ffff8800bd125640) Stack:  ffffffff80627040 0000000000000000
> >> 0000000000000008 ffffffff8048bb28 0000000000000003 ffffffff802ce910
> >> ffff8800b8905d28 0000000000000002 00000000ffffffe8 0000000000000001
> >> 0000000000000001 ffff880001028418 Call Trace:
> >>  [<ffffffff802ce910>] ? sysfs_add_file+0xc/0xe
> >>  [<ffffffff8021a456>] mc_sysdev_add+0xb/0xd
> >>  [<ffffffff8047baaf>] mc_cpu_callback+0x4b/0x208
> >>  [<ffffffff8047b772>] ? mce_cpu_callback+0x3e/0xbc
> >>  [<ffffffff8024b787>] notifier_call_chain+0x33/0x5b
> >>  [<ffffffff8024b81f>] raw_notifier_call_chain+0xf/0x11
> >>  [<ffffffff8047e1dc>] _cpu_up+0xce/0x119
> >>  [<ffffffff8047e285>] cpu_up+0x5e/0x8a
> >>  [<ffffffff80224967>] disable_mmiotrace+0xfe/0x173
> >>  [<ffffffff80265279>] mmio_trace_reset+0x2d/0x44
> >>  [<ffffffff80262c4d>] tracing_set_trace_write+0xd3/0x10f
> >>  [<ffffffff80289cab>] ? filp_close+0x67/0x72
> >>  [<ffffffff8028bee3>] vfs_write+0xa7/0xe1
> >>  [<ffffffff8028bfe1>] sys_write+0x47/0x6f
> >>  [<ffffffff8020b6db>] system_call_fastpath+0x16/0x1b
> >> [   68.405002]
> >> [   68.405002]
> >> Code: e8 59 80 e8 fd 69 26 00 48 c7 c2 80 c6 62 80 48 8b 05 c0 00 3c 00
> >> 48 8b 04 d8 48 8b 48 08 65 8b 04 25 24 00 00 00 44 39 e8 74 04 <0f> 0b
> >> eb fe 4c 8d 04 0a 41 c7 84 24 7c 36 64 80 00 00 00 00 41
> >> RIP  [<ffffffff8021a31d>] __mc_sysdev_add+0xc3/0x1f1
> >>  RSP <ffff8800b8905ce8>
> >> ---[ end trace ee9c9240024cb48c ]---
> >>
> >> I've replaced the originally tainted dmesg with this new clean one, so
> >> there's no proprietary smell about it :-)
> >
> > Yes, it's kind of a known issue. Take a look at this explanation:
> > http://lkml.org/lkml/2008/7/24/260
> >
> > There were a few related discussions in other threads (mainly, Max
> > Krasnyansky and I were asking for additional info on possible
> > requirements from the 'microcode' driver...) heh, I think, we'd be
> > better off just fixing it one way or another.
>
> does a patch below fix it for you?

Well, if this patch is all that can be done about the issue, it gets my tested 
seal of approval. The CPUs online/offline properly without upsetting the mc 
driver. Thanks.

-- 
Cheers,
Alistair.

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Oops in microcode sysfs registration,
  2008-07-30 10:35         ` Dmitry Adamushko
  2008-07-30 13:28           ` Peter Oruba
  2008-07-31 12:49           ` Alistair John Strachan
@ 2008-07-31 16:56           ` Ingo Molnar
  2008-07-31 19:52             ` Dmitry Adamushko
  2 siblings, 1 reply; 42+ messages in thread
From: Ingo Molnar @ 2008-07-31 16:56 UTC (permalink / raw)
  To: Dmitry Adamushko
  Cc: Alistair John Strachan, Pekka Paalanen, Linus Torvalds,
	Linux Kernel Mailing List, shaohua.li, tigran, Thomas Gleixner,
	Steven Rostedt, Max Krasnyansky, Peter Zijlstra


* Dmitry Adamushko <dmitry.adamushko@gmail.com> wrote:

> 2008/7/30 Dmitry Adamushko <dmitry.adamushko@gmail.com>:
> > 2008/7/29 Alistair John Strachan <alistair@devzero.co.uk>:
> >> On Tuesday 29 July 2008 17:22:14 Pekka Paalanen wrote:
> >>> > Also, I'm sure this is reproducible without the NVIDIA garbage, but I was
> >>> > too lazy to test it. If you want me to repeat the experiment without the
> >>> > driver I would be more than happy to do so.
> >>>
> >>> I'm not sure people are willing to look into this without a clean report,
> >>> so this would be cool. There's even a test module for mmiotrace in the
> >>> kernel, but I doubt it would make difference to use it or not, when trying
> >>> to reproduce the crash without the blob.
> >>
> >> Of course, and I should have attempted to reproduce without the driver.
> >> Fortunately that was easy: it is not an NVIDIA driver bug.
> >>
> >> Steps to reproduce: have CONFIG_MICROCODE=y and a suitable Intel
> >> processor, then do:
> >>
> >> echo mmiotrace >/debug/tracing/current_tracer
> >> echo none >/debug/tracing/current_tracer
> >>
> >> And you get this (snipped) oops:
> >>
> >> in mmio_trace_init
> >> mmiotrace: Disabling non-boot CPUs...
> >> kvm: disabling virtualization on CPU1
> >> CPU 1 is now offline
> >> SMP alternatives: switching to UP code
> >> CPU0 attaching NULL sched-domain.
> >> CPU1 attaching NULL sched-domain.
> >> CPU0 attaching NULL sched-domain.
> >> mmiotrace: CPU1 is down.
> >> mmiotrace: enabled.
> >> in mmio_trace_reset
> >> mmiotrace: Re-enabling CPUs...
> >> SMP alternatives: switching to SMP code
> >> Booting processor 1/1 ip 6000
> >> Initializing CPU#1
> >> Calibrating delay using timer specific routine.. <6>7204.76 BogoMIPS (lpj=3602381)
> >> CPU: L1 I cache: 32K, L1 D cache: 32K
> >> CPU: L2 cache: 4096K
> >> CPU: Physical Processor ID: 0
> >> CPU: Processor Core ID: 1
> >> x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
> >> CPU1: Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz stepping 06
> >> checking TSC synchronization [CPU#0 -> CPU#1]: passed.
> >> kvm: enabling virtualization on CPU1
> >> CPU0 attaching NULL sched-domain.
> >> Switched to high resolution mode on CPU 1
> >> CPU0 attaching sched-domain:
> >>  domain 0: span 0-1 level MC
> >>  groups: 0 1
> >> CPU1 attaching sched-domain:
> >>  domain 0: span 0-1 level MC
> >>  groups: 1 0
> >> ------------[ cut here ]------------
> >> Kernel BUG at ffffffff8021a31d [verbose debug info unavailable]
> >> invalid opcode: 0000 [1] PREEMPT SMP
> >> CPU 0
> >> Modules linked in: rfcomm l2cap kvm_intel kvm ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack ip_tables x_tables bridge stp llc acpi_cpufreq freq_table coretemp hwmon
> >> snd_pcm_oss snd_mixer_oss firewire_sbp2 hci_usb bluetooth arc4 ecb crypto_blkcipher cryptomgr crypto_algapi usbhid zd1211rw mac80211 crypto cfg80211 snd_emu10k1 snd_rawmidi
> >> snd_ac97_codec ac97_bus sg snd_seq_device snd_hda_intel snd_pcm snd_util_mem snd_timer sr_mod snd_hwdep i2c_i801 ehci_hcd firewire_ohci uhci_hcd snd snd_page_alloc firewire_core
> >> soundcore r8169 cdrom usbcore i2c_core crc_itu_t
> >> Pid: 2757, comm: bash Tainted: G       A  2.6.27-rc1-damocles #3
> >> RIP: 0010:[<ffffffff8021a31d>]  [<ffffffff8021a31d>] __mc_sysdev_add+0xc3/0x1f1
> >> RSP: 0018:ffff8800b8905ce8  EFLAGS: 00010297
> >> RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff880080a04000
> >> RDX: ffffffff8062c680 RSI: 0000000000000003 RDI: ffffffff8059e830
> >> RBP: ffff8800b8905d48 R08: ffff8800b8904000 R09: ffffffff80229ca4
> >> R10: ffff8800010247b0 R11: ffff8800bf879de0 R12: 0000000000000018
> >> R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000
> >> FS:  00007f8ddc78f6e0(0000) GS:ffffffff805da200(0000) knlGS:0000000000000000
> >> CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> >> CR2: 00007f57cb9b2098 CR3: 00000000b8985000 CR4: 00000000000026e0
> >> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> >> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> >> Process bash (pid: 2757, threadinfo ffff8800b8904000, task ffff8800bd125640)
> >> Stack:  ffffffff80627040 0000000000000000 0000000000000008 ffffffff8048bb28
> >>  0000000000000003 ffffffff802ce910 ffff8800b8905d28 0000000000000002
> >>  00000000ffffffe8 0000000000000001 0000000000000001 ffff880001028418
> >> Call Trace:
> >>  [<ffffffff802ce910>] ? sysfs_add_file+0xc/0xe
> >>  [<ffffffff8021a456>] mc_sysdev_add+0xb/0xd
> >>  [<ffffffff8047baaf>] mc_cpu_callback+0x4b/0x208
> >>  [<ffffffff8047b772>] ? mce_cpu_callback+0x3e/0xbc
> >>  [<ffffffff8024b787>] notifier_call_chain+0x33/0x5b
> >>  [<ffffffff8024b81f>] raw_notifier_call_chain+0xf/0x11
> >>  [<ffffffff8047e1dc>] _cpu_up+0xce/0x119
> >>  [<ffffffff8047e285>] cpu_up+0x5e/0x8a
> >>  [<ffffffff80224967>] disable_mmiotrace+0xfe/0x173
> >>  [<ffffffff80265279>] mmio_trace_reset+0x2d/0x44
> >>  [<ffffffff80262c4d>] tracing_set_trace_write+0xd3/0x10f
> >>  [<ffffffff80289cab>] ? filp_close+0x67/0x72
> >>  [<ffffffff8028bee3>] vfs_write+0xa7/0xe1
> >>  [<ffffffff8028bfe1>] sys_write+0x47/0x6f
> >>  [<ffffffff8020b6db>] system_call_fastpath+0x16/0x1b
> >> [   68.405002]
> >> [   68.405002]
> >> Code: e8 59 80 e8 fd 69 26 00 48 c7 c2 80 c6 62 80 48 8b 05 c0 00 3c 00 48 8b 04 d8 48 8b 48 08 65 8b 04 25 24 00 00 00 44 39 e8 74 04 <0f> 0b eb fe 4c 8d 04 0a 41 c7 84 24 7c 36 64 80 00
> >> 00 00 00 41
> >> RIP  [<ffffffff8021a31d>] __mc_sysdev_add+0xc3/0x1f1
> >>  RSP <ffff8800b8905ce8>
> >> ---[ end trace ee9c9240024cb48c ]---
> >>
> >> I've replaced the originally tainted dmesg with this new clean one, so
> >> there's no proprietary smell about it :-)
> >
> > Yes, it's kind of a known issue. Take a look at this explanation:
> > http://lkml.org/lkml/2008/7/24/260
> >
> > There were a few related discussions in other threads (mainly, Max
> > Krasnyansky and I were asking for additional info on possible
> > requirements from the 'microcode' driver...) heh, I think, we'd be
> > better off just fixing it one way or another.
> 
> does a patch below fix it for you?
> [ not really what we wanted ]
> 
> (non-white-space-damaged version is enclosed)

could you please send this patch with a changelog, explanation, etc.?

	Ingo

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Oops in microcode sysfs registration,
  2008-07-31 16:56           ` Ingo Molnar
@ 2008-07-31 19:52             ` Dmitry Adamushko
  2008-07-31 19:55               ` Dmitry Adamushko
  0 siblings, 1 reply; 42+ messages in thread
From: Dmitry Adamushko @ 2008-07-31 19:52 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Alistair John Strachan, Pekka Paalanen, Linus Torvalds,
	Linux Kernel Mailing List, shaohua.li, tigran, Thomas Gleixner,
	Steven Rostedt, Max Krasnyansky, Peter Zijlstra

2008/7/31 Ingo Molnar <mingo@elte.hu>:
>
> * Dmitry Adamushko <dmitry.adamushko@gmail.com> wrote:
>
>> 2008/7/30 Dmitry Adamushko <dmitry.adamushko@gmail.com>:
>> > 2008/7/29 Alistair John Strachan <alistair@devzero.co.uk>:
>> >> On Tuesday 29 July 2008 17:22:14 Pekka Paalanen wrote:
>> >>> > Also, I'm sure this is reproducible without the NVIDIA garbage, but I was
>> >>> > too lazy to test it. If you want me to repeat the experiment without the
>> >>> > driver I would be more than happy to do so.
>> >>>
>> >>> I'm not sure people are willing to look into this without a clean report,
>> >>> so this would be cool. There's even a test module for mmiotrace in the
>> >>> kernel, but I doubt it would make difference to use it or not, when trying
>> >>> to reproduce the crash without the blob.
>> >>
>> >> Of course, and I should have attempted to reproduce without the driver.
>> >> Fortunately that was easy: it is not an NVIDIA driver bug.
>> >>
>> >> Steps to reproduce: have CONFIG_MICROCODE=y and a suitable Intel
>> >> processor, then do:
>> >>
>> >> echo mmiotrace >/debug/tracing/current_tracer
>> >> echo none >/debug/tracing/current_tracer
>> >>
>> >> And you get this (snipped) oops:
>> >>
>> >> in mmio_trace_init
>> >> mmiotrace: Disabling non-boot CPUs...
>> >> kvm: disabling virtualization on CPU1
>> >> CPU 1 is now offline
>> >> SMP alternatives: switching to UP code
>> >> CPU0 attaching NULL sched-domain.
>> >> CPU1 attaching NULL sched-domain.
>> >> CPU0 attaching NULL sched-domain.
>> >> mmiotrace: CPU1 is down.
>> >> mmiotrace: enabled.
>> >> in mmio_trace_reset
>> >> mmiotrace: Re-enabling CPUs...
>> >> SMP alternatives: switching to SMP code
>> >> Booting processor 1/1 ip 6000
>> >> Initializing CPU#1
>> >> Calibrating delay using timer specific routine.. <6>7204.76 BogoMIPS (lpj=3602381)
>> >> CPU: L1 I cache: 32K, L1 D cache: 32K
>> >> CPU: L2 cache: 4096K
>> >> CPU: Physical Processor ID: 0
>> >> CPU: Processor Core ID: 1
>> >> x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106
>> >> CPU1: Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz stepping 06
>> >> checking TSC synchronization [CPU#0 -> CPU#1]: passed.
>> >> kvm: enabling virtualization on CPU1
>> >> CPU0 attaching NULL sched-domain.
>> >> Switched to high resolution mode on CPU 1
>> >> CPU0 attaching sched-domain:
>> >>  domain 0: span 0-1 level MC
>> >>  groups: 0 1
>> >> CPU1 attaching sched-domain:
>> >>  domain 0: span 0-1 level MC
>> >>  groups: 1 0
>> >> ------------[ cut here ]------------
>> >> Kernel BUG at ffffffff8021a31d [verbose debug info unavailable]
>> >> invalid opcode: 0000 [1] PREEMPT SMP
>> >> CPU 0
>> >> Modules linked in: rfcomm l2cap kvm_intel kvm ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack ip_tables x_tables bridge stp llc acpi_cpufreq freq_table coretemp hwmon
>> >> snd_pcm_oss snd_mixer_oss firewire_sbp2 hci_usb bluetooth arc4 ecb crypto_blkcipher cryptomgr crypto_algapi usbhid zd1211rw mac80211 crypto cfg80211 snd_emu10k1 snd_rawmidi
>> >> snd_ac97_codec ac97_bus sg snd_seq_device snd_hda_intel snd_pcm snd_util_mem snd_timer sr_mod snd_hwdep i2c_i801 ehci_hcd firewire_ohci uhci_hcd snd snd_page_alloc firewire_core
>> >> soundcore r8169 cdrom usbcore i2c_core crc_itu_t
>> >> Pid: 2757, comm: bash Tainted: G       A  2.6.27-rc1-damocles #3
>> >> RIP: 0010:[<ffffffff8021a31d>]  [<ffffffff8021a31d>] __mc_sysdev_add+0xc3/0x1f1
>> >> RSP: 0018:ffff8800b8905ce8  EFLAGS: 00010297
>> >> RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff880080a04000
>> >> RDX: ffffffff8062c680 RSI: 0000000000000003 RDI: ffffffff8059e830
>> >> RBP: ffff8800b8905d48 R08: ffff8800b8904000 R09: ffffffff80229ca4
>> >> R10: ffff8800010247b0 R11: ffff8800bf879de0 R12: 0000000000000018
>> >> R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000
>> >> FS:  00007f8ddc78f6e0(0000) GS:ffffffff805da200(0000) knlGS:0000000000000000
>> >> CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>> >> CR2: 00007f57cb9b2098 CR3: 00000000b8985000 CR4: 00000000000026e0
>> >> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> >> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> >> Process bash (pid: 2757, threadinfo ffff8800b8904000, task ffff8800bd125640)
>> >> Stack:  ffffffff80627040 0000000000000000 0000000000000008 ffffffff8048bb28
>> >>  0000000000000003 ffffffff802ce910 ffff8800b8905d28 0000000000000002
>> >>  00000000ffffffe8 0000000000000001 0000000000000001 ffff880001028418
>> >> Call Trace:
>> >>  [<ffffffff802ce910>] ? sysfs_add_file+0xc/0xe
>> >>  [<ffffffff8021a456>] mc_sysdev_add+0xb/0xd
>> >>  [<ffffffff8047baaf>] mc_cpu_callback+0x4b/0x208
>> >>  [<ffffffff8047b772>] ? mce_cpu_callback+0x3e/0xbc
>> >>  [<ffffffff8024b787>] notifier_call_chain+0x33/0x5b
>> >>  [<ffffffff8024b81f>] raw_notifier_call_chain+0xf/0x11
>> >>  [<ffffffff8047e1dc>] _cpu_up+0xce/0x119
>> >>  [<ffffffff8047e285>] cpu_up+0x5e/0x8a
>> >>  [<ffffffff80224967>] disable_mmiotrace+0xfe/0x173
>> >>  [<ffffffff80265279>] mmio_trace_reset+0x2d/0x44
>> >>  [<ffffffff80262c4d>] tracing_set_trace_write+0xd3/0x10f
>> >>  [<ffffffff80289cab>] ? filp_close+0x67/0x72
>> >>  [<ffffffff8028bee3>] vfs_write+0xa7/0xe1
>> >>  [<ffffffff8028bfe1>] sys_write+0x47/0x6f
>> >>  [<ffffffff8020b6db>] system_call_fastpath+0x16/0x1b
>> >> [   68.405002]
>> >> [   68.405002]
>> >> Code: e8 59 80 e8 fd 69 26 00 48 c7 c2 80 c6 62 80 48 8b 05 c0 00 3c 00 48 8b 04 d8 48 8b 48 08 65 8b 04 25 24 00 00 00 44 39 e8 74 04 <0f> 0b eb fe 4c 8d 04 0a 41 c7 84 24 7c 36 64 80 00
>> >> 00 00 00 41
>> >> RIP  [<ffffffff8021a31d>] __mc_sysdev_add+0xc3/0x1f1
>> >>  RSP <ffff8800b8905ce8>
>> >> ---[ end trace ee9c9240024cb48c ]---
>> >>
>> >> I've replaced the originally tainted dmesg with this new clean one, so
>> >> there's no proprietary smell about it :-)
>> >
>> > Yes, it's kind of a known issue. Take a look at this explanation:
>> > http://lkml.org/lkml/2008/7/24/260
>> >
>> > There were a few related discussions in other threads (mainly, Max
>> > Krasnyansky and I were asking for additional info on possible
>> > requirements from the 'microcode' driver...) heh, I think, we'd be
>> > better off just fixing it one way or another.
>>
>> does a patch below fix it for you?
>> [ not really what we wanted ]
>>
>> (non-white-space-damaged version is enclosed)
>
> could you please send this patch with a changelog, explanation, etc.?

Now having thought a bit more on that issue, I tend to think that this
patch is not all that nice (so I agree with Max here).

The root problem is the way set_cpus_allowed_ptr() is used in
microcode's cpu-hotplug handler. With cpu_active_map in place
set_cpus_allowed_ptr() can't migrate a task on the soon-to-be-online
cpu from withing a CPU_ONLINE handler (more in details here:
http://lkml.org/lkml/2008/7/24/260)

Basically, this patch marks a 'cpu' available for other tasks to be
migrated to it before sending CPU_ONLINE notification to
subscribers... [ now, there can be CPU_ONLINE
http://lkml.org/lkml/2008/7/24/260handlers that has something to do
with enabling migration/load-balancing. e.g. migration_call() ,
although it has the highest prio and is supposed to run first in a
chain ]

In another thread, I've asked whether doing 'microcode update' in
start_secondary() (or even at the beginning of idle_cpu() would be
better):

pros:
- it's done as early as possible (no other tasks has started running
on a cpu yet);
- no actions in cpu-hotplug;

cons:
- microcode sub-systems becomes visible outside of microcode.c _but_
it's arch-specific part anyway + with object-oriented re-work (which
is in -tip), I think it'd be that bad.

Alternatives:

- delayed 'microcode' update -> scheduled to 'workqueue'  (cons: it's
not as early as possible);
- Max suggested a combination of IPI + some wotk (request_firmware())
from cpu-hotplug handler itself. But I think it's quite a complex
scheme (and maybe prone to other problems).


What do you think?


>
>        Ingo
>

-- 
Best regards,
Dmitry Adamushko

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Oops in microcode sysfs registration,
  2008-07-31 19:52             ` Dmitry Adamushko
@ 2008-07-31 19:55               ` Dmitry Adamushko
  0 siblings, 0 replies; 42+ messages in thread
From: Dmitry Adamushko @ 2008-07-31 19:55 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Alistair John Strachan, Pekka Paalanen, Linus Torvalds,
	Linux Kernel Mailing List, shaohua.li, tigran, Thomas Gleixner,
	Steven Rostedt, Max Krasnyansky, Peter Zijlstra

2008/7/31 Dmitry Adamushko <dmitry.adamushko@gmail.com>:
>>
>> could you please send this patch with a changelog, explanation, etc.?
>
> Now having thought a bit more on that issue, I tend to think that this
> patch is not all that nice (so I agree with Max here).
>
> The root problem is the way set_cpus_allowed_ptr() is used in
> microcode's cpu-hotplug handler. With cpu_active_map in place
> set_cpus_allowed_ptr() can't migrate a task on the soon-to-be-online
> cpu from withing a CPU_ONLINE handler (more in details here:
> http://lkml.org/lkml/2008/7/24/260)
>
> Basically, this patch marks a 'cpu' available for other tasks to be
> migrated to it before sending CPU_ONLINE notification to
> subscribers... [ now, there can be CPU_ONLINE
> http://lkml.org/lkml/2008/7/24/260handlers that has something to do
> with enabling migration/load-balancing. e.g. migration_call() ,
> although it has the highest prio and is supposed to run first in a
> chain ]
>
> In another thread, I've asked whether doing 'microcode update' in
> start_secondary() (or even at the beginning of idle_cpu() would be
> better):
>
> pros:
> - it's done as early as possible (no other tasks has started running
> on a cpu yet);
> - no actions in cpu-hotplug;
>
> cons:
> - microcode sub-systems becomes visible outside of microcode.c _but_
> it's arch-specific part anyway + with object-oriented re-work (which
> is in -tip), I think it'd be that bad.

it was supposed to be "it'd be _not_ that bad"


-- 
Best regards,
Dmitry Adamushko

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: Linux v2.6.27-rc1: linux-next
  2008-07-30  9:03     ` Andrew Morton
@ 2008-07-31 22:22       ` Rafael J. Wysocki
  0 siblings, 0 replies; 42+ messages in thread
From: Rafael J. Wysocki @ 2008-07-31 22:22 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Linus Torvalds, Jesse Barnes, Linux Kernel Mailing List,
	Stephen Rothwell

On Wednesday, 30 of July 2008, Andrew Morton wrote:
> On Tue, 29 Jul 2008 09:59:18 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> >  - I don't think the 'next' thing works as well for the occasional 
> >    developer that just has a few patches pending as it works for subsystem 
> >    maintainers that are used to it.
> 
> Those people's patches are in -mm, which now holds maybe 100 or more
> "trees", many of which are small or empty.
> 
> My project within the next couple of weeks is to get most of that
> material into linux-next.  Stephen will be involved ;)
> 
> >    IOW, I think 'next' needs enough infrastructure setup from the 
> >    developer side that I don't think it's reasonable for _everything_ to 
> >    go through next.
> 
> True.  But
> 
> a) some of the problematic changes which we've seen simply _should_
>    have been in linux-next.  Some of them were even coming from
>    developers whose trees are already in linux-next.
> 
> b) A lot of the bugs which hit your tree would have been quickly
>    found in linux-next too.
> 
> 
> But it's all shuffling deckchairs, really.  Are we actually merging
> better code as a reasult of all of this?  Are we being more careful and
> reviewing better and testing better?
> 
> Don't think so.

Well, if the number of the regressions list entries can be regarded as a
pointer, then yes, we are. :-)

There are 28 entries in there right now, compared to 53 entries initially in
the list during the 2.6.26 cycle (see
http://bugzilla.kernel.org/show_bug.cgi?id=11167 for reference).

Thanks,
Rafael

^ permalink raw reply	[flat|nested] 42+ messages in thread

end of thread, other threads:[~2008-07-31 22:19 UTC | newest]

Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-07-29  3:23 Linux v2.6.27-rc1 Linus Torvalds
2008-07-29  4:01 ` Nick Piggin
2008-07-29  9:49 ` 2.6.27-rc1: zd1211rw association fails Alistair John Strachan
2008-07-29 10:09   ` Johannes Berg
2008-07-29 11:25     ` Alistair John Strachan
2008-07-29 11:26       ` Johannes Berg
2008-07-29 11:37         ` Hugh Dickins
2008-07-29 11:46         ` Kalle Valo
2008-07-29 11:55         ` Alistair John Strachan
2008-07-29 12:04     ` Theodore Tso
2008-07-29 12:09       ` Johannes Berg
2008-07-29 12:15         ` Johannes Berg
2008-07-29 15:18           ` Theodore Tso
2008-07-29 17:52           ` John W. Linville
2008-07-30  4:48             ` David Miller
2008-07-29 13:57 ` Oops in microcode sysfs registration, Alistair John Strachan
2008-07-29 16:22   ` Pekka Paalanen
2008-07-29 16:50     ` Alistair John Strachan
2008-07-30  9:07       ` Dmitry Adamushko
2008-07-30 10:35         ` Dmitry Adamushko
2008-07-30 13:28           ` Peter Oruba
2008-07-31 12:49           ` Alistair John Strachan
2008-07-31 16:56           ` Ingo Molnar
2008-07-31 19:52             ` Dmitry Adamushko
2008-07-31 19:55               ` Dmitry Adamushko
2008-07-29 16:27 ` Linux v2.6.27-rc1 Jesse Barnes
2008-07-29 16:59   ` Linus Torvalds
2008-07-29 17:31     ` Roland Dreier
2008-07-30  9:03     ` Andrew Morton
2008-07-31 22:22       ` Linux v2.6.27-rc1: linux-next Rafael J. Wysocki
2008-07-29 20:49 ` Linux v2.6.27-rc1: problem with firmware stuff Rafael J. Wysocki
2008-07-29 21:01   ` Rafael J. Wysocki
2008-07-29 21:01     ` Linus Torvalds
2008-07-29 22:26       ` David Woodhouse
2008-07-29 21:37 ` Linux v2.6.27-rc1 Sam Ravnborg
2008-07-29 21:42   ` Linus Torvalds
2008-07-29 21:59     ` Sam Ravnborg
2008-07-29 22:03       ` Linus Torvalds
2008-07-29 22:30         ` Sam Ravnborg
2008-07-29 22:03 ` Linux v2.6.27-rc1: fails to compile Grant Coady
2008-07-29 22:40   ` Frederik Deweerdt
2008-07-29 23:46     ` Grant Coady

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).