El Sun, 6 Jan 2008 14:19:16 -0800 (PST)
Linus Torvalds <[email protected]> escribi=C3=B3:
>=20
> It's been two weeks since rc6, but let's face it, with xmas and new y=
ears=20
> (and birthdays) in between, there hasn't actually been a lot of worki=
ng=20
> days, and the incremental patch from -rc6 is about half the size of t=
he=20
> one from rc5->rc6.
>=20
> And I'll be charitable and claim it's because it's all stabilizing, a=
nd=20
> not because we've all been in a drunken stupor over the holidays.
>=20
> The shortlog (appended below) is short and fairly informative. It's a=
ll=20
> really just a lot of rather small changes. The diffstat shows a lot o=
f=20
> one- and two-liners, with just a few drivers (and the Cell platform)=20
> getting a bit more attention, and the SLUB support of /proc/slabinfo=20
> showing up as a blip.
>=20
> Both git trees and tar-balls/patches pushed out, should be mirroring =
out=20
> within minutes. So there are no excuses to not try it out, and see if=
your=20
> favorite regression has been fixed.
>=20
> Linus
>=20
Booted with it and I see=20
[ 37.043998] =
=20
[ 37.043999] Call Trace: =
=20
[ 37.044001] <IRQ> [<ffffffff80227fe3>] enqueue_task+0x13/0x30 =
=20
[ 37.044040] [<ffffffff88178cbe>] :mac80211:__ieee80211_rx+0xc7e/0xd=
30 =20
[ 37.044044] [<ffffffff80228062>] activate_task+0x32/0x50 =
=20
[ 37.044073] [<ffffffff8816a28b>] :mac80211:ieee80211_tasklet_handle=
r+0xbb/0x120 =20
[ 37.044086] [<ffffffff80238d08>] tasklet_action+0x48/0xb0 =
=20
[ 37.044091] [<ffffffff80238c09>] __do_softirq+0x69/0xe0 =
=20
[ 37.044097] [<ffffffff8020ce2c>] call_softirq+0x1c/0x30 =
=20
[ 37.044101] [<ffffffff8020efe5>] do_softirq+0x35/0x90 =
=20
[ 37.044105] [<ffffffff80238aa5>] irq_exit+0x95/0xa0 =
=20
[ 37.044108] [<ffffffff8020f0c0>] do_IRQ+0x80/0x100 =
=20
[ 37.044111] [<ffffffff8020a840>] default_idle+0x0/0x40 =
=20
[ 37.044115] [<ffffffff8020c181>] ret_from_intr+0x0/0xa =
=20
[ 37.044117] <EOI> [<ffffffff8020a869>] default_idle+0x29/0x40 =
=20
[ 37.044130] [<ffffffff8020a8f5>] cpu_idle+0x75/0xc0 =
=20
[ 37.044146] =
=20
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
=20
Linux Varda 2.6.24-rc7 #3 SMP PREEMPT Mon Jan 7 14:47:13 CET 2008 x86_6=
4 GNU/Linux
=20
Gnu C 4.1.3
Gnu make 3.81
binutils 2.18
util-linux 2.13
mount 2.13
module-init-tools 3.3-pre2
e2fsprogs 1.40.2
jfsutils 1.1.11
reiserfsprogs 3.6.19
pcmciautils 014
PPP 2.4.4
Linux C Library 2.6.1
Dynamic linker (ldd) 2.6.1
Procps 3.2.7
Net-tools 1.60
Kbd [opcion...][archivo
Console-tools 0.2.3
Sh-utils 5.97
udev 113
wireless-tools 29
Modules Loaded af_packet binfmt_misc rfcomm l2cap bluetooth ipv=
6 powernow_k8 cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq=
_ondemand freq_table cpufreq_conservative nf_conntrack_ftp nf_conntrack=
_irc xt_tcpudp ipt_ULOG xt_limit xt_state iptable_filter nf_conntrack_i=
pv4 nf_conntrack ip_tables x_tables kvm_amd kvm w83627ehf hwmon_vid lp =
arc4 ecb blkcipher cryptomgr snd_hda_intel crypto_algapi snd_pcm_oss sn=
d_mixer_oss snd_pcm rt2500pci rt2x00pci rt2x00lib snd_seq_dummy rfkill =
snd_mpu401 input_polldev snd_seq_oss snd_mpu401_uart crc_itu_t snd_seq_=
midi snd_seq_midi_event mac80211 8250_pnp snd_rawmidi snd_seq parport_p=
c parport 8250 serial_core usbhid cfg80211 snd_timer snd_seq_device rtc=
evdev pcspkr ff_memless k8temp hwmon usblp snd eeprom_93cx6 i2c_ali153=
5 i2c_ali15x3 soundcore i2c_core snd_page_alloc button uli526x floppy s=
r_mod cdrom sg ehci_hcd ohci_hcd pata_acpi ata_generic r8169 usbcore un=
ix thermal processor fan fuse
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.24-rc6
# Sun Jan 6 17:11:46 2008
#
CONFIG_64BIT=3Dy
# CONFIG_X86_32 is not set
CONFIG_X86_64=3Dy
CONFIG_X86=3Dy
CONFIG_GENERIC_TIME=3Dy
CONFIG_GENERIC_CMOS_UPDATE=3Dy
CONFIG_CLOCKSOURCE_WATCHDOG=3Dy
CONFIG_GENERIC_CLOCKEVENTS=3Dy
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=3Dy
CONFIG_LOCKDEP_SUPPORT=3Dy
CONFIG_STACKTRACE_SUPPORT=3Dy
CONFIG_SEMAPHORE_SLEEPERS=3Dy
CONFIG_MMU=3Dy
CONFIG_ZONE_DMA=3Dy
# CONFIG_QUICKLIST is not set
CONFIG_GENERIC_ISA_DMA=3Dy
CONFIG_GENERIC_IOMAP=3Dy
CONFIG_GENERIC_BUG=3Dy
CONFIG_GENERIC_HWEIGHT=3Dy
CONFIG_ARCH_MAY_HAVE_PC_FDC=3Dy
CONFIG_DMI=3Dy
CONFIG_RWSEM_GENERIC_SPINLOCK=3Dy
# CONFIG_RWSEM_XCHGADD_ALGORITHM is not set
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_CALIBRATE_DELAY=3Dy
CONFIG_GENERIC_TIME_VSYSCALL=3Dy
CONFIG_ARCH_SUPPORTS_OPROFILE=3Dy
CONFIG_ZONE_DMA32=3Dy
CONFIG_ARCH_POPULATES_NODE_MAP=3Dy
CONFIG_AUDIT_ARCH=3Dy
CONFIG_GENERIC_HARDIRQS=3Dy
CONFIG_GENERIC_IRQ_PROBE=3Dy
CONFIG_GENERIC_PENDING_IRQ=3Dy
# CONFIG_KTIME_SCALAR is not set
CONFIG_DEFCONFIG_LIST=3D"/lib/modules/$UNAME_RELEASE/.config"
#
# General setup
#
CONFIG_EXPERIMENTAL=3Dy
CONFIG_LOCK_KERNEL=3Dy
CONFIG_INIT_ENV_ARG_LIMIT=3D32
CONFIG_LOCALVERSION=3D""
CONFIG_LOCALVERSION_AUTO=3Dy
CONFIG_SWAP=3Dy
CONFIG_SYSVIPC=3Dy
CONFIG_SYSVIPC_SYSCTL=3Dy
CONFIG_POSIX_MQUEUE=3Dy
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=3Dy
CONFIG_IKCONFIG_PROC=3Dy
CONFIG_LOG_BUF_SHIFT=3D15
# CONFIG_CGROUPS is not set
CONFIG_FAIR_GROUP_SCHED=3Dy
CONFIG_FAIR_USER_SCHED=3Dy
# CONFIG_FAIR_CGROUP_SCHED is not set
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=3Dy
CONFIG_BLK_DEV_INITRD=3Dy
CONFIG_INITRAMFS_SOURCE=3D""
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=3Dy
# CONFIG_EMBEDDED is not set
CONFIG_UID16=3Dy
CONFIG_SYSCTL_SYSCALL=3Dy
CONFIG_KALLSYMS=3Dy
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=3Dy
CONFIG_PRINTK=3Dy
CONFIG_BUG=3Dy
CONFIG_ELF_CORE=3Dy
CONFIG_BASE_FULL=3Dy
CONFIG_FUTEX=3Dy
CONFIG_ANON_INODES=3Dy
CONFIG_EPOLL=3Dy
CONFIG_SIGNALFD=3Dy
CONFIG_EVENTFD=3Dy
CONFIG_SHMEM=3Dy
CONFIG_VM_EVENT_COUNTERS=3Dy
CONFIG_SLUB_DEBUG=3Dy
# CONFIG_SLAB is not set
CONFIG_SLUB=3Dy
# CONFIG_SLOB is not set
CONFIG_SLABINFO=3Dy
CONFIG_RT_MUTEXES=3Dy
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=3D0
CONFIG_MODULES=3Dy
CONFIG_MODULE_UNLOAD=3Dy
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_MODVERSIONS=3Dy
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=3Dy
CONFIG_STOP_MACHINE=3Dy
CONFIG_BLOCK=3Dy
CONFIG_BLK_DEV_IO_TRACE=3Dy
CONFIG_BLK_DEV_BSG=3Dy
CONFIG_BLOCK_COMPAT=3Dy
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=3Dy
CONFIG_IOSCHED_AS=3Dy
CONFIG_IOSCHED_DEADLINE=3Dm
CONFIG_IOSCHED_CFQ=3Dm
CONFIG_DEFAULT_AS=3Dy
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED=3D"anticipatory"
CONFIG_PREEMPT_NOTIFIERS=3Dy
#
# Processor type and features
#
CONFIG_TICK_ONESHOT=3Dy
CONFIG_NO_HZ=3Dy
CONFIG_HIGH_RES_TIMERS=3Dy
CONFIG_GENERIC_CLOCKEVENTS_BUILD=3Dy
CONFIG_SMP=3Dy
CONFIG_X86_PC=3Dy
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_X86_VSMP is not set
# CONFIG_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=3Dy
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_GENERIC_CPU is not set
CONFIG_X86_L1_CACHE_BYTES=3D64
CONFIG_X86_INTERNODE_CACHE_BYTES=3D64
CONFIG_X86_CMPXCHG=3Dy
CONFIG_X86_L1_CACHE_SHIFT=3D6
CONFIG_X86_GOOD_APIC=3Dy
CONFIG_X86_INTEL_USERCOPY=3Dy
CONFIG_X86_USE_PPRO_CHECKSUM=3Dy
CONFIG_X86_TSC=3Dy
CONFIG_X86_MINIMUM_CPU_FAMILY=3D64
CONFIG_HPET_TIMER=3Dy
CONFIG_GART_IOMMU=3Dy
# CONFIG_CALGARY_IOMMU is not set
CONFIG_SWIOTLB=3Dy
CONFIG_NR_CPUS=3D2
# CONFIG_SCHED_SMT is not set
CONFIG_SCHED_MC=3Dy
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=3Dy
CONFIG_PREEMPT_BKL=3Dy
CONFIG_X86_LOCAL_APIC=3Dy
CONFIG_X86_IO_APIC=3Dy
CONFIG_X86_MCE=3Dy
# CONFIG_X86_MCE_INTEL is not set
CONFIG_X86_MCE_AMD=3Dy
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=3Dy
CONFIG_X86_CPUID=3Dy
# CONFIG_NUMA is not set
CONFIG_ARCH_FLATMEM_ENABLE=3Dy
CONFIG_ARCH_SPARSEMEM_ENABLE=3Dy
CONFIG_SELECT_MEMORY_MODEL=3Dy
CONFIG_FLATMEM_MANUAL=3Dy
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=3Dy
CONFIG_FLAT_NODE_MEM_MAP=3Dy
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=3Dy
CONFIG_SPLIT_PTLOCK_CPUS=3D4
CONFIG_RESOURCES_64BIT=3Dy
CONFIG_ZONE_DMA_FLAG=3D1
CONFIG_BOUNCE=3Dy
CONFIG_VIRT_TO_BUS=3Dy
CONFIG_MTRR=3Dy
# CONFIG_SECCOMP is not set
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=3Dy
CONFIG_HZ=3D1000
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
CONFIG_PHYSICAL_START=3D0x200000
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=3D0x200000
# CONFIG_HOTPLUG_CPU is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=3Dy
#
# Power management options
#
CONFIG_PM=3Dy
# CONFIG_PM_LEGACY is not set
# CONFIG_PM_DEBUG is not set
CONFIG_SUSPEND_SMP_POSSIBLE=3Dy
# CONFIG_SUSPEND is not set
CONFIG_HIBERNATION_SMP_POSSIBLE=3Dy
# CONFIG_HIBERNATION is not set
CONFIG_ACPI=3Dy
# CONFIG_ACPI_PROCFS is not set
# CONFIG_ACPI_PROCFS_POWER is not set
# CONFIG_ACPI_PROC_EVENT is not set
# CONFIG_ACPI_AC is not set
# CONFIG_ACPI_BATTERY is not set
CONFIG_ACPI_BUTTON=3Dm
# CONFIG_ACPI_VIDEO is not set
CONFIG_ACPI_FAN=3Dm
# CONFIG_ACPI_DOCK is not set
CONFIG_ACPI_PROCESSOR=3Dm
CONFIG_ACPI_THERMAL=3Dm
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_BLACKLIST_YEAR=3D0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_EC=3Dy
CONFIG_ACPI_POWER=3Dy
CONFIG_ACPI_SYSTEM=3Dy
CONFIG_X86_PM_TIMER=3Dy
# CONFIG_ACPI_CONTAINER is not set
# CONFIG_ACPI_SBS is not set
#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=3Dy
CONFIG_CPU_FREQ_TABLE=3Dm
# CONFIG_CPU_FREQ_DEBUG is not set
CONFIG_CPU_FREQ_STAT=3Dm
CONFIG_CPU_FREQ_STAT_DETAILS=3Dy
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=3Dy
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=3Dy
CONFIG_CPU_FREQ_GOV_POWERSAVE=3Dm
CONFIG_CPU_FREQ_GOV_USERSPACE=3Dm
CONFIG_CPU_FREQ_GOV_ONDEMAND=3Dm
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=3Dm
#
# CPUFreq processor drivers
#
CONFIG_X86_ACPI_CPUFREQ=3Dm
CONFIG_X86_POWERNOW_K8=3Dm
CONFIG_X86_POWERNOW_K8_ACPI=3Dy
# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
# CONFIG_X86_P4_CLOCKMOD is not set
#
# shared options
#
CONFIG_X86_ACPI_CPUFREQ_PROC_INTF=3Dy
# CONFIG_X86_SPEEDSTEP_LIB is not set
# CONFIG_CPU_IDLE is not set
#
# Bus options (PCI etc.)
#
CONFIG_PCI=3Dy
CONFIG_PCI_DIRECT=3Dy
CONFIG_PCI_MMCONFIG=3Dy
CONFIG_PCI_DOMAINS=3Dy
# CONFIG_DMAR is not set
CONFIG_PCIEPORTBUS=3Dy
CONFIG_PCIEAER=3Dy
CONFIG_ARCH_SUPPORTS_MSI=3Dy
CONFIG_PCI_MSI=3Dy
# CONFIG_PCI_LEGACY is not set
# CONFIG_PCI_DEBUG is not set
CONFIG_HT_IRQ=3Dy
CONFIG_ISA_DMA_API=3Dy
CONFIG_K8_NB=3Dy
# CONFIG_PCCARD is not set
# CONFIG_HOTPLUG_PCI is not set
#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=3Dy
CONFIG_BINFMT_MISC=3Dm
CONFIG_IA32_EMULATION=3Dy
# CONFIG_IA32_AOUT is not set
CONFIG_COMPAT=3Dy
CONFIG_COMPAT_FOR_U64_ALIGNMENT=3Dy
CONFIG_SYSVIPC_COMPAT=3Dy
#
# Networking
#
CONFIG_NET=3Dy
#
# Networking options
#
CONFIG_PACKET=3Dm
CONFIG_PACKET_MMAP=3Dy
CONFIG_UNIX=3Dm
CONFIG_XFRM=3Dy
CONFIG_XFRM_USER=3Dm
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
CONFIG_NET_KEY=3Dm
# CONFIG_NET_KEY_MIGRATE is not set
CONFIG_INET=3Dy
CONFIG_IP_MULTICAST=3Dy
CONFIG_IP_ADVANCED_ROUTER=3Dy
CONFIG_ASK_IP_FIB_HASH=3Dy
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=3Dy
CONFIG_IP_MULTIPLE_TABLES=3Dy
CONFIG_IP_ROUTE_MULTIPATH=3Dy
# CONFIG_IP_ROUTE_VERBOSE is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=3Dy
CONFIG_INET_AH=3Dm
CONFIG_INET_ESP=3Dm
CONFIG_INET_IPCOMP=3Dm
CONFIG_INET_XFRM_TUNNEL=3Dm
CONFIG_INET_TUNNEL=3Dm
CONFIG_INET_XFRM_MODE_TRANSPORT=3Dm
CONFIG_INET_XFRM_MODE_TUNNEL=3Dm
CONFIG_INET_XFRM_MODE_BEET=3Dm
CONFIG_INET_LRO=3Dy
CONFIG_INET_DIAG=3Dm
CONFIG_INET_TCP_DIAG=3Dm
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=3Dy
CONFIG_DEFAULT_TCP_CONG=3D"cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IP_VS is not set
CONFIG_IPV6=3Dm
CONFIG_IPV6_PRIVACY=3Dy
CONFIG_IPV6_ROUTER_PREF=3Dy
# CONFIG_IPV6_ROUTE_INFO is not set
# CONFIG_IPV6_OPTIMISTIC_DAD is not set
CONFIG_INET6_AH=3Dm
CONFIG_INET6_ESP=3Dm
CONFIG_INET6_IPCOMP=3Dm
# CONFIG_IPV6_MIP6 is not set
CONFIG_INET6_XFRM_TUNNEL=3Dm
CONFIG_INET6_TUNNEL=3Dm
CONFIG_INET6_XFRM_MODE_TRANSPORT=3Dm
CONFIG_INET6_XFRM_MODE_TUNNEL=3Dm
CONFIG_INET6_XFRM_MODE_BEET=3Dm
# CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
CONFIG_IPV6_SIT=3Dm
# CONFIG_IPV6_TUNNEL is not set
# CONFIG_IPV6_MULTIPLE_TABLES is not set
# CONFIG_NETLABEL is not set
# CONFIG_NETWORK_SECMARK is not set
CONFIG_NETFILTER=3Dy
# CONFIG_NETFILTER_DEBUG is not set
# CONFIG_BRIDGE_NETFILTER is not set
#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=3Dm
CONFIG_NETFILTER_NETLINK_QUEUE=3Dm
CONFIG_NETFILTER_NETLINK_LOG=3Dm
CONFIG_NF_CONNTRACK_ENABLED=3Dm
CONFIG_NF_CONNTRACK=3Dm
CONFIG_NF_CT_ACCT=3Dy
CONFIG_NF_CONNTRACK_MARK=3Dy
# CONFIG_NF_CONNTRACK_EVENTS is not set
CONFIG_NF_CT_PROTO_SCTP=3Dm
# CONFIG_NF_CT_PROTO_UDPLITE is not set
# CONFIG_NF_CONNTRACK_AMANDA is not set
CONFIG_NF_CONNTRACK_FTP=3Dm
# CONFIG_NF_CONNTRACK_H323 is not set
CONFIG_NF_CONNTRACK_IRC=3Dm
# CONFIG_NF_CONNTRACK_NETBIOS_NS is not set
# CONFIG_NF_CONNTRACK_PPTP is not set
# CONFIG_NF_CONNTRACK_SANE is not set
CONFIG_NF_CONNTRACK_SIP=3Dm
CONFIG_NF_CONNTRACK_TFTP=3Dm
# CONFIG_NF_CT_NETLINK is not set
CONFIG_NETFILTER_XTABLES=3Dm
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=3Dm
CONFIG_NETFILTER_XT_TARGET_CONNMARK=3Dm
CONFIG_NETFILTER_XT_TARGET_DSCP=3Dm
CONFIG_NETFILTER_XT_TARGET_MARK=3Dm
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=3Dm
CONFIG_NETFILTER_XT_TARGET_NFLOG=3Dm
CONFIG_NETFILTER_XT_TARGET_NOTRACK=3Dm
CONFIG_NETFILTER_XT_TARGET_TRACE=3Dm
CONFIG_NETFILTER_XT_TARGET_TCPMSS=3Dm
CONFIG_NETFILTER_XT_MATCH_COMMENT=3Dm
CONFIG_NETFILTER_XT_MATCH_CONNBYTES=3Dm
CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=3Dm
CONFIG_NETFILTER_XT_MATCH_CONNMARK=3Dm
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=3Dm
CONFIG_NETFILTER_XT_MATCH_DCCP=3Dm
CONFIG_NETFILTER_XT_MATCH_DSCP=3Dm
CONFIG_NETFILTER_XT_MATCH_ESP=3Dm
CONFIG_NETFILTER_XT_MATCH_HELPER=3Dm
CONFIG_NETFILTER_XT_MATCH_LENGTH=3Dm
CONFIG_NETFILTER_XT_MATCH_LIMIT=3Dm
CONFIG_NETFILTER_XT_MATCH_MAC=3Dm
CONFIG_NETFILTER_XT_MATCH_MARK=3Dm
CONFIG_NETFILTER_XT_MATCH_POLICY=3Dm
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=3Dm
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=3Dm
CONFIG_NETFILTER_XT_MATCH_QUOTA=3Dm
CONFIG_NETFILTER_XT_MATCH_REALM=3Dm
CONFIG_NETFILTER_XT_MATCH_SCTP=3Dm
CONFIG_NETFILTER_XT_MATCH_STATE=3Dm
CONFIG_NETFILTER_XT_MATCH_STATISTIC=3Dm
CONFIG_NETFILTER_XT_MATCH_STRING=3Dm
CONFIG_NETFILTER_XT_MATCH_TCPMSS=3Dm
CONFIG_NETFILTER_XT_MATCH_TIME=3Dm
CONFIG_NETFILTER_XT_MATCH_U32=3Dm
CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=3Dm
#
# IP: Netfilter Configuration
#
CONFIG_NF_CONNTRACK_IPV4=3Dm
CONFIG_NF_CONNTRACK_PROC_COMPAT=3Dy
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=3Dm
CONFIG_IP_NF_MATCH_IPRANGE=3Dm
CONFIG_IP_NF_MATCH_TOS=3Dm
CONFIG_IP_NF_MATCH_RECENT=3Dm
CONFIG_IP_NF_MATCH_ECN=3Dm
CONFIG_IP_NF_MATCH_AH=3Dm
CONFIG_IP_NF_MATCH_TTL=3Dm
CONFIG_IP_NF_MATCH_OWNER=3Dm
CONFIG_IP_NF_MATCH_ADDRTYPE=3Dm
CONFIG_IP_NF_FILTER=3Dm
CONFIG_IP_NF_TARGET_REJECT=3Dm
CONFIG_IP_NF_TARGET_LOG=3Dm
CONFIG_IP_NF_TARGET_ULOG=3Dm
CONFIG_NF_NAT=3Dm
CONFIG_NF_NAT_NEEDED=3Dy
CONFIG_IP_NF_TARGET_MASQUERADE=3Dm
CONFIG_IP_NF_TARGET_REDIRECT=3Dm
CONFIG_IP_NF_TARGET_NETMAP=3Dm
CONFIG_IP_NF_TARGET_SAME=3Dm
CONFIG_NF_NAT_SNMP_BASIC=3Dm
CONFIG_NF_NAT_FTP=3Dm
CONFIG_NF_NAT_IRC=3Dm
CONFIG_NF_NAT_TFTP=3Dm
# 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=3Dm
CONFIG_IP_NF_MANGLE=3Dm
CONFIG_IP_NF_TARGET_TOS=3Dm
CONFIG_IP_NF_TARGET_ECN=3Dm
CONFIG_IP_NF_TARGET_TTL=3Dm
CONFIG_IP_NF_TARGET_CLUSTERIP=3Dm
CONFIG_IP_NF_RAW=3Dm
CONFIG_IP_NF_ARPTABLES=3Dm
CONFIG_IP_NF_ARPFILTER=3Dm
CONFIG_IP_NF_ARP_MANGLE=3Dm
#
# IPv6: Netfilter Configuration (EXPERIMENTAL)
#
CONFIG_NF_CONNTRACK_IPV6=3Dm
CONFIG_IP6_NF_QUEUE=3Dm
CONFIG_IP6_NF_IPTABLES=3Dm
CONFIG_IP6_NF_MATCH_RT=3Dm
CONFIG_IP6_NF_MATCH_OPTS=3Dm
CONFIG_IP6_NF_MATCH_FRAG=3Dm
CONFIG_IP6_NF_MATCH_HL=3Dm
CONFIG_IP6_NF_MATCH_OWNER=3Dm
CONFIG_IP6_NF_MATCH_IPV6HEADER=3Dm
CONFIG_IP6_NF_MATCH_AH=3Dm
CONFIG_IP6_NF_MATCH_MH=3Dm
CONFIG_IP6_NF_MATCH_EUI64=3Dm
CONFIG_IP6_NF_FILTER=3Dm
CONFIG_IP6_NF_TARGET_LOG=3Dm
CONFIG_IP6_NF_TARGET_REJECT=3Dm
CONFIG_IP6_NF_MANGLE=3Dm
CONFIG_IP6_NF_TARGET_HL=3Dm
CONFIG_IP6_NF_RAW=3Dm
#
# Bridge: Netfilter Configuration
#
# CONFIG_BRIDGE_NF_EBTABLES is not set
# CONFIG_IP_DCCP is not set
CONFIG_IP_SCTP=3Dm
# CONFIG_SCTP_DBG_MSG is not set
# CONFIG_SCTP_DBG_OBJCNT is not set
# CONFIG_SCTP_HMAC_NONE is not set
# CONFIG_SCTP_HMAC_SHA1 is not set
CONFIG_SCTP_HMAC_MD5=3Dy
# CONFIG_TIPC is not set
CONFIG_ATM=3Dm
CONFIG_ATM_CLIP=3Dm
CONFIG_ATM_CLIP_NO_ICMP=3Dy
CONFIG_ATM_LANE=3Dm
CONFIG_ATM_MPOA=3Dm
CONFIG_ATM_BR2684=3Dm
CONFIG_ATM_BR2684_IPFILTER=3Dy
CONFIG_BRIDGE=3Dm
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
CONFIG_LLC=3Dm
# 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=3Dy
#
# Queueing/Scheduling
#
CONFIG_NET_SCH_CBQ=3Dm
CONFIG_NET_SCH_HTB=3Dm
CONFIG_NET_SCH_HFSC=3Dm
CONFIG_NET_SCH_ATM=3Dm
CONFIG_NET_SCH_PRIO=3Dm
CONFIG_NET_SCH_RR=3Dm
CONFIG_NET_SCH_RED=3Dm
CONFIG_NET_SCH_SFQ=3Dm
CONFIG_NET_SCH_TEQL=3Dm
CONFIG_NET_SCH_TBF=3Dm
CONFIG_NET_SCH_GRED=3Dm
CONFIG_NET_SCH_DSMARK=3Dm
CONFIG_NET_SCH_NETEM=3Dm
CONFIG_NET_SCH_INGRESS=3Dm
#
# Classification
#
CONFIG_NET_CLS=3Dy
CONFIG_NET_CLS_BASIC=3Dm
CONFIG_NET_CLS_TCINDEX=3Dm
CONFIG_NET_CLS_ROUTE4=3Dm
CONFIG_NET_CLS_ROUTE=3Dy
CONFIG_NET_CLS_FW=3Dm
CONFIG_NET_CLS_U32=3Dm
CONFIG_CLS_U32_PERF=3Dy
CONFIG_CLS_U32_MARK=3Dy
CONFIG_NET_CLS_RSVP=3Dm
CONFIG_NET_CLS_RSVP6=3Dm
CONFIG_NET_EMATCH=3Dy
CONFIG_NET_EMATCH_STACK=3D32
CONFIG_NET_EMATCH_CMP=3Dm
CONFIG_NET_EMATCH_NBYTE=3Dm
CONFIG_NET_EMATCH_U32=3Dm
CONFIG_NET_EMATCH_META=3Dm
CONFIG_NET_EMATCH_TEXT=3Dm
CONFIG_NET_CLS_ACT=3Dy
CONFIG_NET_ACT_POLICE=3Dm
CONFIG_NET_ACT_GACT=3Dm
CONFIG_GACT_PROB=3Dy
CONFIG_NET_ACT_MIRRED=3Dm
CONFIG_NET_ACT_IPT=3Dm
CONFIG_NET_ACT_NAT=3Dm
CONFIG_NET_ACT_PEDIT=3Dm
CONFIG_NET_ACT_SIMP=3Dm
# CONFIG_NET_CLS_POLICE is not set
CONFIG_NET_CLS_IND=3Dy
CONFIG_NET_SCH_FIFO=3Dy
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
CONFIG_BT=3Dm
CONFIG_BT_L2CAP=3Dm
CONFIG_BT_SCO=3Dm
CONFIG_BT_RFCOMM=3Dm
CONFIG_BT_RFCOMM_TTY=3Dy
CONFIG_BT_BNEP=3Dm
CONFIG_BT_BNEP_MC_FILTER=3Dy
CONFIG_BT_BNEP_PROTO_FILTER=3Dy
CONFIG_BT_HIDP=3Dm
#
# Bluetooth device drivers
#
CONFIG_BT_HCIUSB=3Dm
CONFIG_BT_HCIUSB_SCO=3Dy
CONFIG_BT_HCIUART=3Dm
CONFIG_BT_HCIUART_H4=3Dy
CONFIG_BT_HCIUART_BCSP=3Dy
# CONFIG_BT_HCIUART_LL is not set
CONFIG_BT_HCIBCM203X=3Dm
CONFIG_BT_HCIBPA10X=3Dm
CONFIG_BT_HCIBFUSB=3Dm
CONFIG_BT_HCIVHCI=3Dm
# CONFIG_AF_RXRPC is not set
CONFIG_FIB_RULES=3Dy
#
# Wireless
#
CONFIG_CFG80211=3Dm
CONFIG_NL80211=3Dy
CONFIG_WIRELESS_EXT=3Dy
CONFIG_MAC80211=3Dm
CONFIG_MAC80211_RCSIMPLE=3Dy
CONFIG_MAC80211_LEDS=3Dy
# CONFIG_MAC80211_DEBUGFS is not set
# CONFIG_MAC80211_DEBUG is not set
CONFIG_IEEE80211=3Dy
# CONFIG_IEEE80211_DEBUG is not set
CONFIG_IEEE80211_CRYPT_WEP=3Dm
CONFIG_IEEE80211_CRYPT_CCMP=3Dm
CONFIG_IEEE80211_CRYPT_TKIP=3Dm
CONFIG_IEEE80211_SOFTMAC=3Dm
# CONFIG_IEEE80211_SOFTMAC_DEBUG is not set
CONFIG_RFKILL=3Dm
CONFIG_RFKILL_INPUT=3Dm
CONFIG_RFKILL_LEDS=3Dy
CONFIG_NET_9P=3Dm
CONFIG_NET_9P_FD=3Dm
# CONFIG_NET_9P_DEBUG is not set
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH=3D"/sbin/hotplug"
CONFIG_STANDALONE=3Dy
CONFIG_PREVENT_FIRMWARE_BUILD=3Dy
CONFIG_FW_LOADER=3Dy
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
CONFIG_CONNECTOR=3Dm
# CONFIG_MTD is not set
CONFIG_PARPORT=3Dm
CONFIG_PARPORT_PC=3Dm
CONFIG_PARPORT_SERIAL=3Dm
CONFIG_PARPORT_PC_FIFO=3Dy
CONFIG_PARPORT_PC_SUPERIO=3Dy
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_AX88796 is not set
CONFIG_PARPORT_1284=3Dy
CONFIG_PNP=3Dy
# CONFIG_PNP_DEBUG is not set
#
# Protocols
#
CONFIG_PNPACPI=3Dy
CONFIG_BLK_DEV=3Dy
CONFIG_BLK_DEV_FD=3Dm
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=3Dm
CONFIG_BLK_DEV_CRYPTOLOOP=3Dm
# 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=3Dy
CONFIG_BLK_DEV_RAM_COUNT=3D16
CONFIG_BLK_DEV_RAM_SIZE=3D8192
CONFIG_BLK_DEV_RAM_BLOCKSIZE=3D1024
CONFIG_CDROM_PKTCDVD=3Dm
CONFIG_CDROM_PKTCDVD_BUFFERS=3D8
CONFIG_CDROM_PKTCDVD_WCACHE=3Dy
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_MISC_DEVICES is not set
CONFIG_EEPROM_93CX6=3Dm
# CONFIG_IDE is not set
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=3Dy
CONFIG_SCSI_DMA=3Dy
# 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=3Dy
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=3Dm
CONFIG_BLK_DEV_SR_VENDOR=3Dy
CONFIG_CHR_DEV_SG=3Dm
# CONFIG_CHR_DEV_SCH is not set
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set
CONFIG_SCSI_WAIT_SCAN=3Dm
#
# 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_ATA=3Dy
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_ACPI=3Dy
CONFIG_SATA_AHCI=3Dy
# 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_SIL24=3Dm
# CONFIG_SATA_SIS is not set
CONFIG_SATA_ULI=3Dm
CONFIG_SATA_VIA=3Dm
# CONFIG_SATA_VITESSE is not set
# CONFIG_SATA_INIC162X is not set
CONFIG_PATA_ACPI=3Dm
CONFIG_PATA_ALI=3Dy
# 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=3Dm
# 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=3Dm
# 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=3Dm
# 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=3Dm
# CONFIG_PATA_WINBOND is not set
# CONFIG_MD is not set
# CONFIG_FUSION is not set
#
# IEEE 1394 (FireWire) support
#
CONFIG_FIREWIRE=3Dm
CONFIG_FIREWIRE_OHCI=3Dm
CONFIG_FIREWIRE_SBP2=3Dm
# CONFIG_IEEE1394 is not set
# CONFIG_I2O is not set
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=3Dy
CONFIG_NETDEVICES_MULTIQUEUE=3Dy
# CONFIG_IFB is not set
CONFIG_DUMMY=3Dm
CONFIG_BONDING=3Dm
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=3Dm
CONFIG_VETH=3Dm
# CONFIG_NET_SB1000 is not set
# CONFIG_IP1000 is not set
# CONFIG_ARCNET is not set
CONFIG_PHYLIB=3Dm
#
# MII PHY device drivers
#
CONFIG_MARVELL_PHY=3Dm
CONFIG_DAVICOM_PHY=3Dm
CONFIG_QSEMI_PHY=3Dm
CONFIG_LXT_PHY=3Dm
CONFIG_CICADA_PHY=3Dm
CONFIG_VITESSE_PHY=3Dm
CONFIG_SMSC_PHY=3Dm
CONFIG_BROADCOM_PHY=3Dm
CONFIG_ICPLUS_PHY=3Dm
CONFIG_FIXED_PHY=3Dm
CONFIG_FIXED_MII_10_FDX=3Dy
CONFIG_FIXED_MII_100_FDX=3Dy
CONFIG_FIXED_MII_1000_FDX=3Dy
CONFIG_FIXED_MII_AMNT=3D1
# CONFIG_MDIO_BITBANG is not set
CONFIG_NET_ETHERNET=3Dy
CONFIG_MII=3Dm
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set
CONFIG_NET_TULIP=3Dy
# CONFIG_DE2104X is not set
# CONFIG_TULIP is not set
# CONFIG_DE4X5 is not set
# CONFIG_WINBOND_840 is not set
# CONFIG_DM9102 is not set
CONFIG_ULI526X=3Dm
# CONFIG_HP100 is not set
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
# CONFIG_NET_PCI is not set
# CONFIG_B44 is not set
# CONFIG_NET_POCKET is not set
CONFIG_NETDEV_1000=3Dy
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_E1000E is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
CONFIG_R8169=3Dm
CONFIG_R8169_NAPI=3Dy
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_SK98LIN 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_NETDEV_10000 is not set
# CONFIG_TR is not set
#
# Wireless LAN
#
# CONFIG_WLAN_PRE80211 is not set
CONFIG_WLAN_80211=3Dy
# 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=3Dm
CONFIG_RTL8187=3Dm
# CONFIG_ADM8211 is not set
# CONFIG_P54_COMMON is not set
# CONFIG_IWLWIFI is not set
# CONFIG_HOSTAP is not set
# CONFIG_BCM43XX is not set
# CONFIG_B43 is not set
# CONFIG_B43LEGACY is not set
CONFIG_ZD1211RW=3Dm
# CONFIG_ZD1211RW_DEBUG is not set
CONFIG_RT2X00=3Dm
CONFIG_RT2X00_LIB=3Dm
CONFIG_RT2X00_LIB_PCI=3Dm
CONFIG_RT2X00_LIB_USB=3Dm
CONFIG_RT2X00_LIB_FIRMWARE=3Dy
CONFIG_RT2X00_LIB_RFKILL=3Dy
# CONFIG_RT2400PCI is not set
CONFIG_RT2500PCI=3Dm
CONFIG_RT2500PCI_RFKILL=3Dy
# CONFIG_RT61PCI is not set
CONFIG_RT2500USB=3Dm
CONFIG_RT73USB=3Dm
# CONFIG_RT2X00_DEBUG 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_ATM_DRIVERS is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
CONFIG_PPP=3Dm
CONFIG_PPP_MULTILINK=3Dy
CONFIG_PPP_FILTER=3Dy
CONFIG_PPP_ASYNC=3Dm
CONFIG_PPP_SYNC_TTY=3Dm
CONFIG_PPP_DEFLATE=3Dm
CONFIG_PPP_BSDCOMP=3Dm
CONFIG_PPP_MPPE=3Dm
CONFIG_PPPOE=3Dm
CONFIG_PPPOATM=3Dm
# CONFIG_PPPOL2TP is not set
# CONFIG_SLIP is not set
CONFIG_SLHC=3Dm
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
CONFIG_NETCONSOLE=3Dm
CONFIG_NETCONSOLE_DYNAMIC=3Dy
CONFIG_NETPOLL=3Dy
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=3Dy
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=3Dy
CONFIG_INPUT_FF_MEMLESS=3Dm
CONFIG_INPUT_POLLDEV=3Dm
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=3Dy
CONFIG_INPUT_MOUSEDEV_PSAUX=3Dy
CONFIG_INPUT_MOUSEDEV_SCREEN_X=3D1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=3D768
CONFIG_INPUT_JOYDEV=3Dm
CONFIG_INPUT_EVDEV=3Dm
CONFIG_INPUT_EVBUG=3Dm
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=3Dy
CONFIG_KEYBOARD_ATKBD=3Dy
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
CONFIG_KEYBOARD_XTKBD=3Dm
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
CONFIG_INPUT_MOUSE=3Dy
CONFIG_MOUSE_PS2=3Dy
CONFIG_MOUSE_PS2_ALPS=3Dy
CONFIG_MOUSE_PS2_LOGIPS2PP=3Dy
CONFIG_MOUSE_PS2_SYNAPTICS=3Dy
CONFIG_MOUSE_PS2_LIFEBOOK=3Dy
CONFIG_MOUSE_PS2_TRACKPOINT=3Dy
# 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=3Dy
CONFIG_JOYSTICK_ANALOG=3Dm
CONFIG_JOYSTICK_A3D=3Dm
CONFIG_JOYSTICK_ADI=3Dm
CONFIG_JOYSTICK_COBRA=3Dm
CONFIG_JOYSTICK_GF2K=3Dm
CONFIG_JOYSTICK_GRIP=3Dm
CONFIG_JOYSTICK_GRIP_MP=3Dm
CONFIG_JOYSTICK_GUILLEMOT=3Dm
CONFIG_JOYSTICK_INTERACT=3Dm
CONFIG_JOYSTICK_SIDEWINDER=3Dm
CONFIG_JOYSTICK_TMDC=3Dm
CONFIG_JOYSTICK_IFORCE=3Dm
CONFIG_JOYSTICK_IFORCE_USB=3Dy
CONFIG_JOYSTICK_IFORCE_232=3Dy
CONFIG_JOYSTICK_WARRIOR=3Dm
CONFIG_JOYSTICK_MAGELLAN=3Dm
CONFIG_JOYSTICK_SPACEORB=3Dm
CONFIG_JOYSTICK_SPACEBALL=3Dm
CONFIG_JOYSTICK_STINGER=3Dm
CONFIG_JOYSTICK_TWIDJOY=3Dm
CONFIG_JOYSTICK_DB9=3Dm
CONFIG_JOYSTICK_GAMECON=3Dm
CONFIG_JOYSTICK_TURBOGRAFX=3Dm
CONFIG_JOYSTICK_JOYDUMP=3Dm
CONFIG_JOYSTICK_XPAD=3Dm
CONFIG_JOYSTICK_XPAD_FF=3Dy
CONFIG_JOYSTICK_XPAD_LEDS=3Dy
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=3Dy
CONFIG_INPUT_PCSPKR=3Dm
# CONFIG_INPUT_ATLAS_BTNS is not set
# CONFIG_INPUT_ATI_REMOTE is not set
# CONFIG_INPUT_ATI_REMOTE2 is not set
# CONFIG_INPUT_KEYSPAN_REMOTE is not set
# CONFIG_INPUT_POWERMATE is not set
# CONFIG_INPUT_YEALINK is not set
CONFIG_INPUT_UINPUT=3Dm
#
# Hardware I/O ports
#
CONFIG_SERIO=3Dy
CONFIG_SERIO_I8042=3Dy
CONFIG_SERIO_SERPORT=3Dm
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
CONFIG_SERIO_PCIPS2=3Dm
CONFIG_SERIO_LIBPS2=3Dy
CONFIG_SERIO_RAW=3Dm
CONFIG_GAMEPORT=3Dm
CONFIG_GAMEPORT_NS558=3Dm
# CONFIG_GAMEPORT_L4 is not set
CONFIG_GAMEPORT_EMU10K1=3Dm
# CONFIG_GAMEPORT_FM801 is not set
#
# Character devices
#
CONFIG_VT=3Dy
CONFIG_VT_CONSOLE=3Dy
CONFIG_HW_CONSOLE=3Dy
CONFIG_VT_HW_CONSOLE_BINDING=3Dy
# CONFIG_SERIAL_NONSTANDARD is not set
#
# Serial drivers
#
CONFIG_SERIAL_8250=3Dm
CONFIG_FIX_EARLYCON_MEM=3Dy
CONFIG_SERIAL_8250_PCI=3Dm
CONFIG_SERIAL_8250_PNP=3Dm
CONFIG_SERIAL_8250_NR_UARTS=3D4
CONFIG_SERIAL_8250_RUNTIME_UARTS=3D4
CONFIG_SERIAL_8250_EXTENDED=3Dy
CONFIG_SERIAL_8250_MANY_PORTS=3Dy
CONFIG_SERIAL_8250_SHARE_IRQ=3Dy
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
CONFIG_SERIAL_8250_RSA=3Dy
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=3Dm
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=3Dy
# CONFIG_LEGACY_PTYS is not set
CONFIG_PRINTER=3Dm
# CONFIG_LP_CONSOLE is not set
# CONFIG_PPDEV is not set
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=3Dm
CONFIG_HW_RANDOM_INTEL=3Dm
CONFIG_HW_RANDOM_AMD=3Dm
CONFIG_NVRAM=3Dm
CONFIG_RTC=3Dm
CONFIG_GEN_RTC=3Dm
CONFIG_GEN_RTC_X=3Dy
# 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=3Dy
CONFIG_HPET_RTC_IRQ=3Dy
CONFIG_HPET_MMAP=3Dy
CONFIG_HANGCHECK_TIMER=3Dm
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set
CONFIG_DEVPORT=3Dy
CONFIG_I2C=3Dm
CONFIG_I2C_BOARDINFO=3Dy
CONFIG_I2C_CHARDEV=3Dm
#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=3Dm
CONFIG_I2C_ALGOPCF=3Dm
CONFIG_I2C_ALGOPCA=3Dm
#
# I2C Hardware Bus support
#
CONFIG_I2C_ALI1535=3Dm
CONFIG_I2C_ALI1563=3Dm
CONFIG_I2C_ALI15X3=3Dm
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_NFORCE2 is not set
CONFIG_I2C_OCORES=3Dm
CONFIG_I2C_PARPORT=3Dm
CONFIG_I2C_PARPORT_LIGHT=3Dm
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_TAOS_EVM is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_TINY_USB is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set
#
# Miscellaneous I2C Chip support
#
# CONFIG_SENSORS_DS1337 is not set
# CONFIG_SENSORS_DS1374 is not set
# CONFIG_DS1682 is not set
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_MAX6875 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set
#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
CONFIG_HWMON=3Dm
CONFIG_HWMON_VID=3Dm
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_ABITUGURU3 is not set
# CONFIG_SENSORS_AD7418 is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ADT7470 is not set
CONFIG_SENSORS_K8TEMP=3Dm
# 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 is not set
CONFIG_SENSORS_IT87=3Dm
# 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_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_W83627HF is not set
CONFIG_SENSORS_W83627EHF=3Dm
# CONFIG_SENSORS_HDAPS is not set
# CONFIG_SENSORS_APPLESMC is not set
# CONFIG_HWMON_DEBUG_CHIP is not set
# CONFIG_WATCHDOG is not set
#
# Sonics Silicon Backplane
#
CONFIG_SSB_POSSIBLE=3Dy
# CONFIG_SSB is not set
#
# Multifunction device drivers
#
# CONFIG_MFD_SM501 is not set
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
# CONFIG_DVB_CORE is not set
# CONFIG_DAB is not set
#
# Graphics support
#
CONFIG_AGP=3Dy
CONFIG_AGP_AMD64=3Dy
# CONFIG_AGP_INTEL is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_VIA is not set
CONFIG_DRM=3Dm
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set
CONFIG_VGASTATE=3Dm
CONFIG_VIDEO_OUTPUT_CONTROL=3Dm
CONFIG_FB=3Dm
# CONFIG_FIRMWARE_EDID is not set
CONFIG_FB_DDC=3Dm
CONFIG_FB_CFB_FILLRECT=3Dm
CONFIG_FB_CFB_COPYAREA=3Dm
CONFIG_FB_CFB_IMAGEBLIT=3Dm
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
# CONFIG_FB_SYS_FILLRECT is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_SYS_FOPS is not set
CONFIG_FB_DEFERRED_IO=3Dy
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
CONFIG_FB_BACKLIGHT=3Dy
CONFIG_FB_MODE_HELPERS=3Dy
# 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_VGA16 is not set
CONFIG_FB_UVESA=3Dm
# CONFIG_FB_HECUBA is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
CONFIG_FB_NVIDIA=3Dm
CONFIG_FB_NVIDIA_I2C=3Dy
# CONFIG_FB_NVIDIA_DEBUG is not set
CONFIG_FB_NVIDIA_BACKLIGHT=3Dy
# 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_GEODE is not set
# CONFIG_FB_VIRTUAL is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=3Dy
CONFIG_LCD_CLASS_DEVICE=3Dm
CONFIG_BACKLIGHT_CLASS_DEVICE=3Dm
# CONFIG_BACKLIGHT_CORGI is not set
# CONFIG_BACKLIGHT_PROGEAR is not set
#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=3Dy
# CONFIG_VGACON_SOFT_SCROLLBACK is not set
CONFIG_VIDEO_SELECT=3Dy
CONFIG_DUMMY_CONSOLE=3Dy
CONFIG_FRAMEBUFFER_CONSOLE=3Dm
# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
CONFIG_FONTS=3Dy
# CONFIG_FONT_8x8 is not set
CONFIG_FONT_8x16=3Dy
# CONFIG_FONT_6x11 is not set
# CONFIG_FONT_7x14 is not set
# CONFIG_FONT_PEARL_8x8 is not set
# CONFIG_FONT_ACORN_8x8 is not set
# CONFIG_FONT_MINI_4x6 is not set
# CONFIG_FONT_SUN8x16 is not set
# CONFIG_FONT_SUN12x22 is not set
# CONFIG_FONT_10x18 is not set
CONFIG_LOGO=3Dy
# CONFIG_LOGO_LINUX_MONO is not set
CONFIG_LOGO_LINUX_VGA16=3Dy
CONFIG_LOGO_LINUX_CLUT224=3Dy
#
# Sound
#
CONFIG_SOUND=3Dm
#
# Advanced Linux Sound Architecture
#
CONFIG_SND=3Dm
CONFIG_SND_TIMER=3Dm
CONFIG_SND_PCM=3Dm
CONFIG_SND_HWDEP=3Dm
CONFIG_SND_RAWMIDI=3Dm
CONFIG_SND_SEQUENCER=3Dm
CONFIG_SND_SEQ_DUMMY=3Dm
CONFIG_SND_OSSEMUL=3Dy
CONFIG_SND_MIXER_OSS=3Dm
CONFIG_SND_PCM_OSS=3Dm
CONFIG_SND_PCM_OSS_PLUGINS=3Dy
CONFIG_SND_SEQUENCER_OSS=3Dy
CONFIG_SND_RTCTIMER=3Dm
CONFIG_SND_SEQ_RTCTIMER_DEFAULT=3Dy
# CONFIG_SND_DYNAMIC_MINORS is not set
CONFIG_SND_SUPPORT_OLD_API=3Dy
# CONFIG_SND_VERBOSE_PROCFS is not set
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
#
# Generic devices
#
CONFIG_SND_MPU401_UART=3Dm
CONFIG_SND_OPL3_LIB=3Dm
CONFIG_SND_AC97_CODEC=3Dm
CONFIG_SND_DUMMY=3Dm
CONFIG_SND_VIRMIDI=3Dm
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_MTS64 is not set
# CONFIG_SND_SERIAL_U16550 is not set
CONFIG_SND_MPU401=3Dm
# CONFIG_SND_PORTMAN2X4 is not set
CONFIG_SND_SB_COMMON=3Dm
CONFIG_SND_SB16_DSP=3Dm
#
# PCI devices
#
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
CONFIG_SND_ALI5451=3Dm
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
CONFIG_SND_CA0106=3Dm
CONFIG_SND_CMIPCI=3Dm
CONFIG_SND_CS4281=3Dm
CONFIG_SND_CS46XX=3Dm
CONFIG_SND_CS46XX_NEW_DSP=3Dy
CONFIG_SND_CS5530=3Dm
# 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=3Dm
CONFIG_SND_EMU10K1X=3Dm
CONFIG_SND_ENS1370=3Dm
CONFIG_SND_ENS1371=3Dm
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_FM801 is not set
CONFIG_SND_HDA_INTEL=3Dm
# CONFIG_SND_HDA_HWDEP is not set
CONFIG_SND_HDA_CODEC_REALTEK=3Dy
# 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=3Dy
CONFIG_SND_HDA_POWER_SAVE=3Dy
CONFIG_SND_HDA_POWER_SAVE_DEFAULT=3D0
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
CONFIG_SND_INTEL8X0=3Dm
CONFIG_SND_INTEL8X0M=3Dm
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_PCXHR is not set
# CONFIG_SND_RIPTIDE is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_AC97_POWER_SAVE is not set
#
# USB devices
#
# CONFIG_SND_USB_AUDIO is not set
# CONFIG_SND_USB_USX2Y is not set
# CONFIG_SND_USB_CAIAQ is not set
#
# System on Chip audio support
#
# CONFIG_SND_SOC is not set
#
# SoC Audio support for SuperH
#
#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set
CONFIG_AC97_BUS=3Dm
CONFIG_HID_SUPPORT=3Dy
CONFIG_HID=3Dy
# CONFIG_HID_DEBUG is not set
CONFIG_HIDRAW=3Dy
#
# USB Input Devices
#
CONFIG_USB_HID=3Dm
# CONFIG_USB_HIDINPUT_POWERBOOK is not set
CONFIG_HID_FF=3Dy
CONFIG_HID_PID=3Dy
CONFIG_LOGITECH_FF=3Dy
# CONFIG_PANTHERLORD_FF is not set
CONFIG_THRUSTMASTER_FF=3Dy
CONFIG_ZEROPLUS_FF=3Dy
CONFIG_USB_HIDDEV=3Dy
#
# USB HID Boot Protocol drivers
#
CONFIG_USB_KBD=3Dm
CONFIG_USB_MOUSE=3Dm
CONFIG_USB_SUPPORT=3Dy
CONFIG_USB_ARCH_HAS_HCD=3Dy
CONFIG_USB_ARCH_HAS_OHCI=3Dy
CONFIG_USB_ARCH_HAS_EHCI=3Dy
CONFIG_USB=3Dm
# CONFIG_USB_DEBUG is not set
#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=3Dy
CONFIG_USB_DEVICE_CLASS=3Dy
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_SUSPEND is not set
# CONFIG_USB_PERSIST is not set
# CONFIG_USB_OTG is not set
#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=3Dm
CONFIG_USB_EHCI_SPLIT_ISO=3Dy
CONFIG_USB_EHCI_ROOT_HUB_TT=3Dy
CONFIG_USB_EHCI_TT_NEWSCHED=3Dy
# CONFIG_USB_ISP116X_HCD is not set
CONFIG_USB_OHCI_HCD=3Dm
# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=3Dy
# CONFIG_USB_UHCI_HCD is not set
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
#
# USB Device Class drivers
#
CONFIG_USB_ACM=3Dm
CONFIG_USB_PRINTER=3Dm
#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#
#
# may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=3Dm
# 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_KARMA is not set
CONFIG_USB_LIBUSUAL=3Dy
#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
CONFIG_USB_MON=3Dy
#
# USB port drivers
#
# CONFIG_USB_USS720 is not set
#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set
#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_BERRY_CHARGE is not set
CONFIG_USB_LED=3Dm
# 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=3Dm
CONFIG_USB_TRANCEVIBRATOR=3Dm
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
#
# USB DSL modem support
#
CONFIG_USB_ATM=3Dm
CONFIG_USB_SPEEDTOUCH=3Dm
# CONFIG_USB_CXACRU is not set
# CONFIG_USB_UEAGLEATM is not set
# CONFIG_USB_XUSBATM is not set
#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
# CONFIG_MMC is not set
CONFIG_NEW_LEDS=3Dy
CONFIG_LEDS_CLASS=3Dm
#
# LED drivers
#
#
# LED Triggers
#
CONFIG_LEDS_TRIGGERS=3Dy
CONFIG_LEDS_TRIGGER_TIMER=3Dm
CONFIG_LEDS_TRIGGER_HEARTBEAT=3Dm
# CONFIG_INFINIBAND is not set
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=3Dm
CONFIG_RTC_CLASS=3Dm
#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=3Dy
CONFIG_RTC_INTF_PROC=3Dy
CONFIG_RTC_INTF_DEV=3Dy
CONFIG_RTC_INTF_DEV_UIE_EMUL=3Dy
CONFIG_RTC_DRV_TEST=3Dm
#
# I2C RTC drivers
#
CONFIG_RTC_DRV_DS1307=3Dm
# CONFIG_RTC_DRV_DS1374 is not set
CONFIG_RTC_DRV_DS1672=3Dm
CONFIG_RTC_DRV_MAX6900=3Dm
CONFIG_RTC_DRV_RS5C372=3Dm
CONFIG_RTC_DRV_ISL1208=3Dm
CONFIG_RTC_DRV_X1205=3Dm
CONFIG_RTC_DRV_PCF8563=3Dm
CONFIG_RTC_DRV_PCF8583=3Dm
# CONFIG_RTC_DRV_M41T80 is not set
#
# SPI RTC drivers
#
#
# Platform RTC drivers
#
CONFIG_RTC_DRV_CMOS=3Dm
CONFIG_RTC_DRV_DS1553=3Dm
# CONFIG_RTC_DRV_STK17TA8 is not set
CONFIG_RTC_DRV_DS1742=3Dm
CONFIG_RTC_DRV_M48T86=3Dm
# CONFIG_RTC_DRV_M48T59 is not set
CONFIG_RTC_DRV_V3020=3Dm
#
# on-CPU RTC drivers
#
# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
CONFIG_VIRTUALIZATION=3Dy
CONFIG_KVM=3Dm
# CONFIG_KVM_INTEL is not set
CONFIG_KVM_AMD=3Dm
#
# Userspace I/O
#
# CONFIG_UIO is not set
#
# Firmware Drivers
#
# CONFIG_EDD is not set
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
# CONFIG_DMIID is not set
#
# File systems
#
CONFIG_EXT2_FS=3Dy
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=3Dm
CONFIG_EXT3_FS_XATTR=3Dy
CONFIG_EXT3_FS_POSIX_ACL=3Dy
CONFIG_EXT3_FS_SECURITY=3Dy
# CONFIG_EXT4DEV_FS is not set
CONFIG_JBD=3Dm
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=3Dy
# CONFIG_REISERFS_FS is not set
CONFIG_JFS_FS=3Dy
CONFIG_JFS_POSIX_ACL=3Dy
CONFIG_JFS_SECURITY=3Dy
# CONFIG_JFS_DEBUG is not set
CONFIG_JFS_STATISTICS=3Dy
CONFIG_FS_POSIX_ACL=3Dy
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_INOTIFY=3Dy
CONFIG_INOTIFY_USER=3Dy
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=3Dy
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
CONFIG_FUSE_FS=3Dm
#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=3Dm
CONFIG_JOLIET=3Dy
CONFIG_ZISOFS=3Dy
CONFIG_UDF_FS=3Dm
CONFIG_UDF_NLS=3Dy
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=3Dm
CONFIG_MSDOS_FS=3Dm
CONFIG_VFAT_FS=3Dm
CONFIG_FAT_DEFAULT_CODEPAGE=3D850
CONFIG_FAT_DEFAULT_IOCHARSET=3D"iso8859-1"
CONFIG_NTFS_FS=3Dm
# CONFIG_NTFS_DEBUG is not set
CONFIG_NTFS_RW=3Dy
#
# Pseudo filesystems
#
CONFIG_PROC_FS=3Dy
CONFIG_PROC_KCORE=3Dy
CONFIG_PROC_SYSCTL=3Dy
CONFIG_SYSFS=3Dy
CONFIG_TMPFS=3Dy
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_CONFIGFS_FS=3Dm
#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
CONFIG_ECRYPT_FS=3Dm
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_CRAMFS=3Dy
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=3Dy
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_SMB_FS is not set
CONFIG_CIFS=3Dm
CONFIG_CIFS_STATS=3Dy
# CONFIG_CIFS_STATS2 is not set
CONFIG_CIFS_WEAK_PW_HASH=3Dy
CONFIG_CIFS_XATTR=3Dy
CONFIG_CIFS_POSIX=3Dy
# CONFIG_CIFS_DEBUG2 is not set
# CONFIG_CIFS_EXPERIMENTAL is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
CONFIG_9P_FS=3Dm
#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=3Dy
# 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=3Dy
# 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=3Dy
CONFIG_LDM_DEBUG=3Dy
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
CONFIG_KARMA_PARTITION=3Dy
CONFIG_EFI_PARTITION=3Dy
# CONFIG_SYSV68_PARTITION is not set
CONFIG_NLS=3Dy
CONFIG_NLS_DEFAULT=3D"cp850"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=3Dm
# 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=3Dm
# 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=3Dm
# CONFIG_NLS_ISO8859_2 is not set
CONFIG_NLS_ISO8859_3=3Dm
# 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=3Dm
CONFIG_NLS_ISO8859_15=3Dm
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=3Dm
# CONFIG_DLM is not set
CONFIG_INSTRUMENTATION=3Dy
# CONFIG_PROFILING is not set
# CONFIG_KPROBES is not set
# CONFIG_MARKERS is not set
#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=3Dy
CONFIG_PRINTK_TIME=3Dy
CONFIG_ENABLE_WARN_DEPRECATED=3Dy
CONFIG_ENABLE_MUST_CHECK=3Dy
CONFIG_MAGIC_SYSRQ=3Dy
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=3Dy
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_KERNEL=3Dy
CONFIG_DEBUG_SHIRQ=3Dy
CONFIG_DETECT_SOFTLOCKUP=3Dy
CONFIG_SCHED_DEBUG=3Dy
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
# CONFIG_SLUB_DEBUG_ON 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_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=3Dy
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_FRAME_POINTER is not set
# CONFIG_FORCED_INLINING is not set
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_SAMPLES is not set
CONFIG_EARLY_PRINTK=3Dy
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_RODATA is not set
# CONFIG_IOMMU_DEBUG is not set
#
# Security options
#
CONFIG_KEYS=3Dy
CONFIG_KEYS_DEBUG_PROC_KEYS=3Dy
CONFIG_SECURITY=3Dy
CONFIG_SECURITY_NETWORK=3Dy
CONFIG_SECURITY_NETWORK_XFRM=3Dy
CONFIG_SECURITY_CAPABILITIES=3Dy
# CONFIG_SECURITY_FILE_CAPABILITIES is not set
CONFIG_CRYPTO=3Dy
CONFIG_CRYPTO_ALGAPI=3Dm
CONFIG_CRYPTO_ABLKCIPHER=3Dm
CONFIG_CRYPTO_AEAD=3Dm
CONFIG_CRYPTO_BLKCIPHER=3Dm
CONFIG_CRYPTO_HASH=3Dm
CONFIG_CRYPTO_MANAGER=3Dm
CONFIG_CRYPTO_HMAC=3Dm
CONFIG_CRYPTO_XCBC=3Dm
CONFIG_CRYPTO_NULL=3Dm
CONFIG_CRYPTO_MD4=3Dm
CONFIG_CRYPTO_MD5=3Dm
CONFIG_CRYPTO_SHA1=3Dm
CONFIG_CRYPTO_SHA256=3Dm
CONFIG_CRYPTO_SHA512=3Dm
CONFIG_CRYPTO_WP512=3Dm
CONFIG_CRYPTO_TGR192=3Dm
CONFIG_CRYPTO_GF128MUL=3Dm
CONFIG_CRYPTO_ECB=3Dm
CONFIG_CRYPTO_CBC=3Dm
CONFIG_CRYPTO_PCBC=3Dm
CONFIG_CRYPTO_LRW=3Dm
CONFIG_CRYPTO_XTS=3Dm
CONFIG_CRYPTO_CRYPTD=3Dm
CONFIG_CRYPTO_DES=3Dm
CONFIG_CRYPTO_FCRYPT=3Dm
CONFIG_CRYPTO_BLOWFISH=3Dm
CONFIG_CRYPTO_TWOFISH=3Dm
CONFIG_CRYPTO_TWOFISH_COMMON=3Dm
CONFIG_CRYPTO_TWOFISH_X86_64=3Dm
CONFIG_CRYPTO_SERPENT=3Dm
CONFIG_CRYPTO_AES=3Dm
CONFIG_CRYPTO_AES_X86_64=3Dm
CONFIG_CRYPTO_CAST5=3Dm
CONFIG_CRYPTO_CAST6=3Dm
CONFIG_CRYPTO_TEA=3Dm
CONFIG_CRYPTO_ARC4=3Dm
CONFIG_CRYPTO_KHAZAD=3Dm
CONFIG_CRYPTO_ANUBIS=3Dm
CONFIG_CRYPTO_SEED=3Dm
CONFIG_CRYPTO_DEFLATE=3Dm
CONFIG_CRYPTO_MICHAEL_MIC=3Dm
CONFIG_CRYPTO_CRC32C=3Dm
CONFIG_CRYPTO_CAMELLIA=3Dm
# CONFIG_CRYPTO_TEST is not set
CONFIG_CRYPTO_AUTHENC=3Dm
# CONFIG_CRYPTO_HW is not set
#
# Library routines
#
CONFIG_BITREVERSE=3Dy
CONFIG_CRC_CCITT=3Dm
CONFIG_CRC16=3Dm
CONFIG_CRC_ITU_T=3Dm
CONFIG_CRC32=3Dy
CONFIG_CRC7=3Dm
CONFIG_LIBCRC32C=3Dm
CONFIG_ZLIB_INFLATE=3Dy
CONFIG_ZLIB_DEFLATE=3Dm
CONFIG_TEXTSEARCH=3Dy
CONFIG_TEXTSEARCH_KMP=3Dm
CONFIG_TEXTSEARCH_BM=3Dm
CONFIG_TEXTSEARCH_FSM=3Dm
CONFIG_PLIST=3Dy
CONFIG_HAS_IOMEM=3Dy
CONFIG_HAS_IOPORT=3Dy
CONFIG_HAS_DMA=3Dy
On Fri, 25 Jan 2008, Johannes Berg wrote:
>
> Since the only problematic driver is Intel's, they really should be able
> to get their act together for .25 and fix their firmware, if not then
> we'll have to think of something else like making their drivers
> memmove() the packets to the right place.
Well, there *is* a really simple solution:
- realize that x86 (along with some few other architectures) is sane, and
not a crapola architecture that cannot do unaligneds well.
The thing is, not handling unaligned data well (and by "well", I don't
mean just "without a trap", but "fast") is a problem for _other_
architectures, not x86. And quite frankly, x86 is not only the bulk of the
machines out there, in this area it's also the one that did the right
thing.
[ Lots of people think that x86 is ugly. The fact is, x86 is a paragon of
cleanliness when it comes to all the details that matter. When it comes
to ugly, the *really* ugly things is not in some complex ISA decoding,
but in all the horrible crap other architectures forces software to do
unnecessarily, when hardware can do it so much better! ]
So I would actually suggest that the wireless people realize that
unaligned accesses aren't necessarily bad, and if there is code that needs
alignment, maybe it's the *crap* architectures that should pay the price,
not the good ones?
So I would suggest replacing that WARN_ON_ONCE() (which is gone now, but
never mind, it marks the spot) with one of:
- mark the header data structure unaligned, so that gcc will
automatically generate the extra instructions to do the accesses
automatically.
- .. or, if there are just a few ones that actually matter, use
"get_unaligned()" in those places
- .. or just make the WARN_ON_ONCE() be dependent on the broken
architecture in the first place.
- .. or, finally, do something that penalizes crap and does
#ifdef CONFIG_ARCH_NEEDS_ALIGNED
#define STRICT_ARCH_MINIMUM_ALIGNMENT alignof(..)
#else
#define STRICT_ARCH_MINIMUM_ALIGNMENT 1
#endif
...
unsigned long unalign;
..
unaligned = (unsigned long) ptr & (STRICT_ARCH_MINIMUM_ALIGNMENT-1);
if (unaligned) {
void *newptr = ptr;
WARN_ON_ONCE(1);
/* This assumes we have padding */
newptr += STRICT_ARCH_MINIMUM_ALIGNMENT - unaligned;
memmove(newptr, ptr, size);
}
..
because the thing is, we should give Intel credit for doing the right
thing (in the CPU), rather than complain about the fact that they don't
care about insane architectures that do the wrong thing and can't even
work with the wireless driver in the first place!
Linus
Linus Torvalds wrote:
>
> On Fri, 25 Jan 2008, Michael Buesch wrote:
>> The problem is _not_ the wireless header access, but the alignment of the embedded
>> protocol stack, if the header does not have a size aligned to 4.
>> Do we want to clutter the whole networking stack below wireless with
>> get_unaligned() or attribute(packed) or something like that?
>
> That's what all the other protocols do, isn't it?
>
> For example, on PowerPC, NET_IP_ALIGN is 0 - explicitly so that the *dma*
> from the card should be aligned, even if that in turn means that the IP
> payload itself is then just two-byte aligned rather than word-aligned
> (14-byte ethernet headers and all that).
>
> [ Side note - I _used_ to know the networking code. That was about eight
> to ten years ago. I'm really happy having a maintainer for it and not
> having to know all the details any more, so maybe things have changed. ]
>
> I do think that we generally should try to make the drivers do as little
> complex stuff as humanly possible, and expect as little from hardware (and
> firmware counts in that group) as we can. If some higher-level thing
> really needs things aligned in order to not have to have lots of ugly
> code, it should generally extract that alignment itself.
Actually... grep for rx_copybreak in networking drivers.
For certain ethernet NIC hardware, given standard packet headers, your
data will always be unaligned, which -does- have a cost, even on Intel.
On such hardware, this is required because the RX packet must start on
a 32-bit (sometimes 64-bit) DMA boundary.
Since RX SKBs are pre-allocated, we use the driver-wide 'rx_copybreak'
variable to determine the point at which an unaligned packet is painful
enough that we should copy into a newly allocated, properly aligned skb
(NET_IP_ALIGN, etc.)
Sane architectures can set rx_copybreak to MTU size. Other
architectures (at compile time) set the rx_copybreak default to
something smaller.
Jeff
On Jan 25, 2008 11:46 PM, John W. Linville <[email protected]> wrote:
> On Fri, Jan 25, 2008 at 10:21:07PM +0100, Michael Buesch wrote:
> > On Friday 25 January 2008 22:11:44 Inaky Perez-Gonzalez wrote:
> > > On Friday 25 January 2008, Michael Buesch wrote:
> > > > On Friday 25 January 2008 19:34:46 Linus Torvalds wrote:
> > > > > My attitude is: CPU's that do unaligned accesses right are the *good*
> > > > > CPU's. We should encourage them, and put the onus of being crap on the
> > > > > ones that are crap, rather than penalizing the ones that aren't.
> > > >
> > > > I absolutely agree. But as this can get fixed with _no_ performance loss
> > > > at all inside of the firmware (and who if not intel can change stuff
> > > > in their firmware?), I think this warning is in fact valid.
> > >
> > > Well, you forgot the point that maybe it is not that simple to get such
> > > a seemingly simple change into the firmware for a long list of reasons.
> >
> > The reasons being?
>
> Firmware certification is expensive.
>
> Plus it is a bit unfair to ask for firmware changes just because the
> vendor is actually engaged with us. If this were Broadcom or Zydas
> firmware we would have little recourse other than to accept it or
> fix it in the driver or stack.
>
> John
> --
> John W. Linville
> [email protected]
>
Sorry for getting late into this conversation till now I was enjoying
my weekend :)
We are definitely not ignoring this issue. We are discussing this at
Intel and this for sure will be fixed in next generation HW. For now
we are trying to find some remedy to this problem. The big problem we
have that 11n handling is HW assisted and it's really hard to do
something about it in the FW level for 11n cards. This is not
something that we fix over night if at all. The truth is these cards
never dreamed to be run on other CPUs then Intel so the morning is
hard :)
I would suggest to go for conditional copying on platforms that cannot
handle unaligned for these platforms we have to probably disable 11n
though.
Tomas
> -
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Fri, 25 Jan 2008, Linus Torvalds wrote:
>
> But complaining about a vendor who does a good job technically, for
> non-technical reasons, I really don't see that as being fine.
Side note: I also think the wireless parts here are doing things wrong.
Why _would_ you care about alignment? We used to have issues like that in
the normal networking code, and it was a mistake there too. Why isn't the
wireless stack just extracting the header explicitly, or using
"get_unaligned()" like regular networking?
With ethernet, there were chips that could only do DMA at certain
alignments etc, together with various other headers being involved, making
it impossible to require alignment without memcpy(), and I don't think
we've had any issues there.
People have to add in the proper "get_unaligned()" calls that they forgot
or didn't think about to various pieces every once in a while, but on most
platforms you get a nice warning when something isn't doing the right
thing (I think some borken ARM cores are the exception and will just
silently do the wrong thing entirely).
So it's not like this is a new issue, and I can't recall us ever before
having ended up requiring alignment when it hit us.
Linus
From: Linus Torvalds <[email protected]>
Date: Fri, 25 Jan 2008 13:56:15 -0800 (PST)
>
>
> On Fri, 25 Jan 2008, John W. Linville wrote:
> >
> > Anyway, this is mostly just so we can scope the driver change required
> > in absence of a firmware change. Persumably the changes required if
> > we were to put such code in mac80211 would be similar.
>
> Make this conditional on archictures that need it, please.
>
> And why is it suddenly smart to do this in three drivers rather than one
> upper layer?
>
Grep the ethernet drivers Linus, we've been doing this since
the Donald Becker era.
The ones that cannot provide the necessary alignment copy on
platforms that cannot handle it without traps.
From: Inaky Perez-Gonzalez <[email protected]>
Date: Fri, 25 Jan 2008 13:28:35 -0800
> For example: want to ship new firmware, drivers *and* full validation and
> certification for a product that is already completed just to satisfy a
> fraction of a market which is not part of the designed target?
>
> Do you know how much money that costs?
I'm glad you guys are the only one's with access to the firmware
source, thus enduring that you can constantly come up with reasons
like this in order to not have to fix the problem.
You know that if the source were available, the community would have
fixed the bug ages ago.
But the situation is entirely in Intel's control which is surely
exactly the way they like it.
On Friday 25 January 2008, Michael Buesch wrote:
> On Friday 25 January 2008 22:11:44 Inaky Perez-Gonzalez wrote:
> > On Friday 25 January 2008, Michael Buesch wrote:
> > > On Friday 25 January 2008 19:34:46 Linus Torvalds wrote:
> > > > My attitude is: CPU's that do unaligned accesses right are the *good*
> > > > CPU's. We should encourage them, and put the onus of being crap on the
> > > > ones that are crap, rather than penalizing the ones that aren't.
> > >
> > > I absolutely agree. But as this can get fixed with _no_ performance loss
> > > at all inside of the firmware (and who if not intel can change stuff
> > > in their firmware?), I think this warning is in fact valid.
> >
> > Well, you forgot the point that maybe it is not that simple to get such
> > a seemingly simple change into the firmware for a long list of reasons.
>
> The reasons being?
For example: want to ship new firmware, drivers *and* full validation and
certification for a product that is already completed just to satisfy a
fraction of a market which is not part of the designed target?
Do you know how much money that costs?
I'll be happy to eat my words without any ketchup and mustard if it happens,
btw, but I don't think it will [and I am speaking for myself, not for Intel,
when saying this].
On Fri, 25 Jan 2008, Dan Williams wrote:
>
> Does Intel need to make iwlwifi and ipw2x00 work reliably on platforms
> other than x86? Or don't they?
Why should they?
If somebody else takes over maintenance, because Intel does a bad job,
that's fine.
If somebody else sends in patches and they get accepted "around" Intel,
that's obviously also fine.
But complaining about a vendor who does a good job technically, for
non-technical reasons, I really don't see that as being fine.
Is it even physically *possible* to use that Intel wireless chipset with
anything but x86 CPU's (not just that, but actually _Intel_ x86 CPU's)?
And would it make any sense what-so-ever even if it was?
And yes, portability is a great thing, but quite frankly, so is good
hardware. I personally can't really blame Intel engineers for not caring
about irrelevant hardware.
We should make technical decisions on _technical_ grounds, not some
perceived "this is how the world should work" grounds.
Linus
On 1/26/08, John W. Linville <[email protected]> wrote:
> On Fri, Jan 25, 2008 at 01:56:15PM -0800, Linus Torvalds wrote:
> > And why is it suddenly smart to do this in three drivers rather than one
> > upper layer?
>
> Two drivers, FWIW... :-)
IMO, The right place to put a conditional memmove is at the 802.11 to
802.3 conversion. currnetly iwlwifi always hands an aligned 802.11
frame to mac80211. If it is needed to re-align the frame after
stripping the odd 802.11 header to support CPUs that can't handle it,
it makes sense to do it there.
> John
From: Linus Torvalds <[email protected]>
Date: Sat, 26 Jan 2008 23:54:18 -0800 (PST)
> Wouldn't it be nice to just handle the MTU memory accounting issue at the
> network level too?
If the driver does it, it can immediately recycle the packet back into
the RX ring without all the overhead of freeing it and then allocating
it all over again.
It can also avoid all of the DMA map/unmap operations as well.
(you can copy and entire packet in the time a PIO operation
to some of these IOMMU chips can take)
Moving all of this into netif_receive_skb() would be great for
centralization of logic, but I would not advocate it specifically
because it makes the drivers etc. do a lot of wasteful work.
On Fri, Jan 25, 2008 at 10:21:07PM +0100, Michael Buesch wrote:
> On Friday 25 January 2008 22:11:44 Inaky Perez-Gonzalez wrote:
> > On Friday 25 January 2008, Michael Buesch wrote:
> > > On Friday 25 January 2008 19:34:46 Linus Torvalds wrote:
> > > > My attitude is: CPU's that do unaligned accesses right are the *good*
> > > > CPU's. We should encourage them, and put the onus of being crap on the
> > > > ones that are crap, rather than penalizing the ones that aren't.
> > >
> > > I absolutely agree. But as this can get fixed with _no_ performance loss
> > > at all inside of the firmware (and who if not intel can change stuff
> > > in their firmware?), I think this warning is in fact valid.
> >
> > Well, you forgot the point that maybe it is not that simple to get such
> > a seemingly simple change into the firmware for a long list of reasons.
>
> The reasons being?
Firmware certification is expensive.
Plus it is a bit unfair to ask for firmware changes just because the
vendor is actually engaged with us. If this were Broadcom or Zydas
firmware we would have little recourse other than to accept it or
fix it in the driver or stack.
John
--
John W. Linville
[email protected]
On Monday 07 January 2008 17:52:48 Alejandro Riveira Fern=C3=A1ndez wro=
te:
> El Mon, 7 Jan 2008 17:24:03 +0100
> Michael Buesch <[email protected]> escribi=C3=B3:
>=20
> =
=20
> >=20
> > Can you post the lines above this?
> > This might be a WARN_ON_ONCE() triggering, for which fixes are on t=
heir way into
> > the wireless-2.6 tree.
>=20
> This?
>=20
>=20
> [ 37.043990] WARNING: at /home/alex/kernel/linux-2.6/net/mac80211/r=
x.c:1486 __ieee80211_rx()=20
> [ 37.043996] Pid: 0, comm: swapper Not tainted 2.6.24-rc7 #3 =
=20
> [ 37.043998] =
=20
> [ 37.043999] Call Trace: =
=20
> [ 37.044001] <IRQ> [<ffffffff80227fe3>] enqueue_task+0x13/0x30 =
=20
> [ 37.044040] [<ffffffff88178cbe>] :mac80211:__ieee80211_rx+0xc7e/0=
xd30 =20
> [ 37.044044] [<ffffffff80228062>] activate_task+0x32/0x50 =
=20
> [ 37.044073] [<ffffffff8816a28b>] :mac80211:ieee80211_tasklet_hand=
ler+0xbb/0x120 =20
> [ 37.044086] [<ffffffff80238d08>] tasklet_action+0x48/0xb0 =
=20
> [ 37.044091] [<ffffffff80238c09>] __do_softirq+0x69/0xe0 =
=20
> [ 37.044097] [<ffffffff8020ce2c>] call_softirq+0x1c/0x30 =
=20
> [ 37.044101] [<ffffffff8020efe5>] do_softirq+0x35/0x90 =
=20
> [ 37.044105] [<ffffffff80238aa5>] irq_exit+0x95/0xa0 =
=20
> [ 37.044108] [<ffffffff8020f0c0>] do_IRQ+0x80/0x100 =
=20
> [ 37.044111] [<ffffffff8020a840>] default_idle+0x0/0x40 =
=20
> [ 37.044115] [<ffffffff8020c181>] ret_from_intr+0x0/0xa =
=20
> [ 37.044117] <EOI> [<ffffffff8020a869>] default_idle+0x29/0x40 =
=20
> [ 37.044130] [<ffffffff8020a8f5>] cpu_idle+0x75/0xc0 =
=20
> [ 37.044146] =
=20
Can you check if that is the
WARN_ON_ONCE(((unsigned long)(skb->data + hdrlen)) & 3);
in rx.c line 1486?
If that is the one, then fixes are already on their way upstream.
Ignore the harmless warning for now.
--=20
Greetings Michael.
On Fri, 2008-01-25 at 08:43 -0800, Linus Torvalds wrote:
>
> On Fri, 25 Jan 2008, Michael Buesch wrote:
> >
> > If we are talking about what's sane or not...
> > It's trivial to fix this in the firmware, like sane vendors like
> > Broadcom do.
>
> You just showed your total disregard for any sanity by calling broadcom
> "sane".
>
> Quite frankly, Broadcom is probably the single worst chip manufacturer in
> terms of both bugginess of the silicon itself and in terms of lack of
> support.
>
> > Architectures that can't do unaligned access are heavily used in
> > wireless embedded routers. So we are not going to pay a huge
> > price there so just one vendor doesn't have to fix his firmware.
>
> .. and you also showed that you didn't even read my email and the options
> I outlined. The fact is, the Intel wireless chipset only works with x86
> CPU's. There is absolutely zero "price" on crap CPU's, because they are
> simply not relevant to this driver.
Except that some kernel developers (not you) have made noise about
requiring Intel to ensure their hardware and drivers work on platforms
that they are unlikely ever to work on. There was resistance to merging
iwlwifi because it wasn't quite endian-safe at the time (even though
99.99% of iwl3945 and 4965 cards will be on x86) and Intel's track
record in not endian-safing ipw2200 and ipw2100 was brought up.
Eventually Intel developers did go through and try to do the correct
sparse annotations and endian conversions and the driver got merged.
Does Intel need to make iwlwifi and ipw2x00 work reliably on platforms
other than x86? Or don't they?
Dan
On Saturday 26 January 2008, David Miller wrote:
> From: Inaky Perez-Gonzalez <[email protected]>
> Date: Fri, 25 Jan 2008 13:28:35 -0800
>
> > For example: want to ship new firmware, drivers *and* full validation and
> > certification for a product that is already completed just to satisfy a
> > fraction of a market which is not part of the designed target?
> >
> > Do you know how much money that costs?
>
> I'm glad you guys are the only one's with access to the firmware
> source, thus enduring that you can constantly come up with reasons
> like this in order to not have to fix the problem.
At the risk of falling into your game, let me reiterate what I said
above, as you don't seem to have taken it into acount:
want to ship new firmware, drivers *and* full validation and
certification for a product that is already completed just to satisfy a
fraction of a market which is not part of the designed target?
Do you know how much money that costs?
Maybe there is somewhere someone willing to pony up all the the money
needed to get all that started and done, but we are not in that position,
so in those cases, we need to do some kind of software arrangement.
But even still, cref to some of Linus's message in this thread: that doesn't
mean people would use it. Workaround broken stuff because it is there already
and ask for the vendor to fix things.
We listen, participate, release code and we try hard to get the stuff right
in current releases when doable, in future as much as possible. It doesn't
help anyone when you just go about ripping us senseless.
> You know that if the source were available, the community would have
> fixed the bug ages ago.
>
> But the situation is entirely in Intel's control which is surely
> exactly the way they like it.
Do you have the (open) source to any wireless card firmware? I'd be
curious to know, because I (personally) don't know how can you do an
open source firmware for a software defined radio without the FCC
denying you a license. No license, no product. No product, no need to
even have this discussion... :)
On Friday 25 January 2008 17:08:51 Linus Torvalds wrote:
>
> On Fri, 25 Jan 2008, Johannes Berg wrote:
> >
> > Since the only problematic driver is Intel's, they really should be able
> > to get their act together for .25 and fix their firmware, if not then
> > we'll have to think of something else like making their drivers
> > memmove() the packets to the right place.
>
> Well, there *is* a really simple solution:
>
> - realize that x86 (along with some few other architectures) is sane, and
> not a crapola architecture that cannot do unaligneds well.
...
> because the thing is, we should give Intel credit for doing the right
> thing (in the CPU), rather than complain about the fact that they don't
> care about insane architectures that do the wrong thing and can't even
> work with the wireless driver in the first place!
If we are talking about what's sane or not...
It's trivial to fix this in the firmware, like sane vendors like
Broadcom do.
Architectures that can't do unaligned access are heavily used in
wireless embedded routers. So we are not going to pay a huge
price there so just one vendor doesn't have to fix his firmware.
--
Greetings Michael.
On Sat, 26 Jan 2008, David Miller wrote:
>
> The socket gets charged for a full MTU's amount of memory instead
> of something more on the order of 100 bytes :-)
>
> In fact that is the original reason all of these things exists,
> it was just simple to extend it to handle alignment cases too.
>
> Anyways, once we put the logic for unaligned handling into a
> centralized location the above can now evaluate to a constant,
> or default to the lower value of 100.
Wouldn't it be nice to just handle the MTU memory accounting issue at the
network level too?
Make the rule simply be:
- if the packet allocation is *much* bigger than the packet length
itself (eg 20-byte IP packet bytes in a 1536-byte allocation),
OR
- if the packet data is badly aligned AND (packet is small and can be
just moved in place OR architecture requires alignment)
then copy the packet data into a new allocation (or preferably reuse the
old allocation if the size is appropriate and you can tell from the
refcount that nobody else has a pointer to it - I forget the exact rules
for this all).
The fact that the new allocation would be aligned is obviously one of the
benefits, but as you point out, it's not the only one.
Linus
On Friday 25 January 2008 20:07:47 Linus Torvalds wrote:
>
> On Fri, 25 Jan 2008, Michael Buesch wrote:
> >
> > The problem is _not_ the wireless header access, but the alignment of the embedded
> > protocol stack, if the header does not have a size aligned to 4.
> > Do we want to clutter the whole networking stack below wireless with
> > get_unaligned() or attribute(packed) or something like that?
>
> That's what all the other protocols do, isn't it?
>
> For example, on PowerPC, NET_IP_ALIGN is 0 - explicitly so that the *dma*
> from the card should be aligned, even if that in turn means that the IP
> payload itself is then just two-byte aligned rather than word-aligned
> (14-byte ethernet headers and all that).
>
> [ Side note - I _used_ to know the networking code. That was about eight
> to ten years ago. I'm really happy having a maintainer for it and not
> having to know all the details any more, so maybe things have changed. ]
>
> I do think that we generally should try to make the drivers do as little
> complex stuff as humanly possible, and expect as little from hardware (and
> firmware counts in that group) as we can. If some higher-level thing
> really needs things aligned in order to not have to have lots of ugly
> code, it should generally extract that alignment itself.
So we should forward any bugreport about alignment issues to the
netdev people. That's perfectly fine with me. If netdev people are OK with that,
I'm also OK with removing the warning. :)
--
Greetings Michael.
On Fri, 25 Jan 2008, John W. Linville wrote:
>
> Quoth Herbert Xu:
>
> "OK. Let me clarify this a bit more. We require at least one
> of the following rules to be met:
>
> * the IPv4/IPv6 header is aligned by 8 bytes on reception;
> * or the platform provides unaligned exception handlers.
Ok, so the wireless stack currently does neither. It warns about
lack of 4-byte alignment (not 8), and it does so for everything.
> That puts mac80211 in an awkward position. It is not architecture
> code, so it can't make any assumptions about what is or isn't OK.
> So, we need to present aligned data to the network stack.
We can *easily* just have a "CONFIG_EXPENSIVE_UNALIGNED" thing, and force
architectures to set that, and then just have the mac80211 code re-align
the packet as required if it is set.
Or you guys could ask the network people to do that at an even higher
level.
> We could put the alignment onus on mac80211, but this has proven to be
> very solvable at (near?) zero cost by all the other drivers.
>From personal experience, I would not be in the least surprised if there
are DMA engines that simply cannot even do non-aligned DMA's.
And from a performance standpoint, it's also very possible that unaligned
DMA accesses (if they end up being done as such by a stupid DMA engine)
are more expensive than unaligned CPU data.
Linus
From: Linus Torvalds <[email protected]>
Date: Fri, 25 Jan 2008 10:22:13 -0800 (PST)
> With ethernet, there were chips that could only do DMA at certain
> alignments etc, together with various other headers being involved,
> making it impossible to require alignment without memcpy(), and I
> don't think we've had any issues there.
Yes, we could do a copy in the input path in the Intel drivers.
But then Intel is going to say "see it's fixed" and will never make
the 2 or 3 line fix to their firmware necessary to cure this
efficiently on all platforms.
To be honest I am in the camp of putting pressure on people
to do the right thing, and Intel fixing their firmware is
definitely the right thing to do here especially since it
is so easy for them to do so.
As for the "get another maintainer to step up" argument, nobody has
access to Intel's firmware source besides them, otherwise I can assure
you people would jump out of the woodwork by the handful to take over
several of Intel's drivers.
Many people are un-buggering up the Intel driver source bits that
people do have access to and can edit.
Intel controls the situation and that's just the way they like it.
It's not really a community thing because of the firmware issue,
so it's not possible to apply the same sort of "if you don't like
it, stand up and do the work to fix it" arguments.
We would if we could :-)
FWIW, I do agree with cpus should do unaligned accesses transparently,
without traps. But unfortunately I don't think all the cell phones,
wireless access points, building key-card entry systems and the like
are going to switch over to x86 any time soon. And in a scary sense
this is becomming the dominant space for Linux by at least some
measures :-)
On Fri, 25 Jan 2008, Michael Buesch wrote:
>
> The problem is _not_ the wireless header access, but the alignment of the embedded
> protocol stack, if the header does not have a size aligned to 4.
> Do we want to clutter the whole networking stack below wireless with
> get_unaligned() or attribute(packed) or something like that?
That's what all the other protocols do, isn't it?
For example, on PowerPC, NET_IP_ALIGN is 0 - explicitly so that the *dma*
from the card should be aligned, even if that in turn means that the IP
payload itself is then just two-byte aligned rather than word-aligned
(14-byte ethernet headers and all that).
[ Side note - I _used_ to know the networking code. That was about eight
to ten years ago. I'm really happy having a maintainer for it and not
having to know all the details any more, so maybe things have changed. ]
I do think that we generally should try to make the drivers do as little
complex stuff as humanly possible, and expect as little from hardware (and
firmware counts in that group) as we can. If some higher-level thing
really needs things aligned in order to not have to have lots of ugly
code, it should generally extract that alignment itself.
Linus
From: "John W. Linville" <[email protected]>
Date: Fri, 25 Jan 2008 17:46:31 -0500
> Given that we don't have a CONFIG_MUST_ALIGN at present, I'm not sure
> it is worth adding one for either an iwlwifi fix or a mac80211 one.
> Or are there other issues that might be resolved or aided by such
> a definition? It doesn't seem to have been needed so far.
We do have a need, look at the drivers like Tulip that
encode this into a big list of architecture ifdef checks.
On Friday 25 January 2008 22:11:44 Inaky Perez-Gonzalez wrote:
> On Friday 25 January 2008, Michael Buesch wrote:
> > On Friday 25 January 2008 19:34:46 Linus Torvalds wrote:
> > > My attitude is: CPU's that do unaligned accesses right are the *good*
> > > CPU's. We should encourage them, and put the onus of being crap on the
> > > ones that are crap, rather than penalizing the ones that aren't.
> >
> > I absolutely agree. But as this can get fixed with _no_ performance loss
> > at all inside of the firmware (and who if not intel can change stuff
> > in their firmware?), I think this warning is in fact valid.
>
> Well, you forgot the point that maybe it is not that simple to get such
> a seemingly simple change into the firmware for a long list of reasons.
The reasons being?
--
Greetings Michael.
On Fri, 25 Jan 2008, John W. Linville wrote:
>
> Anyway, this is mostly just so we can scope the driver change required
> in absence of a firmware change. Persumably the changes required if
> we were to put such code in mac80211 would be similar.
Make this conditional on archictures that need it, please.
And why is it suddenly smart to do this in three drivers rather than one
upper layer?
Linus
On Friday 25 January 2008 19:22:13 Linus Torvalds wrote:
>
> On Fri, 25 Jan 2008, Linus Torvalds wrote:
> >
> > But complaining about a vendor who does a good job technically, for
> > non-technical reasons, I really don't see that as being fine.
>
> Side note: I also think the wireless parts here are doing things wrong.
>
> Why _would_ you care about alignment? We used to have issues like that in
> the normal networking code, and it was a mistake there too. Why isn't the
> wireless stack just extracting the header explicitly, or using
> "get_unaligned()" like regular networking?
The problem is _not_ the wireless header access, but the alignment of the embedded
protocol stack, if the header does not have a size aligned to 4.
Do we want to clutter the whole networking stack below wireless with
get_unaligned() or attribute(packed) or something like that?
--
Greetings Michael.
On Fri, 2008-01-25 at 09:38 -0800, Linus Torvalds wrote:
>
> On Fri, 25 Jan 2008, Dan Williams wrote:
> >
> > Does Intel need to make iwlwifi and ipw2x00 work reliably on platforms
> > other than x86? Or don't they?
>
> Why should they?
>
> If somebody else takes over maintenance, because Intel does a bad job,
> that's fine.
>
> If somebody else sends in patches and they get accepted "around" Intel,
> that's obviously also fine.
>
> But complaining about a vendor who does a good job technically, for
> non-technical reasons, I really don't see that as being fine.
>
> Is it even physically *possible* to use that Intel wireless chipset with
> anything but x86 CPU's (not just that, but actually _Intel_ x86 CPU's)?
> And would it make any sense what-so-ever even if it was?
Yeah, 3945 and 4965 cards are mini PCI-E these days. And there are
ipw2100, ipw2200, and ipw2915 mini PCI cards that you could stick in
embedded systems and such. Though of course everyone doing embedded
stuff uses either Atheros or PrismII still, certainly not ipw/iwl.
This discussion occurred on May 18 - May 21, 2007 on linux-wireless with
the thread heading "[PATCH] Add iwlwifi wireless drivers [part 2/2]".
Dan
> And yes, portability is a great thing, but quite frankly, so is good
> hardware. I personally can't really blame Intel engineers for not caring
> about irrelevant hardware.
>
> We should make technical decisions on _technical_ grounds, not some
> perceived "this is how the world should work" grounds.
>
> Linus
On Thu, 2008-01-24 at 13:34 -0800, Linus Torvalds wrote:
>
> On Thu, 24 Jan 2008, John W. Linville wrote:
> >
> > There is no great harm in reverting
> > 81100eb80add328c4d2a377326f15aa0e7236398 if you would like to go ahead
> > and push the 2.6.24 release. I suspect, however, that the mac80211
> > guys would like to keep it (or put it back for 2.6.25) to continue
> > to shame driver developers in the future.
>
> I'd be happy to have it back in the development tree, I just don't want to
> have the noise for a release tree.
I guess I should speak up, having added that warning :)
We had a huge discussion a while ago concerning alignment of packets
when somebody noticed that on sparc64 the zd1211rw driver was causing
alignment faults in the IP stack.
During the discussion, I noticed that hardly anybody of the wireless
driver developers knew about the alignment constraints and so I added
this warning to make people aware of when they would run into problems
on platforms like sparc and arm that can't do unaligned loads (or only
with extreme penalties).
I had myself been considering to revert this patch for the .24 release
as you've done now, so I definitely don't have a problem with that. All
drivers except the Intel ones have been fixed, and they are in the
luxurious position to be able to fix their firmware. I can see that
might take a while longer than posting a quick fix and honestly I had
hoped they'd post a quick fix so their hardware is usable on platforms
like arm/sparc that can't do unaligned loads, no such luck, however.
Please revert the revert after .24 though, there are quite a few
alignment constraints and we'd like to check them automatically. Also,
with 11n there is yet another constraint and John has just merged a
patch from me that checks for those constraints as well.
Since the only problematic driver is Intel's, they really should be able
to get their act together for .25 and fix their firmware, if not then
we'll have to think of something else like making their drivers
memmove() the packets to the right place.
johannes
El Tue, 8 Jan 2008 16:30:30 +0100
Michael Buesch <[email protected]> escribi=C3=B3:
> On Monday 07 January 2008 21:23:44 Alejandro Riveira Fern=C3=A1ndez w=
rote:
>
> > =20
> > How can I check? The source code I build does indeed have the line
> > you quoted on net/mac80211/rx.c:1486 Is that what you are asking f=
or?
> > =20
> > WARN_ON_ONCE(((unsigned long)(skb->data + hdrlen)) & 3);
>=20
> Yes fine.
> Patches are on their way. Ignore the warning for now. It is harmless.
>=20
Thank you very much for your time. Keep on the good work :)
El Mon, 7 Jan 2008 17:24:03 +0100
Michael Buesch <[email protected]> escribi=C3=B3:
=
=20
>=20
> Can you post the lines above this?
> This might be a WARN_ON_ONCE() triggering, for which fixes are on the=
ir way into
> the wireless-2.6 tree.
This?
[ 37.043990] WARNING: at /home/alex/kernel/linux-2.6/net/mac80211/rx.=
c:1486 __ieee80211_rx()=20
[ 37.043996] Pid: 0, comm: swapper Not tainted 2.6.24-rc7 #3 =
=20
[ 37.043998] =
=20
[ 37.043999] Call Trace: =
=20
[ 37.044001] <IRQ> [<ffffffff80227fe3>] enqueue_task+0x13/0x30 =
=20
[ 37.044040] [<ffffffff88178cbe>] :mac80211:__ieee80211_rx+0xc7e/0xd=
30 =20
[ 37.044044] [<ffffffff80228062>] activate_task+0x32/0x50 =
=20
[ 37.044073] [<ffffffff8816a28b>] :mac80211:ieee80211_tasklet_handle=
r+0xbb/0x120 =20
[ 37.044086] [<ffffffff80238d08>] tasklet_action+0x48/0xb0 =
=20
[ 37.044091] [<ffffffff80238c09>] __do_softirq+0x69/0xe0 =
=20
[ 37.044097] [<ffffffff8020ce2c>] call_softirq+0x1c/0x30 =
=20
[ 37.044101] [<ffffffff8020efe5>] do_softirq+0x35/0x90 =
=20
[ 37.044105] [<ffffffff80238aa5>] irq_exit+0x95/0xa0 =
=20
[ 37.044108] [<ffffffff8020f0c0>] do_IRQ+0x80/0x100 =
=20
[ 37.044111] [<ffffffff8020a840>] default_idle+0x0/0x40 =
=20
[ 37.044115] [<ffffffff8020c181>] ret_from_intr+0x0/0xa =
=20
[ 37.044117] <EOI> [<ffffffff8020a869>] default_idle+0x29/0x40 =
=20
[ 37.044130] [<ffffffff8020a8f5>] cpu_idle+0x75/0xc0 =
=20
[ 37.044146] =
=20
>=20
On Friday 25 January 2008 19:34:46 Linus Torvalds wrote:
> My attitude is: CPU's that do unaligned accesses right are the *good*
> CPU's. We should encourage them, and put the onus of being crap on the
> ones that are crap, rather than penalizing the ones that aren't.
I absolutely agree. But as this can get fixed with _no_ performance loss
at all inside of the firmware (and who if not intel can change stuff
in their firmware?), I think this warning is in fact valid.
> In other words, we should use "get_unaligned()".
So we should put get_unaligned() into the whole networking stack below
wireless and penalize everybody, even gigabit-ethernet?
--
Greetings Michael.
On Fri, 25 Jan 2008, Michael Buesch wrote:
> > Well, you forgot the point that maybe it is not that simple to get such
> > a seemingly simple change into the firmware for a long list of reasons.
>
> The reasons being?
.. the reason being that people just expect existing firmware to work, for
example.
The point being, even if a newer firmware was _available_, people wouldn't
necessarily run with it.
We do *not* accept "upgrade the BIOS" as an answer to broken BIOSes
either. We work around BIOS limitations.
There can easily be other issues too. The DMA engine literally might only
do word-aligned transfers. Or other operating systems have different rules
from Linux, and the firmware is designed for those other systems.
Realistically, if it works with Windows, and I was a hardware team, and
the Linux people were whining about it, I'd feel perfectly fine in saying
"you're the buggy ones, we work fine".
So no, whining about hardware or firmware features isn't really very
productive. You take what you get.
Linus
On Thu, 24 Jan 2008, John W. Linville wrote:
>
> There is no great harm in reverting
> 81100eb80add328c4d2a377326f15aa0e7236398 if you would like to go ahead
> and push the 2.6.24 release. I suspect, however, that the mac80211
> guys would like to keep it (or put it back for 2.6.25) to continue
> to shame driver developers in the future.
I'd be happy to have it back in the development tree, I just don't want to
have the noise for a release tree.
Will revert that commit with a comment to that effect. Thanks,
Linus
On Fri, Jan 25, 2008 at 02:50:37PM -0500, John W. Linville wrote:
> On Fri, Jan 25, 2008 at 02:48:07PM -0500, John W. Linville wrote:
>
> > http://kerneltrap.org/mailarchive/linux-netdev/2007/11/24/442496
> >
> > Quoth Herbert Xu:
> >
> > "OK. Let me clarify this a bit more. We require at least one
> > of the following rules to be met:
> >
> > * the IPv4/IPv6 header is aligned by 8 bytes on reception;
> > * or the platform provides unaligned exception handlers.
>
> > (Hmmm..."aligned by 8 bytes", so our warning and my iwlwifi patch
> > may still not be right...)
>
> http://kerneltrap.org/mailarchive/linux-netdev/2007/11/25/443558
>
> More from Herbert:
>
> "Sorry I was wrong about the 8 bytes requirement. Although the
> IPv6 protocol does try to maintain an 8-byte alignment the Linux
> stack never does anything that requires that.
>
> So 4 bytes is enough."
>
> Phew!
Alright, here is my whack at it... The iwl_handle_data_packet_monitor
bits are untested, as I appear to be too daft to figure-out how to
exercise those paths.
Anyway, this is mostly just so we can scope the driver change required
in absence of a firmware change. Persumably the changes required if
we were to put such code in mac80211 would be similar.
John
-----
From: John W. Linville <[email protected]>
Subject: [PATCH] iwlwifi: move data at CPU to ensure 4-byte alignment for payload
Ugly, but if the firmware won't cooperate...
Signed-off-by: John W. Linville <[email protected]>
---
drivers/net/wireless/iwlwifi/iwl-3945.c | 13 ++++++++++---
drivers/net/wireless/iwlwifi/iwl-4965.c | 10 +++++++++-
drivers/net/wireless/iwlwifi/iwl3945-base.c | 10 +++++++++-
drivers/net/wireless/iwlwifi/iwl4965-base.c | 10 +++++++++-
4 files changed, 37 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-3945.c b/drivers/net/wireless/iwlwifi/iwl-3945.c
index 3a45fe9..06cd28e 100644
--- a/drivers/net/wireless/iwlwifi/iwl-3945.c
+++ b/drivers/net/wireless/iwlwifi/iwl-3945.c
@@ -252,6 +252,7 @@ static void iwl3945_handle_data_packet(struct iwl_priv *priv, int is_data,
struct iwl_rx_frame_hdr *rx_hdr = IWL_RX_HDR(pkt);
struct iwl_rx_frame_end *rx_end = IWL_RX_END(pkt);
short len = le16_to_cpu(rx_hdr->len);
+ int hdrlen, align;
/* We received data from the HW, so stop the watchdog */
if (unlikely((len + IWL_RX_FRAME_SIZE) > skb_tailroom(rxb->skb))) {
@@ -275,11 +276,17 @@ static void iwl3945_handle_data_packet(struct iwl_priv *priv, int is_data,
return;
}
- skb_reserve(rxb->skb, (void *)rx_hdr->payload - (void *)pkt);
+ hdr = (void *)rx_hdr->payload;
+ hdrlen = ieee80211_get_hdrlen(le16_to_cpu(hdr->frame_control));
+ align = hdrlen & 3;
+
+ skb_reserve(rxb->skb, (void *)rx_hdr->payload - (void *)pkt - align);
/* Set the size of the skb to the size of the frame */
- skb_put(rxb->skb, le16_to_cpu(rx_hdr->len));
+ skb_put(rxb->skb, len);
- hdr = (void *)rxb->skb->data;
+ /* align payload on 4-byte boundary if necessary */
+ if (align)
+ memmove((void *)hdr - align, hdr, len);
if (iwl_param_hwcrypto)
iwl_set_decrypted_flag(priv, rxb->skb,
diff --git a/drivers/net/wireless/iwlwifi/iwl-4965.c b/drivers/net/wireless/iwlwifi/iwl-4965.c
index 891f90d..11eb75b 100644
--- a/drivers/net/wireless/iwlwifi/iwl-4965.c
+++ b/drivers/net/wireless/iwlwifi/iwl-4965.c
@@ -3496,6 +3496,7 @@ static void iwl4965_handle_data_packet(struct iwl_priv *priv, int is_data,
__le32 *rx_end;
unsigned int skblen;
u32 ampdu_status;
+ int hdrlen, align;
if (!include_phy && priv->last_phy_res[0])
rx_start = (struct iwl4965_rx_phy_res *)&priv->last_phy_res[1];
@@ -3533,10 +3534,17 @@ static void iwl4965_handle_data_packet(struct iwl_priv *priv, int is_data,
ampdu_status = le32_to_cpu(*rx_end);
skblen = ((u8 *) rx_end - (u8 *) & pkt->u.raw[0]) + sizeof(u32);
+ hdrlen = ieee80211_get_hdrlen(le16_to_cpu(hdr->frame_control));
+ align = hdrlen & 3;
+
/* start from MAC */
- skb_reserve(rxb->skb, (void *)hdr - (void *)pkt);
+ skb_reserve(rxb->skb, (void *)hdr - (void *)pkt - align);
skb_put(rxb->skb, len); /* end where data ends */
+ /* align payload on 4-byte boundary if necessary */
+ if (align)
+ memmove(rxb->skb->data, hdr, len);
+
/* We only process data packets if the interface is open */
if (unlikely(!priv->is_open)) {
IWL_DEBUG_DROP_LIMIT
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 1a6b0e0..d6018bd 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -3056,7 +3056,9 @@ void iwl_handle_data_packet_monitor(struct iwl_priv *priv,
struct ieee80211_rx_status *stats,
u16 phy_flags)
{
+ struct ieee80211_hdr *hdr;
struct iwl_rt_rx_hdr *iwl_rt;
+ int hdrlen, align;
/* First cache any information we need before we overwrite
* the information provided in the skb from the hardware */
@@ -3072,8 +3074,14 @@ void iwl_handle_data_packet_monitor(struct iwl_priv *priv,
return;
}
+ /* determine payload alignment adjustment */
+ hdr = data;
+ hdrlen = ieee80211_get_hdrlen(le16_to_cpu(hdr->frame_control))
+ + sizeof(*iwl_rt);
+ align = 4 - (hdrlen & 3); /* invert align since already at skb head */
+
/* copy the frame data to write after where the radiotap header goes */
- iwl_rt = (void *)rxb->skb->data;
+ iwl_rt = (void *)rxb->skb->data + align;
memmove(iwl_rt->payload, data, len);
iwl_rt->rt_hdr.it_version = PKTHDR_RADIOTAP_VERSION;
diff --git a/drivers/net/wireless/iwlwifi/iwl4965-base.c b/drivers/net/wireless/iwlwifi/iwl4965-base.c
index 6cd57c2..9ef9d14 100644
--- a/drivers/net/wireless/iwlwifi/iwl4965-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl4965-base.c
@@ -3144,7 +3144,9 @@ void iwl_handle_data_packet_monitor(struct iwl_priv *priv,
struct ieee80211_rx_status *stats,
u16 phy_flags)
{
+ struct ieee80211_hdr *hdr;
struct iwl_rt_rx_hdr *iwl_rt;
+ int hdrlen, align;
/* First cache any information we need before we overwrite
* the information provided in the skb from the hardware */
@@ -3160,8 +3162,14 @@ void iwl_handle_data_packet_monitor(struct iwl_priv *priv,
return;
}
+ /* determine payload alignment adjustment */
+ hdr = data;
+ hdrlen = ieee80211_get_hdrlen(le16_to_cpu(hdr->frame_control))
+ + sizeof(*iwl_rt);
+ align = 4 - (hdrlen & 3); /* invert align since already at skb head */
+
/* copy the frame data to write after where the radiotap header goes */
- iwl_rt = (void *)rxb->skb->data;
+ iwl_rt = (void *)rxb->skb->data + align;
memmove(iwl_rt->payload, data, len);
iwl_rt->rt_hdr.it_version = PKTHDR_RADIOTAP_VERSION;
--
1.5.3.3
--
John W. Linville
[email protected]
On Fri, Jan 25, 2008 at 07:21:48PM +0100, Michael Buesch wrote:
> So why remove
> a sanity check that tells you about bugs in other drivers where it does
> matter (because they are used on such weird architectures), just because one
> vendor says "hey, doesn't matter for me"?
This is a good point. If people were already using a driver on an
oddball architecture, then we would get _those_ warnings (as we did
when someone plugged a zd1211 device into their sparc box). The point
of the warning is/was to point-out the problem to developers running
on mainstream architecutres so that they could fix these problems
rather than foisting them on some poor schmuck years from now trying
to build an SPARC-based AP. (Hey, it could happen...)
John
--
John W. Linville
[email protected]
From: "John W. Linville" <[email protected]>
Date: Fri, 25 Jan 2008 16:46:26 -0500
> Plus it is a bit unfair to ask for firmware changes just because the
> vendor is actually engaged with us. If this were Broadcom or Zydas
> firmware we would have little recourse other than to accept it or
> fix it in the driver or stack.
It's funny that you mention Broadcom, because on the ethernet
side exactly because they engage with us I've been able to
get them to add things that make sense to their gigabit firmware
and even the hardware itself.
It's the only reason Broadcom's gigabit and faster chips have
the one-shot MSI feature, because I asked them to add it because
it makes NAPI significantly faster.
On Thu, 24 Jan 2008, Michael Buesch wrote:
>
> This was fixed in the drivers. A fix for zd1211rw got in and for
> the RTL wireless drivers. Did any other driver trigger this warning?
The Intel driver does, and was tagged as the main culprit in at least the
pseudo-automated oops reports that Arjan sends to lkml.
> So it can cause some delay sometimes, but I'm pretty sure the fixes
> should have hit mainline by now. I can recheck that if you desire.
I'm 100% sure they haven't, since I could trigger this warning as of the
tree an hour ago (and I have since reverted it, so now I can't). That's
what reminded me - doing a final round of "test on the machines I have
available" before releasing 2.6.24.
Linus
From: Linus Torvalds <[email protected]>
Date: Fri, 25 Jan 2008 12:28:22 -0800 (PST)
[ Why do you guys have to have a thread like this when
I'm on a plane for 18 hours :-) ]
> > That puts mac80211 in an awkward position. It is not architecture
> > code, so it can't make any assumptions about what is or isn't OK.
> > So, we need to present aligned data to the network stack.
>
> We can *easily* just have a "CONFIG_EXPENSIVE_UNALIGNED" thing, and force
> architectures to set that, and then just have the mac80211 code re-align
> the packet as required if it is set.
>
> Or you guys could ask the network people to do that at an even higher
> level.
This is pseudo-encoded into many drivers which have trouble
receiving into "aligned for IP stack" RX buffers. They
copy in such cases, but the existing test is a pile or
arch ifdefs.
Those should definitely be transformed into something centralized
like the EXPENSIVE_UNAIGNED setting you suggest.
> And from a performance standpoint, it's also very possible that unaligned
> DMA accesses (if they end up being done as such by a stupid DMA engine)
> are more expensive than unaligned CPU data.
Not if it traps.
For powerpc it does win, because they don't trap on
unaligned accesses and the DMA cost is for non-cacheline
transfers is exhorbitant (not just large).
Now, practically speaking, sparc64 emits warnings when any
unaligned trap is taken. I test the networking a lot and I
know of only one obscure case in the IPSEC interface with
userspace over netlink where I see it ever occur.
It is so much easier to make the 4-byte alignment thing an
invariant at one place, top-most packet input, then pepper
the whole stack with all kinds of packed markings and
get_unaligned() and whatnot. And from my experience in sparc64
it's totally unnecessary and it will only add tons of overhead.
We could even move the check and the copy out of the drivers
and into the top-level packet input.
That would be a double win, things would always work and not
trap, but also drivers could still optimize cases where aspects
of hardware behavior would allow avoiding the unaligned cases
better on a driver-local level.
On Friday 25 January 2008 22:46:26 John W. Linville wrote:
> On Fri, Jan 25, 2008 at 10:21:07PM +0100, Michael Buesch wrote:
> > On Friday 25 January 2008 22:11:44 Inaky Perez-Gonzalez wrote:
> > > On Friday 25 January 2008, Michael Buesch wrote:
> > > > On Friday 25 January 2008 19:34:46 Linus Torvalds wrote:
> > > > > My attitude is: CPU's that do unaligned accesses right are the *good*
> > > > > CPU's. We should encourage them, and put the onus of being crap on the
> > > > > ones that are crap, rather than penalizing the ones that aren't.
> > > >
> > > > I absolutely agree. But as this can get fixed with _no_ performance loss
> > > > at all inside of the firmware (and who if not intel can change stuff
> > > > in their firmware?), I think this warning is in fact valid.
> > >
> > > Well, you forgot the point that maybe it is not that simple to get such
> > > a seemingly simple change into the firmware for a long list of reasons.
> >
> > The reasons being?
>
> Firmware certification is expensive.
>
> Plus it is a bit unfair to ask for firmware changes just because the
> vendor is actually engaged with us. If this were Broadcom or Zydas
> firmware we would have little recourse other than to accept it or
> fix it in the driver or stack.
Well, we could patch broadcom's firmware ;)
But anyway.
So what about removing the WARN_ON() and replacing it by
a conditional memmove then?
I mean, the wireless hardware I care about already is sane or fixed.
So if intel doesn't want to support this kind of machines, I'd say in
the end it is OK and we should not care about it at all. I mean, nobody
is forced to buy an intel card to use on such a machine.
I must say I don't care much about intel's customers that want to run
intel wireless in a machine that can't do unaligned access, if intel itself
doesn't care at all about them. In the end it is _intel's_ performance
problem and not ours.
The problem with that is that the warning goes away and _future_ drivers
will probably run into this performance problem and don't know about.
--
Greetings Michael.
On Monday 07 January 2008 21:23:44 Alejandro Riveira Fern=C3=A1ndez wro=
te:
> > > [ 37.043990] WARNING: at /home/alex/kernel/linux-2.6/net/mac802=
11/rx.c:1486 __ieee80211_rx()=20
> > > [ 37.043996] Pid: 0, comm: swapper Not tainted 2.6.24-rc7 #3 =
=20
> > > [ 37.043998] =
=20
> > > [ 37.043999] Call Trace: =
=20
> > > [ 37.044001] <IRQ> [<ffffffff80227fe3>] enqueue_task+0x13/0x3=
0 =20
> > > [ 37.044040] [<ffffffff88178cbe>] :mac80211:__ieee80211_rx+0xc=
7e/0xd30 =20
> > > [ 37.044044] [<ffffffff80228062>] activate_task+0x32/0x50 =
=20
> > > [ 37.044073] [<ffffffff8816a28b>] :mac80211:ieee80211_tasklet_=
handler+0xbb/0x120 =20
> > > [ 37.044086] [<ffffffff80238d08>] tasklet_action+0x48/0xb0 =
=20
> > > [ 37.044091] [<ffffffff80238c09>] __do_softirq+0x69/0xe0 =
=20
> > > [ 37.044097] [<ffffffff8020ce2c>] call_softirq+0x1c/0x30 =
=20
> > > [ 37.044101] [<ffffffff8020efe5>] do_softirq+0x35/0x90 =
=20
> > > [ 37.044105] [<ffffffff80238aa5>] irq_exit+0x95/0xa0 =
=20
> > > [ 37.044108] [<ffffffff8020f0c0>] do_IRQ+0x80/0x100 =
=20
> > > [ 37.044111] [<ffffffff8020a840>] default_idle+0x0/0x40 =
=20
> > > [ 37.044115] [<ffffffff8020c181>] ret_from_intr+0x0/0xa =
=20
> > > [ 37.044117] <EOI> [<ffffffff8020a869>] default_idle+0x29/0x4=
0 =20
> > > [ 37.044130] [<ffffffff8020a8f5>] cpu_idle+0x75/0xc0 =
=20
> > > [ 37.044146] =
=20
> >=20
> >=20
> > Can you check if that is the
> > WARN_ON_ONCE(((unsigned long)(skb->data + hdrlen)) & 3);
> > in rx.c line 1486?
> =20
> How can I check? The source code I build does indeed have the line
> you quoted on net/mac80211/rx.c:1486 Is that what you are asking for=
?
> =20
> WARN_ON_ONCE(((unsigned long)(skb->data + hdrlen)) & 3);
Yes fine.
Patches are on their way. Ignore the warning for now. It is harmless.
--=20
Greetings Michael.
On Sat, 26 Jan 2008, David Miller wrote:
>
> We could even move the check and the copy out of the drivers
> and into the top-level packet input.
Hallelujah! Exactly.
> That would be a double win, things would always work and not
> trap, but also drivers could still optimize cases where aspects
> of hardware behavior would allow avoiding the unaligned cases
> better on a driver-local level.
Absolutely. Even on x86 and PowerPC, even if the actual "memmove()"
doesn't take place, a driver that *can* make the packet data naturally
aligned will want to do so just for simple performance reasons.
But we shouldn't make up stupid rules like "network drivers *have* to
align packets correctly", simply because such rules may not make sense to
the driver writer. If the hardware simply cannot do it, or has some
horrible performance behaviour when it does so, it's stupid to tell a
driver that it has to do it.
Linus
On Thursday 24 January 2008 21:27:03 Linus Torvalds wrote:
>
> On Tue, 8 Jan 2008, Michael Buesch wrote:
> > > >
> > > > Can you check if that is the
> > > > WARN_ON_ONCE(((unsigned long)(skb->data + hdrlen)) & 3);
> > > > in rx.c line 1486?
> >
> > Yes fine.
> > Patches are on their way. Ignore the warning for now. It is harmless.
>
> I don't think this ever got fixed.
This was fixed in the drivers. A fix for zd1211rw got in and for
the RTL wireless drivers. Did any other driver trigger this warning?
> I don't see any alternative but just uncomment that bogus warning, because
> it's otherwise going to just cause way more noise than it's worth. It's
> apparently known to developers, and as such it's worthless in the source
> code except as a way to make poor users worry.
>
> It's been in the top oops/warnings report for the last three weeks, and I
> haven't gotten any patches for it, so I'm a bit grumpy. What's the point
> of having a WARN_ON() if nobody involved *does* anything about it?
It was already fixed before this bugreport, in this mail thread
you are replying to, was sent.
We do have a long maintainers chain for wireless
driver developers -> john linville -> netdev -> you
So it can cause some delay sometimes, but I'm pretty sure the fixes
should have hit mainline by now. I can recheck that if you desire.
--
Greetings Michael.
El Mon, 7 Jan 2008 18:30:51 +0100
Michael Buesch <[email protected]> escribi=C3=B3:
> On Monday 07 January 2008 17:52:48 Alejandro Riveira Fern=C3=A1ndez w=
rote:
> > El Mon, 7 Jan 2008 17:24:03 +0100
> > Michael Buesch <[email protected]> escribi=C3=B3:
> >=20
> > =
=20
> > >=20
> > > Can you post the lines above this?
> > > This might be a WARN_ON_ONCE() triggering, for which fixes are on=
their way into
> > > the wireless-2.6 tree.
> >=20
> > This?
> >=20
> >=20
> > [ 37.043990] WARNING: at /home/alex/kernel/linux-2.6/net/mac80211=
/rx.c:1486 __ieee80211_rx()=20
> > [ 37.043996] Pid: 0, comm: swapper Not tainted 2.6.24-rc7 #3 =
=20
> > [ 37.043998] =
=20
> > [ 37.043999] Call Trace: =
=20
> > [ 37.044001] <IRQ> [<ffffffff80227fe3>] enqueue_task+0x13/0x30 =
=20
> > [ 37.044040] [<ffffffff88178cbe>] :mac80211:__ieee80211_rx+0xc7e=
/0xd30 =20
> > [ 37.044044] [<ffffffff80228062>] activate_task+0x32/0x50 =
=20
> > [ 37.044073] [<ffffffff8816a28b>] :mac80211:ieee80211_tasklet_ha=
ndler+0xbb/0x120 =20
> > [ 37.044086] [<ffffffff80238d08>] tasklet_action+0x48/0xb0 =
=20
> > [ 37.044091] [<ffffffff80238c09>] __do_softirq+0x69/0xe0 =
=20
> > [ 37.044097] [<ffffffff8020ce2c>] call_softirq+0x1c/0x30 =
=20
> > [ 37.044101] [<ffffffff8020efe5>] do_softirq+0x35/0x90 =
=20
> > [ 37.044105] [<ffffffff80238aa5>] irq_exit+0x95/0xa0 =
=20
> > [ 37.044108] [<ffffffff8020f0c0>] do_IRQ+0x80/0x100 =
=20
> > [ 37.044111] [<ffffffff8020a840>] default_idle+0x0/0x40 =
=20
> > [ 37.044115] [<ffffffff8020c181>] ret_from_intr+0x0/0xa =
=20
> > [ 37.044117] <EOI> [<ffffffff8020a869>] default_idle+0x29/0x40 =
=20
> > [ 37.044130] [<ffffffff8020a8f5>] cpu_idle+0x75/0xc0 =
=20
> > [ 37.044146] =
=20
>=20
>=20
> Can you check if that is the
> WARN_ON_ONCE(((unsigned long)(skb->data + hdrlen)) & 3);
> in rx.c line 1486?
=20
How can I check? The source code I build does indeed have the line
you quoted on net/mac80211/rx.c:1486 Is that what you are asking for?
=20
WARN_ON_ONCE(((unsigned long)(skb->data + hdrlen)) & 3);
=20
=20
> If that is the one, then fixes are already on their way upstream.
> Ignore the harmless warning for now.
=20
Thanks for your time
>=20
On Fri, Jan 25, 2008 at 11:07:47AM -0800, Linus Torvalds wrote:
>
>
> On Fri, 25 Jan 2008, Michael Buesch wrote:
> >
> > The problem is _not_ the wireless header access, but the alignment of the embedded
> > protocol stack, if the header does not have a size aligned to 4.
> > Do we want to clutter the whole networking stack below wireless with
> > get_unaligned() or attribute(packed) or something like that?
>
> That's what all the other protocols do, isn't it?
>
> For example, on PowerPC, NET_IP_ALIGN is 0 - explicitly so that the *dma*
> from the card should be aligned, even if that in turn means that the IP
> payload itself is then just two-byte aligned rather than word-aligned
> (14-byte ethernet headers and all that).
http://kerneltrap.org/mailarchive/linux-netdev/2007/11/24/442496
Quoth Herbert Xu:
"OK. Let me clarify this a bit more. We require at least one
of the following rules to be met:
* the IPv4/IPv6 header is aligned by 8 bytes on reception;
* or the platform provides unaligned exception handlers.
So if your platform violates both rules then it won't work with
the IP stack, simple as that. Fortunately I don't think such a
platform exists currently on Linux."
That puts mac80211 in an awkward position. It is not architecture
code, so it can't make any assumptions about what is or isn't OK.
So, we need to present aligned data to the network stack.
We could put the alignment onus on mac80211, but this has proven to be
very solvable at (near?) zero cost by all the other drivers. I suppose
we could put code in mac80211 to check/correct the alignment anyway
and hope that the cost of such checking is small enough not to matter
as long as drivers are passing aligned data anyway. But that seems
a bit silly, when at least so far only this one driver has balked at
doing the right thing.
I'm working on some iwlwifi patches to check/correct alignment.
(Hmmm..."aligned by 8 bytes", so our warning and my iwlwifi patch
may still not be right...)
John
--
John W. Linville
[email protected]
On Friday 25 January 2008 17:43:09 Linus Torvalds wrote:
>
> On Fri, 25 Jan 2008, Michael Buesch wrote:
> >
> > If we are talking about what's sane or not...
> > It's trivial to fix this in the firmware, like sane vendors like
> > Broadcom do.
>
> You just showed your total disregard for any sanity by calling broadcom
> "sane".
The Broadcom firmware _is_ mostly sane. That's what I am saying.
I wasn't talking about Broadcom's support or anything else.
> > Architectures that can't do unaligned access are heavily used in
> > wireless embedded routers. So we are not going to pay a huge
> > price there so just one vendor doesn't have to fix his firmware.
>
> .. and you also showed that you didn't even read my email and the options
> I outlined. The fact is, the Intel wireless chipset only works with x86
> CPU's. There is absolutely zero "price" on crap CPU's, because they are
> simply not relevant to this driver.
I'm not sure what's so hard about adding this trivial fix to the firmware.
The _fact_ that this warning triggered for lots of drivers means that
developers are not aware of the problem. So why should we go on hiding bugs
that are _trivial_ to fix?
I absolutely hate the attitude "The problem does not happen on most
of the stuff intel uses, so they don't need to fix this". So, I also don't
need to fix bugs in code I wrote, just because I don't have such use
scenario? That would be great. I'd know thousands of lines of b43 code
that I'd like to immediately remove then.
That's just not how it works in the real world.
We should write the kernel and drivers as portable as possible. We left the
old days when linux only ran on an i386. ;)
And to say it again, this is really really trivial to fix. So why remove
a sanity check that tells you about bugs in other drivers where it does
matter (because they are used on such weird architectures), just because one
vendor says "hey, doesn't matter for me"?
Adding the check to the driver is not an option, because most driver developers
are not aware of the issue. So they would not add this. They would just run
into weird issues and waste time debugging it.
If this was a hard to fix problem which would require changing lots of things,
ok. That would be OK to remove the sanity check then. But that's not the case.
--
Greetings Michael.
On Tue, 8 Jan 2008, Michael Buesch wrote:
> > >
> > > Can you check if that is the
> > > WARN_ON_ONCE(((unsigned long)(skb->data + hdrlen)) & 3);
> > > in rx.c line 1486?
>
> Yes fine.
> Patches are on their way. Ignore the warning for now. It is harmless.
I don't think this ever got fixed.
I don't see any alternative but just uncomment that bogus warning, because
it's otherwise going to just cause way more noise than it's worth. It's
apparently known to developers, and as such it's worthless in the source
code except as a way to make poor users worry.
It's been in the top oops/warnings report for the last three weeks, and I
haven't gotten any patches for it, so I'm a bit grumpy. What's the point
of having a WARN_ON() if nobody involved *does* anything about it?
Linus
On Monday 07 January 2008 17:14:15 Alejandro Riveira Fern=C3=A1ndez wro=
te:
> El Sun, 6 Jan 2008 14:19:16 -0800 (PST)
> Linus Torvalds <[email protected]> escribi=C3=B3:
>=20
> >=20
> > It's been two weeks since rc6, but let's face it, with xmas and new=
years=20
> > (and birthdays) in between, there hasn't actually been a lot of wor=
king=20
> > days, and the incremental patch from -rc6 is about half the size of=
the=20
> > one from rc5->rc6.
> >=20
> > And I'll be charitable and claim it's because it's all stabilizing,=
and=20
> > not because we've all been in a drunken stupor over the holidays.
> >=20
> > The shortlog (appended below) is short and fairly informative. It's=
all=20
> > really just a lot of rather small changes. The diffstat shows a lot=
of=20
> > one- and two-liners, with just a few drivers (and the Cell platform=
)=20
> > getting a bit more attention, and the SLUB support of /proc/slabinf=
o=20
> > showing up as a blip.
> >=20
> > Both git trees and tar-balls/patches pushed out, should be mirrorin=
g out=20
> > within minutes. So there are no excuses to not try it out, and see =
if your=20
> > favorite regression has been fixed.
> >=20
> > Linus
> >=20
> Booted with it and I see=20
>=20
> [ 37.043998] =
=20
> [ 37.043999] Call Trace: =
=20
> [ 37.044001] <IRQ> [<ffffffff80227fe3>] enqueue_task+0x13/0x30 =
=20
> [ 37.044040] [<ffffffff88178cbe>] :mac80211:__ieee80211_rx+0xc7e/0=
xd30 =20
> [ 37.044044] [<ffffffff80228062>] activate_task+0x32/0x50 =
=20
> [ 37.044073] [<ffffffff8816a28b>] :mac80211:ieee80211_tasklet_hand=
ler+0xbb/0x120 =20
> [ 37.044086] [<ffffffff80238d08>] tasklet_action+0x48/0xb0 =
=20
> [ 37.044091] [<ffffffff80238c09>] __do_softirq+0x69/0xe0 =
=20
> [ 37.044097] [<ffffffff8020ce2c>] call_softirq+0x1c/0x30 =
=20
> [ 37.044101] [<ffffffff8020efe5>] do_softirq+0x35/0x90 =
=20
> [ 37.044105] [<ffffffff80238aa5>] irq_exit+0x95/0xa0 =
=20
> [ 37.044108] [<ffffffff8020f0c0>] do_IRQ+0x80/0x100 =
=20
> [ 37.044111] [<ffffffff8020a840>] default_idle+0x0/0x40 =
=20
> [ 37.044115] [<ffffffff8020c181>] ret_from_intr+0x0/0xa =
=20
> [ 37.044117] <EOI> [<ffffffff8020a869>] default_idle+0x29/0x40 =
=20
> [ 37.044130] [<ffffffff8020a8f5>] cpu_idle+0x75/0xc0 =
=20
> [ 37.044146] =
=20
Can you post the lines above this?
This might be a WARN_ON_ONCE() triggering, for which fixes are on their=
way into
the wireless-2.6 tree.
--=20
Greetings Michael.
On Fri, 25 Jan 2008, Michael Buesch wrote:
>
> If we are talking about what's sane or not...
> It's trivial to fix this in the firmware, like sane vendors like
> Broadcom do.
You just showed your total disregard for any sanity by calling broadcom
"sane".
Quite frankly, Broadcom is probably the single worst chip manufacturer in
terms of both bugginess of the silicon itself and in terms of lack of
support.
> Architectures that can't do unaligned access are heavily used in
> wireless embedded routers. So we are not going to pay a huge
> price there so just one vendor doesn't have to fix his firmware.
.. and you also showed that you didn't even read my email and the options
I outlined. The fact is, the Intel wireless chipset only works with x86
CPU's. There is absolutely zero "price" on crap CPU's, because they are
simply not relevant to this driver.
Linus
On Fri, Jan 25, 2008 at 01:56:15PM -0800, Linus Torvalds wrote:
>
>
> On Fri, 25 Jan 2008, John W. Linville wrote:
> >
> > Anyway, this is mostly just so we can scope the driver change required
> > in absence of a firmware change. Persumably the changes required if
> > we were to put such code in mac80211 would be similar.
>
> Make this conditional on archictures that need it, please.
>
> And why is it suddenly smart to do this in three drivers rather than one
> upper layer?
Two drivers, FWIW... :-)
Given that we don't have a CONFIG_MUST_ALIGN at present, I'm not sure
it is worth adding one for either an iwlwifi fix or a mac80211 one.
Or are there other issues that might be resolved or aided by such
a definition? It doesn't seem to have been needed so far.
Maybe it would be easier to add a CONFIG_MAC80211_ALIGN_PAYLOAD option
around some code in mac80211 to fix-up alignments? Then users of
alignment-sensitive arches could turn-on that option, and the rest
of us would leave it off. Another (non-exclusive) option would be
to put CONFIG_MAC80211_DEBUG around the alignment warning so that
most people would never see it.
Thoughts? I'm just looking for a resolution... :-)
John
--
John W. Linville
[email protected]
From: "John W. Linville" <[email protected]>
Date: Fri, 25 Jan 2008 16:18:15 -0500
> Alright, here is my whack at it... The iwl_handle_data_packet_monitor
> bits are untested, as I appear to be too daft to figure-out how to
> exercise those paths.
>
> Anyway, this is mostly just so we can scope the driver change required
> in absence of a firmware change. Persumably the changes required if
> we were to put such code in mac80211 would be similar.
If this buffer is in the SKB, this is an illegal transformation.
Once you put something in front of skb->data, it's fair game
for other things to write over that buffer area with a pushed
packet header of their own.
The only legal way to fix this is to completely copy the packet,
headers and all, at the input site.
On Friday 25 January 2008, Michael Buesch wrote:
> On Friday 25 January 2008 19:34:46 Linus Torvalds wrote:
> > My attitude is: CPU's that do unaligned accesses right are the *good*
> > CPU's. We should encourage them, and put the onus of being crap on the
> > ones that are crap, rather than penalizing the ones that aren't.
>
> I absolutely agree. But as this can get fixed with _no_ performance loss
> at all inside of the firmware (and who if not intel can change stuff
> in their firmware?), I think this warning is in fact valid.
Well, you forgot the point that maybe it is not that simple to get such
a seemingly simple change into the firmware for a long list of reasons.
NACK
memmove will cause redundant high CPU utilization in 11n High Throughput.
Such changes, if done, should be wrapped with some
#ifdef CANT_HANDLE_UNALIGNED_....
And better be done in mac80211 and not at driver level. iwlwifi skb is
802.11 and 802.3 frame.
On 1/25/08, John W. Linville <[email protected]> wrote:
> Alright, here is my whack at it... The iwl_handle_data_packet_monitor
> bits are untested, as I appear to be too daft to figure-out how to
> exercise those paths.
>
> Anyway, this is mostly just so we can scope the driver change required
> in absence of a firmware change. Persumably the changes required if
> we were to put such code in mac80211 would be similar.
>
> John
>
> -----
>
> From: John W. Linville <[email protected]>
> Subject: [PATCH] iwlwifi: move data at CPU to ensure 4-byte alignment for payload
>
> Ugly, but if the firmware won't cooperate...
>
> Signed-off-by: John W. Linville <[email protected]>
> ---
> drivers/net/wireless/iwlwifi/iwl-3945.c | 13 ++++++++++---
> drivers/net/wireless/iwlwifi/iwl-4965.c | 10 +++++++++-
> drivers/net/wireless/iwlwifi/iwl3945-base.c | 10 +++++++++-
> drivers/net/wireless/iwlwifi/iwl4965-base.c | 10 +++++++++-
> 4 files changed, 37 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl-3945.c b/drivers/net/wireless/iwlwifi/iwl-3945.c
> index 3a45fe9..06cd28e 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-3945.c
> +++ b/drivers/net/wireless/iwlwifi/iwl-3945.c
> @@ -252,6 +252,7 @@ static void iwl3945_handle_data_packet(struct iwl_priv *priv, int is_data,
> struct iwl_rx_frame_hdr *rx_hdr = IWL_RX_HDR(pkt);
> struct iwl_rx_frame_end *rx_end = IWL_RX_END(pkt);
> short len = le16_to_cpu(rx_hdr->len);
> + int hdrlen, align;
>
> /* We received data from the HW, so stop the watchdog */
> if (unlikely((len + IWL_RX_FRAME_SIZE) > skb_tailroom(rxb->skb))) {
> @@ -275,11 +276,17 @@ static void iwl3945_handle_data_packet(struct iwl_priv *priv, int is_data,
> return;
> }
>
> - skb_reserve(rxb->skb, (void *)rx_hdr->payload - (void *)pkt);
> + hdr = (void *)rx_hdr->payload;
> + hdrlen = ieee80211_get_hdrlen(le16_to_cpu(hdr->frame_control));
> + align = hdrlen & 3;
> +
> + skb_reserve(rxb->skb, (void *)rx_hdr->payload - (void *)pkt - align);
> /* Set the size of the skb to the size of the frame */
> - skb_put(rxb->skb, le16_to_cpu(rx_hdr->len));
> + skb_put(rxb->skb, len);
>
> - hdr = (void *)rxb->skb->data;
> + /* align payload on 4-byte boundary if necessary */
> + if (align)
> + memmove((void *)hdr - align, hdr, len);
>
> if (iwl_param_hwcrypto)
> iwl_set_decrypted_flag(priv, rxb->skb,
> diff --git a/drivers/net/wireless/iwlwifi/iwl-4965.c b/drivers/net/wireless/iwlwifi/iwl-4965.c
> index 891f90d..11eb75b 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-4965.c
> +++ b/drivers/net/wireless/iwlwifi/iwl-4965.c
> @@ -3496,6 +3496,7 @@ static void iwl4965_handle_data_packet(struct iwl_priv *priv, int is_data,
> __le32 *rx_end;
> unsigned int skblen;
> u32 ampdu_status;
> + int hdrlen, align;
>
> if (!include_phy && priv->last_phy_res[0])
> rx_start = (struct iwl4965_rx_phy_res *)&priv->last_phy_res[1];
> @@ -3533,10 +3534,17 @@ static void iwl4965_handle_data_packet(struct iwl_priv *priv, int is_data,
> ampdu_status = le32_to_cpu(*rx_end);
> skblen = ((u8 *) rx_end - (u8 *) & pkt->u.raw[0]) + sizeof(u32);
>
> + hdrlen = ieee80211_get_hdrlen(le16_to_cpu(hdr->frame_control));
> + align = hdrlen & 3;
> +
> /* start from MAC */
> - skb_reserve(rxb->skb, (void *)hdr - (void *)pkt);
> + skb_reserve(rxb->skb, (void *)hdr - (void *)pkt - align);
> skb_put(rxb->skb, len); /* end where data ends */
>
> + /* align payload on 4-byte boundary if necessary */
> + if (align)
> + memmove(rxb->skb->data, hdr, len);
> +
> /* We only process data packets if the interface is open */
> if (unlikely(!priv->is_open)) {
> IWL_DEBUG_DROP_LIMIT
> diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
> index 1a6b0e0..d6018bd 100644
> --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
> +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
> @@ -3056,7 +3056,9 @@ void iwl_handle_data_packet_monitor(struct iwl_priv *priv,
> struct ieee80211_rx_status *stats,
> u16 phy_flags)
> {
> + struct ieee80211_hdr *hdr;
> struct iwl_rt_rx_hdr *iwl_rt;
> + int hdrlen, align;
>
> /* First cache any information we need before we overwrite
> * the information provided in the skb from the hardware */
> @@ -3072,8 +3074,14 @@ void iwl_handle_data_packet_monitor(struct iwl_priv *priv,
> return;
> }
>
> + /* determine payload alignment adjustment */
> + hdr = data;
> + hdrlen = ieee80211_get_hdrlen(le16_to_cpu(hdr->frame_control))
> + + sizeof(*iwl_rt);
> + align = 4 - (hdrlen & 3); /* invert align since already at skb head */
> +
> /* copy the frame data to write after where the radiotap header goes */
> - iwl_rt = (void *)rxb->skb->data;
> + iwl_rt = (void *)rxb->skb->data + align;
> memmove(iwl_rt->payload, data, len);
>
> iwl_rt->rt_hdr.it_version = PKTHDR_RADIOTAP_VERSION;
> diff --git a/drivers/net/wireless/iwlwifi/iwl4965-base.c b/drivers/net/wireless/iwlwifi/iwl4965-base.c
> index 6cd57c2..9ef9d14 100644
> --- a/drivers/net/wireless/iwlwifi/iwl4965-base.c
> +++ b/drivers/net/wireless/iwlwifi/iwl4965-base.c
> @@ -3144,7 +3144,9 @@ void iwl_handle_data_packet_monitor(struct iwl_priv *priv,
> struct ieee80211_rx_status *stats,
> u16 phy_flags)
> {
> + struct ieee80211_hdr *hdr;
> struct iwl_rt_rx_hdr *iwl_rt;
> + int hdrlen, align;
>
> /* First cache any information we need before we overwrite
> * the information provided in the skb from the hardware */
> @@ -3160,8 +3162,14 @@ void iwl_handle_data_packet_monitor(struct iwl_priv *priv,
> return;
> }
>
> + /* determine payload alignment adjustment */
> + hdr = data;
> + hdrlen = ieee80211_get_hdrlen(le16_to_cpu(hdr->frame_control))
> + + sizeof(*iwl_rt);
> + align = 4 - (hdrlen & 3); /* invert align since already at skb head */
> +
> /* copy the frame data to write after where the radiotap header goes */
> - iwl_rt = (void *)rxb->skb->data;
> + iwl_rt = (void *)rxb->skb->data + align;
> memmove(iwl_rt->payload, data, len);
>
> iwl_rt->rt_hdr.it_version = PKTHDR_RADIOTAP_VERSION;
> --
> 1.5.3.3
>
> --
> John W. Linville
> [email protected]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
From: Linus Torvalds <[email protected]>
Date: Fri, 25 Jan 2008 13:54:31 -0800 (PST)
>
>
> On Fri, 25 Jan 2008, Michael Buesch wrote:
> > > Well, you forgot the point that maybe it is not that simple to get such
> > > a seemingly simple change into the firmware for a long list of reasons.
> >
> > The reasons being?
>
> .. the reason being that people just expect existing firmware to work, for
> example.
>
> The point being, even if a newer firmware was _available_, people wouldn't
> necessarily run with it.
How differently would the situation be handled if the firmware
source were available and changeable by anyone in the community?
This situation therefore only exists because it is not available
to anyone to hack on.
Drivers like the aic7xxx and sym53c8xx scsi ones come with scripts
and other firmware that we build, if a bug were found in it we
would simply fix it instead of bastardizing the C portions of
the driver to fit the limitations of the firmware.
The firmware is source, just that in this case we don't have
access to a usable form of it, and the entity that does chooses
to not band over a little bit to be cooperative.
On Fri, 25 Jan 2008, Michael Buesch wrote:
>
> I'm not sure what's so hard about adding this trivial fix to the firmware.
> The _fact_ that this warning triggered for lots of drivers means that
> developers are not aware of the problem. So why should we go on hiding bugs
> that are _trivial_ to fix?
.. mainly because I don't think it's a bug in the network driver.
It really sounds like you're creating a warning for a bug in the wireless
infrastructure, and then trying to blame the drivers that don't agree with
that warning being valid in the first place.
> I absolutely hate the attitude "The problem does not happen on most
> of the stuff intel uses, so they don't need to fix this".
That's not *my* attitude at least.
My attitude is: CPU's that do unaligned accesses right are the *good*
CPU's. We should encourage them, and put the onus of being crap on the
ones that are crap, rather than penalizing the ones that aren't.
In other words, we should use "get_unaligned()".
Linus
On Jan 26, 2008 8:42 AM, David Miller <[email protected]> wrote:
> From: Inaky Perez-Gonzalez <[email protected]>
> Date: Fri, 25 Jan 2008 13:28:35 -0800
>
> > For example: want to ship new firmware, drivers *and* full validation and
> > certification for a product that is already completed just to satisfy a
> > fraction of a market which is not part of the designed target?
> >
> > Do you know how much money that costs?
>
> I'm glad you guys are the only one's with access to the firmware
> source, thus enduring that you can constantly come up with reasons
> like this in order to not have to fix the problem.
>
> You know that if the source were available, the community would have
> fixed the bug ages ago.
>
> But the situation is entirely in Intel's control which is surely
> exactly the way they like it.
IMO the real problem is not Intel not wanting to free the firmware,
but that legal says they can't. The reason why legal would tell them
that is due to the attempt to comply to out-of-date regulatory laws
which currently exist in different and sometimes in most countries. At
least within the US, for example, the laws dealing with new devices
like SDRs [1] don't say you can't use FOSS but "warn that the
certification will be less likely to be granted if the manufacturer
relies 'wholly' on FOSS in building the device" [2]. IMO these laws
are just new and regulatory agencies just have no good ideas as to
how to properly regulate these type of devices properly yet. My
current stance on this issue is to have regulatory bodies shift
liability to the user for use of unsupported software. Changing
regulatory bodies to embrace this idea will take a while so in the
meantime we have to deal with what we have and that is wireless cards
coming close to being SDRs but still being certified under part 15
rules and corporate legal teams just wanting to play it safe.
So all this is in general is not about vendors not wanting to support
us. Its simply the fear uncertainty and doubt game, but the stakes are
pretty high for vendors. In the long run my hope is we can get an
alliance of wireless vendors going to eventually make a proposal to
different legislative bodies to consider changing certification
requirements for the sake of advancing these technologies with the
community even using FOSS.
[1] http://en.wikipedia.org/wiki/Software_radio
[2] http://www.softwarefreedom.org/resources/2007/fcc-sdr-whitepaper.html
Luis
On Fri, Jan 25, 2008 at 02:48:07PM -0500, John W. Linville wrote:
> http://kerneltrap.org/mailarchive/linux-netdev/2007/11/24/442496
>
> Quoth Herbert Xu:
>
> "OK. Let me clarify this a bit more. We require at least one
> of the following rules to be met:
>
> * the IPv4/IPv6 header is aligned by 8 bytes on reception;
> * or the platform provides unaligned exception handlers.
> (Hmmm..."aligned by 8 bytes", so our warning and my iwlwifi patch
> may still not be right...)
http://kerneltrap.org/mailarchive/linux-netdev/2007/11/25/443558
More from Herbert:
"Sorry I was wrong about the 8 bytes requirement. Although the
IPv6 protocol does try to maintain an 8-byte alignment the Linux
stack never does anything that requires that.
So 4 bytes is enough."
Phew!
John
--
John W. Linville
[email protected]
On 1/25/08, Michael Buesch <[email protected]> wrote:
> On Friday 25 January 2008 22:11:44 Inaky Perez-Gonzalez wrote:
> > Well, you forgot the point that maybe it is not that simple to get such
> > a seemingly simple change into the firmware for a long list of reasons.
>
> The reasons being?
Please stop being a smug. We are not going to expose here 4965's HW or
FW architecture. [did you think about the theoretical possibility that
240Mbps HW may handle its RX data path not purely by FW SW?].
Currently we don't have any magic solution for that.
The right solution here is as Linus suggested. Align the data for CPUs
that can't handle unaligned access _only_.
Guy.
>
> --
> Greetings Michael.
On Thursday 24 January 2008 23:26:41 Linus Torvalds wrote:
>
> On Thu, 24 Jan 2008, Michael Buesch wrote:
> >
> > This was fixed in the drivers. A fix for zd1211rw got in and for
> > the RTL wireless drivers. Did any other driver trigger this warning?
>
> The Intel driver does, and was tagged as the main culprit in at least the
> pseudo-automated oops reports that Arjan sends to lkml.
Oh, well. Intel... hm.
They basically refused to fix it by now.
Please don't blame us mainline developers for this.
We _did_ immediately care to fix our drivers. So the only driver
that is actually not fixed is the intel stuff, which is kind of
developed out of tree and only pushed from time to time.
I don't know why they didn't fix it, yet, but I guess it's low
priority for them, as it does not cause any problems on
intel CPUs.
> > So it can cause some delay sometimes, but I'm pretty sure the fixes
> > should have hit mainline by now. I can recheck that if you desire.
>
> I'm 100% sure they haven't, since I could trigger this warning as of the
> tree an hour ago (and I have since reverted it, so now I can't). That's
> what reminded me - doing a final round of "test on the machines I have
> available" before releasing 2.6.24.
I guess you tested with Intel wireless, right?
I'm sorry for the inconvenience anyway.
It's OK to revert this WARN_ON for the release kernel, as it does
only cause any problems on CPUs that can't do unaligned access.
--
Greetings Michael.
On Thu, Jan 24, 2008 at 12:27:03PM -0800, Linus Torvalds wrote:
>
>
> On Tue, 8 Jan 2008, Michael Buesch wrote:
> > > >
> > > > Can you check if that is the
> > > > WARN_ON_ONCE(((unsigned long)(skb->data + hdrlen)) & 3);
> > > > in rx.c line 1486?
> >
> > Yes fine.
> > Patches are on their way. Ignore the warning for now. It is harmless.
>
> I don't think this ever got fixed.
>
> I don't see any alternative but just uncomment that bogus warning, because
> it's otherwise going to just cause way more noise than it's worth. It's
> apparently known to developers, and as such it's worthless in the source
> code except as a way to make poor users worry.
>
> It's been in the top oops/warnings report for the last three weeks, and I
> haven't gotten any patches for it, so I'm a bit grumpy. What's the point
> of having a WARN_ON() if nobody involved *does* anything about it?
We've been trying to shame the iwlwifi team into fixing it. They have
been blaming their firmware, but I think they could fix the alignment
in their driver.
There is no great harm in reverting
81100eb80add328c4d2a377326f15aa0e7236398 if you would like to go ahead
and push the 2.6.24 release. I suspect, however, that the mac80211
guys would like to keep it (or put it back for 2.6.25) to continue
to shame driver developers in the future.
John
--
John W. Linville
[email protected]
On Sat, 26 Jan 2008, David Miller wrote:
>
> PowerPC handles unaligned accesses transparently, so it is safe
> for them to make this setting.
.. as does x86. Better than PowerPC, btw.
> It would not work out on sparc64 for example.
Right. Which is why different architectures should do different things,
and which is why this should absolutely NOT be a driver issue. The driver
should do what is natural to it.
If giving aligned data is reasonable, then obviously the driver should be
striving for that, since regardless of architecture, alignment will never
HURT the CPU.
But you seem to be totally ignoring people when they tell you that the
hardware cannot necessarily do unaligned DMA well, or at all.
We've had that with disk controllers that simply *cannot* do DMA at less
than 4-byte alignment, and where anything else has to be either done in
software with PIO, or by memcpy.
You've also had Intel engineers tell you that the actual wireless stuff
isn't just "firmware" - everybody who claims that this is an easy fix from
Intel apparently has just been outright *lying*.
> So you'll see drivers for chips that have to 64-byte align the
> ethernet header in the RX packet for whatever reason, simply
> copy into a fresh buffer on receive.
>
> Some drivers do this only platforms where unalign accesses trap or
> simply do not work.
.. and can't you see that this is STUPID?
Honestly, now, David - take a step back, and allow yourself to think about
the issue. You have the following undeniable FACTS:
- some hardware only does certain DMA alignment. This is a FACT. Treat it
as such, instead of whining about how Intel alledgely could easily fix
it.
Quite frankly, I've been disgusted by people who say that it's "easy to
fix firmware". It's not. It then turns out that Intel people actually
step up and tell you that it's not even a firmware issue, are you now
going to say "It's easy to fix hardware - just a few lines of RTL"?
So instead of this idiotic whining about "easy to fix firmware" that
turned out to be just total ignorance, how about the people who made
that claim step up and admit that (a) apparently not true, but also (b)
even if it had been "just" firmware, that was a totally idiotic claim
to begin with, since it's never been a valid excuse anyway!
And once you admit that first part ("some hardware will have different
aligment requirements than the network stack has"), go on to the OBVIOUS
secont step, which is to realize two other undeniable truths:
- requiring individual drivers to do something in every driver is stupid
if it all boils down to something that could be done in *one* place
(the network stack entry).
This is so obviously true that I really cannot see why you don't seem
to accept this. Drivers are hard enough to write as-is, and we want to
make driver writers have to worry as little as possible about things
like this.
- The above is *doubly* true when it's simply not the case that "drivers
should always align packets to X bytes".
Many CPU's handle unaligned accesses with little or no cost at all.
Most x86 chips have absolutely *zero* cost for an unaigned access that
doesn't cross a cache access boundary (often 8 bytes, these days I
think it's 16), and even when it requires crossing the natural internal
cache access bus width, it's usually not that high.
In other words, what you ask drivers to do is to not just create extra
work for them, but create extra work for them in ways that aren't even
obvious or relevant to most driver writers. Because on many architectures,
they are better off *not* aligining things.
End result? When Intel writes a driver, they do it for the CPU
architecture they care about. Which does *not* have the idiotic unaligned
access problems that sparc has. So they do what makes sense to them, and I
reall ycannot blame them for it.
So there's a very simple solution to this all: just make the entry to the
networking layer re-align thing if required. In *one* single well-tested
place. One that can do some smart things, like decide that re-aligning
small packets may make sense even on architectures that don't have
problems with unaligned accesses, just because the packet fits in one
cacheline anyway.
That way al drivers can do what is best for *them*, and not have to worry.
Yes, they'd like to align things naturally (in order to avoid the cost of
the memcp()), but you don't create unnecessary and *stupid* work for them.
Linus
From: Jeff Garzik <[email protected]>
Date: Sun, 27 Jan 2008 02:16:00 -0500
> It would be nice to stop maintaining code like the following in
> drivers/net/tulip/tulip_core.c:
>
> > /* Set the copy breakpoint for the copy-only-tiny-buffer Rx structure. */
> > #if defined(__alpha__) || defined(__arm__) || defined(__hppa__) \
> > || defined(CONFIG_SPARC) || defined(__ia64__) \
> > || defined(__sh__) || defined(__mips__)
> > static int rx_copybreak = 1518;
> > #else
> > static int rx_copybreak = 100;
> > #endif
>
> The driver passes a lot of information implicitly to the net stack
> simply via its "style" of allocation and mapping.
I just want to note in passing that we should remember that
there is a secoondary reason this copy-break logic exists
in the drivers.
When a reeived packet is attached to, and charged to, a socket,
we account the real amount of memory the SKB has allocated to it.
This means if the driver allocates full MTU sized frames for the
device to DMA into, we can cause unintended problems for passing
that packet directly in if there is only say 100 bytes of data.
The socket gets charged for a full MTU's amount of memory instead
of something more on the order of 100 bytes :-)
In fact that is the original reason all of these things exists,
it was just simple to extend it to handle alignment cases too.
Anyways, once we put the logic for unaligned handling into a
centralized location the above can now evaluate to a constant,
or default to the lower value of 100.
Linus Torvalds wrote:
> But we shouldn't make up stupid rules like "network drivers *have* to
> align packets correctly", simply because such rules may not make sense to
> the driver writer. If the hardware simply cannot do it, or has some
> horrible performance behaviour when it does so, it's stupid to tell a
> driver that it has to do it.
<shrug> seems like it should be possible to have an arch
copy-and-align-if-necessary hook at the point of packet reception
(netif_rx or netif_receive_skb).
And it would certainly be a nice cleanup to move all those driver
implementations of rx_copybreak into common code.
But ultimately the driver knows the hardware (alignment requirements, RX
skb allocation details) best, so by definition the low-level driver must
communicate that information /somehow/.
That data may be communicated implicitly, sure: maybe the
aforementioned arch hook could simply look at the alignment of the skb's
data, and make decision based on that (the driver still, by definition,
ultimately controls RX skb allocation, alignment, and DMA boundaries and
mappings)
It would be nice to stop maintaining code like the following in
drivers/net/tulip/tulip_core.c:
> /* Set the copy breakpoint for the copy-only-tiny-buffer Rx structure. */
> #if defined(__alpha__) || defined(__arm__) || defined(__hppa__) \
> || defined(CONFIG_SPARC) || defined(__ia64__) \
> || defined(__sh__) || defined(__mips__)
> static int rx_copybreak = 1518;
> #else
> static int rx_copybreak = 100;
> #endif
The driver passes a lot of information implicitly to the net stack
simply via its "style" of allocation and mapping.
Its really a question of where you want to pay the cost of unaligned
accesses, and how much is too much. If the data is going to be memcpy'd
to userspace or another buffer almost immediately, maybe we don't even
care, even on non-x86.
Never know until you bench, I guess...
Jeff
From: Linus Torvalds <[email protected]>
Date: Fri, 25 Jan 2008 11:07:47 -0800 (PST)
>
>
> On Fri, 25 Jan 2008, Michael Buesch wrote:
> >
> > The problem is _not_ the wireless header access, but the alignment of the embedded
> > protocol stack, if the header does not have a size aligned to 4.
> > Do we want to clutter the whole networking stack below wireless with
> > get_unaligned() or attribute(packed) or something like that?
>
> That's what all the other protocols do, isn't it?
No.
> For example, on PowerPC, NET_IP_ALIGN is 0 - explicitly so that the *dma*
> from the card should be aligned, even if that in turn means that the IP
> payload itself is then just two-byte aligned rather than word-aligned
> (14-byte ethernet headers and all that).
PowerPC handles unaligned accesses transparently, so it is safe
for them to make this setting.
It would not work out on sparc64 for example.
What happens in practice is that the drivers provide something
reasonably aligned for IPV4 headers. That's why we don't mark the
IPV4 header structure as packed and that's why we don't have to use
get_unaligned() to dereference the 32-bit addresses in there.
So you'll see drivers for chips that have to 64-byte align the
ethernet header in the RX packet for whatever reason, simply
copy into a fresh buffer on receive.
Some drivers do this only platforms where unalign accesses trap or
simply do not work.