* Re: Linux 2.6.24-rc7 [not found] <alpine.LFD.1.00.0801061410290.3148@woody.linux-foundation.org> @ 2008-01-07 16:14 ` Alejandro Riveira Fernández 2008-01-07 16:24 ` Michael Buesch 0 siblings, 1 reply; 63+ messages in thread From: Alejandro Riveira Fernández @ 2008-01-07 16:14 UTC (permalink / raw) To: Linus Torvalds; +Cc: Linux Kernel Mailing List, linux-wireless El Sun, 6 Jan 2008 14:19:16 -0800 (PST) Linus Torvalds <torvalds@linux-foundation.org> 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 - To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-07 16:14 ` Linux 2.6.24-rc7 Alejandro Riveira Fernández @ 2008-01-07 16:24 ` Michael Buesch 2008-01-07 16:52 ` Alejandro Riveira Fernández 0 siblings, 1 reply; 63+ messages in thread From: Michael Buesch @ 2008-01-07 16:24 UTC (permalink / raw) To: Alejandro Riveira Fernández Cc: Linus Torvalds, Linux Kernel Mailing List, linux-wireless 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 <torvalds@linux-foundation.org> 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. - To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-07 16:24 ` Michael Buesch @ 2008-01-07 16:52 ` Alejandro Riveira Fernández 2008-01-07 17:30 ` Michael Buesch 0 siblings, 1 reply; 63+ messages in thread From: Alejandro Riveira Fernández @ 2008-01-07 16:52 UTC (permalink / raw) To: Michael Buesch; +Cc: Linus Torvalds, Linux Kernel Mailing List, linux-wireless El Mon, 7 Jan 2008 17:24:03 +0100 Michael Buesch <mb@bu3sch.de> 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 - To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-07 16:52 ` Alejandro Riveira Fernández @ 2008-01-07 17:30 ` Michael Buesch 2008-01-07 20:23 ` Alejandro Riveira Fernández 0 siblings, 1 reply; 63+ messages in thread From: Michael Buesch @ 2008-01-07 17:30 UTC (permalink / raw) To: Alejandro Riveira Fernández Cc: Linus Torvalds, Linux Kernel Mailing List, linux-wireless 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 <mb@bu3sch.de> 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. - To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-07 17:30 ` Michael Buesch @ 2008-01-07 20:23 ` Alejandro Riveira Fernández 2008-01-08 15:30 ` Michael Buesch 0 siblings, 1 reply; 63+ messages in thread From: Alejandro Riveira Fernández @ 2008-01-07 20:23 UTC (permalink / raw) To: Michael Buesch; +Cc: Linus Torvalds, Linux Kernel Mailing List, linux-wireless El Mon, 7 Jan 2008 18:30:51 +0100 Michael Buesch <mb@bu3sch.de> 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 <mb@bu3sch.de> 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 - To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-07 20:23 ` Alejandro Riveira Fernández @ 2008-01-08 15:30 ` Michael Buesch 2008-01-08 15:55 ` Alejandro Riveira Fernández 2008-01-24 20:27 ` Linus Torvalds 0 siblings, 2 replies; 63+ messages in thread From: Michael Buesch @ 2008-01-08 15:30 UTC (permalink / raw) To: Alejandro Riveira Fernández Cc: Linus Torvalds, Linux Kernel Mailing List, linux-wireless 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. - To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-08 15:30 ` Michael Buesch @ 2008-01-08 15:55 ` Alejandro Riveira Fernández 2008-01-24 20:27 ` Linus Torvalds 1 sibling, 0 replies; 63+ messages in thread From: Alejandro Riveira Fernández @ 2008-01-08 15:55 UTC (permalink / raw) To: Michael Buesch; +Cc: Linus Torvalds, Linux Kernel Mailing List, linux-wireless El Tue, 8 Jan 2008 16:30:30 +0100 Michael Buesch <mb@bu3sch.de> 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 :) - To unsubscribe from this list: send the line "unsubscribe linux-wireles= s" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-08 15:30 ` Michael Buesch 2008-01-08 15:55 ` Alejandro Riveira Fernández @ 2008-01-24 20:27 ` Linus Torvalds 2008-01-24 21:07 ` John W. Linville 2008-01-24 22:17 ` Michael Buesch 1 sibling, 2 replies; 63+ messages in thread From: Linus Torvalds @ 2008-01-24 20:27 UTC (permalink / raw) To: Michael Buesch; +Cc: linux-wireless 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-24 20:27 ` Linus Torvalds @ 2008-01-24 21:07 ` John W. Linville 2008-01-24 21:34 ` Linus Torvalds 2008-01-24 22:17 ` Michael Buesch 1 sibling, 1 reply; 63+ messages in thread From: John W. Linville @ 2008-01-24 21:07 UTC (permalink / raw) To: Linus Torvalds; +Cc: Michael Buesch, linux-wireless 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 linville@tuxdriver.com ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-24 21:07 ` John W. Linville @ 2008-01-24 21:34 ` Linus Torvalds 2008-01-25 12:29 ` Johannes Berg 0 siblings, 1 reply; 63+ messages in thread From: Linus Torvalds @ 2008-01-24 21:34 UTC (permalink / raw) To: John W. Linville; +Cc: Michael Buesch, linux-wireless 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-24 21:34 ` Linus Torvalds @ 2008-01-25 12:29 ` Johannes Berg 2008-01-25 16:08 ` Linus Torvalds 0 siblings, 1 reply; 63+ messages in thread From: Johannes Berg @ 2008-01-25 12:29 UTC (permalink / raw) To: Linus Torvalds; +Cc: John W. Linville, Michael Buesch, linux-wireless [-- Attachment #1: Type: text/plain, Size: 2129 bytes --] 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 [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 828 bytes --] ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 12:29 ` Johannes Berg @ 2008-01-25 16:08 ` Linus Torvalds 2008-01-25 16:23 ` Michael Buesch 0 siblings, 1 reply; 63+ messages in thread From: Linus Torvalds @ 2008-01-25 16:08 UTC (permalink / raw) To: Johannes Berg; +Cc: John W. Linville, Michael Buesch, linux-wireless 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 16:08 ` Linus Torvalds @ 2008-01-25 16:23 ` Michael Buesch 2008-01-25 16:43 ` Linus Torvalds 0 siblings, 1 reply; 63+ messages in thread From: Michael Buesch @ 2008-01-25 16:23 UTC (permalink / raw) To: Linus Torvalds; +Cc: Johannes Berg, John W. Linville, linux-wireless 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 16:23 ` Michael Buesch @ 2008-01-25 16:43 ` Linus Torvalds 2008-01-25 17:27 ` Dan Williams 2008-01-25 18:21 ` Michael Buesch 0 siblings, 2 replies; 63+ messages in thread From: Linus Torvalds @ 2008-01-25 16:43 UTC (permalink / raw) To: Michael Buesch; +Cc: Johannes Berg, John W. Linville, linux-wireless 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 16:43 ` Linus Torvalds @ 2008-01-25 17:27 ` Dan Williams 2008-01-25 17:38 ` Linus Torvalds 2008-01-25 18:21 ` Michael Buesch 1 sibling, 1 reply; 63+ messages in thread From: Dan Williams @ 2008-01-25 17:27 UTC (permalink / raw) To: Linus Torvalds Cc: Michael Buesch, Johannes Berg, John W. Linville, linux-wireless 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 17:27 ` Dan Williams @ 2008-01-25 17:38 ` Linus Torvalds 2008-01-25 17:42 ` Dan Williams 2008-01-25 18:22 ` Linus Torvalds 0 siblings, 2 replies; 63+ messages in thread From: Linus Torvalds @ 2008-01-25 17:38 UTC (permalink / raw) To: Dan Williams Cc: Michael Buesch, Johannes Berg, John W. Linville, linux-wireless 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 17:38 ` Linus Torvalds @ 2008-01-25 17:42 ` Dan Williams 2008-02-05 20:55 ` Russell S. Senior 2008-01-25 18:22 ` Linus Torvalds 1 sibling, 1 reply; 63+ messages in thread From: Dan Williams @ 2008-01-25 17:42 UTC (permalink / raw) To: Linus Torvalds Cc: Michael Buesch, Johannes Berg, John W. Linville, linux-wireless 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 17:42 ` Dan Williams @ 2008-02-05 20:55 ` Russell S. Senior 0 siblings, 0 replies; 63+ messages in thread From: Russell S. Senior @ 2008-02-05 20:55 UTC (permalink / raw) To: Dan Williams Cc: Linus Torvalds, Michael Buesch, Johannes Berg, John W. Linville, linux-wireless >>>>> "Dan" == Dan Williams <dcbw@redhat.com> writes: Linus> Is it even physically *possible* to use that Intel wireless Linus> chipset with anything but x86 CPU's (not just that, but Linus> actually _Intel_ x86 CPU's)? And would it make any sense Linus> what-so-ever even if it was? Dan> Yeah, 3945 and 4965 cards are mini PCI-E these days. And there Dan> are ipw2100, ipw2200, and ipw2915 mini PCI cards that you could Dan> stick in embedded systems and such. Though of course everyone Dan> doing embedded stuff uses either Atheros or PrismII still, Dan> certainly not ipw/iwl. Fwiw, I would if I could. I've got a couple mini-PCI Intel radios sitting here that I would like to be able to use in various single board computers (e.g. soekris and netgear wgt634u). Right now, I am mostly constrained to using Atheros radios, which is a situation I'd rather not be in and have been looking forward to growing out of. -- Russell Senior ``I have nine fingers; you have ten.'' seniorr@aracnet.com ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 17:38 ` Linus Torvalds 2008-01-25 17:42 ` Dan Williams @ 2008-01-25 18:22 ` Linus Torvalds 2008-01-25 18:30 ` Michael Buesch 2008-01-26 13:22 ` David Miller 1 sibling, 2 replies; 63+ messages in thread From: Linus Torvalds @ 2008-01-25 18:22 UTC (permalink / raw) To: Dan Williams Cc: Michael Buesch, Johannes Berg, John W. Linville, linux-wireless 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 18:22 ` Linus Torvalds @ 2008-01-25 18:30 ` Michael Buesch 2008-01-25 19:07 ` Linus Torvalds 2008-01-26 13:22 ` David Miller 1 sibling, 1 reply; 63+ messages in thread From: Michael Buesch @ 2008-01-25 18:30 UTC (permalink / raw) To: Linus Torvalds Cc: Dan Williams, Johannes Berg, John W. Linville, linux-wireless 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 18:30 ` Michael Buesch @ 2008-01-25 19:07 ` Linus Torvalds 2008-01-25 19:34 ` Michael Buesch ` (3 more replies) 0 siblings, 4 replies; 63+ messages in thread From: Linus Torvalds @ 2008-01-25 19:07 UTC (permalink / raw) To: Michael Buesch Cc: Dan Williams, Johannes Berg, John W. Linville, linux-wireless 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 19:07 ` Linus Torvalds @ 2008-01-25 19:34 ` Michael Buesch 2008-01-25 19:48 ` John W. Linville ` (2 subsequent siblings) 3 siblings, 0 replies; 63+ messages in thread From: Michael Buesch @ 2008-01-25 19:34 UTC (permalink / raw) To: Linus Torvalds Cc: Dan Williams, Johannes Berg, John W. Linville, linux-wireless, David Miller, Jeff Garzik 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 19:07 ` Linus Torvalds 2008-01-25 19:34 ` Michael Buesch @ 2008-01-25 19:48 ` John W. Linville 2008-01-25 19:50 ` John W. Linville 2008-01-25 20:28 ` Linus Torvalds 2008-01-25 23:22 ` Jeff Garzik 2008-01-26 13:27 ` David Miller 3 siblings, 2 replies; 63+ messages in thread From: John W. Linville @ 2008-01-25 19:48 UTC (permalink / raw) To: Linus Torvalds Cc: Michael Buesch, Dan Williams, Johannes Berg, linux-wireless 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 linville@tuxdriver.com ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 19:48 ` John W. Linville @ 2008-01-25 19:50 ` John W. Linville 2008-01-25 21:18 ` John W. Linville 2008-01-25 20:28 ` Linus Torvalds 1 sibling, 1 reply; 63+ messages in thread From: John W. Linville @ 2008-01-25 19:50 UTC (permalink / raw) To: Linus Torvalds Cc: Michael Buesch, Dan Williams, Johannes Berg, linux-wireless 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 linville@tuxdriver.com ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 19:50 ` John W. Linville @ 2008-01-25 21:18 ` John W. Linville 2008-01-25 21:56 ` Linus Torvalds ` (2 more replies) 0 siblings, 3 replies; 63+ messages in thread From: John W. Linville @ 2008-01-25 21:18 UTC (permalink / raw) To: Linus Torvalds Cc: Michael Buesch, Dan Williams, Johannes Berg, linux-wireless 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 <linville@tuxdriver.com> 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 <linville@tuxdriver.com> --- 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 linville@tuxdriver.com ^ permalink raw reply related [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 21:18 ` John W. Linville @ 2008-01-25 21:56 ` Linus Torvalds 2008-01-25 22:46 ` John W. Linville 2008-01-26 13:47 ` David Miller 2008-01-25 22:02 ` Guy Cohen 2008-01-26 13:40 ` David Miller 2 siblings, 2 replies; 63+ messages in thread From: Linus Torvalds @ 2008-01-25 21:56 UTC (permalink / raw) To: John W. Linville Cc: Michael Buesch, Dan Williams, Johannes Berg, linux-wireless 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 21:56 ` Linus Torvalds @ 2008-01-25 22:46 ` John W. Linville 2008-01-25 23:20 ` Guy Cohen 2008-01-26 13:53 ` David Miller 2008-01-26 13:47 ` David Miller 1 sibling, 2 replies; 63+ messages in thread From: John W. Linville @ 2008-01-25 22:46 UTC (permalink / raw) To: Linus Torvalds Cc: Michael Buesch, Dan Williams, Johannes Berg, linux-wireless 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 linville@tuxdriver.com ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 22:46 ` John W. Linville @ 2008-01-25 23:20 ` Guy Cohen 2008-01-26 13:53 ` David Miller 1 sibling, 0 replies; 63+ messages in thread From: Guy Cohen @ 2008-01-25 23:20 UTC (permalink / raw) To: John W. Linville Cc: Linus Torvalds, Michael Buesch, Dan Williams, Johannes Berg, linux-wireless On 1/26/08, John W. Linville <linville@tuxdriver.com> 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 22:46 ` John W. Linville 2008-01-25 23:20 ` Guy Cohen @ 2008-01-26 13:53 ` David Miller 1 sibling, 0 replies; 63+ messages in thread From: David Miller @ 2008-01-26 13:53 UTC (permalink / raw) To: linville; +Cc: torvalds, mb, dcbw, johannes, linux-wireless From: "John W. Linville" <linville@tuxdriver.com> 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 21:56 ` Linus Torvalds 2008-01-25 22:46 ` John W. Linville @ 2008-01-26 13:47 ` David Miller 1 sibling, 0 replies; 63+ messages in thread From: David Miller @ 2008-01-26 13:47 UTC (permalink / raw) To: torvalds; +Cc: linville, mb, dcbw, johannes, linux-wireless From: Linus Torvalds <torvalds@linux-foundation.org> 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 21:18 ` John W. Linville 2008-01-25 21:56 ` Linus Torvalds @ 2008-01-25 22:02 ` Guy Cohen 2008-01-26 13:40 ` David Miller 2 siblings, 0 replies; 63+ messages in thread From: Guy Cohen @ 2008-01-25 22:02 UTC (permalink / raw) To: John W. Linville Cc: Linus Torvalds, Michael Buesch, Dan Williams, Johannes Berg, linux-wireless 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 <linville@tuxdriver.com> 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 <linville@tuxdriver.com> > 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 <linville@tuxdriver.com> > --- > 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 > linville@tuxdriver.com > - > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 21:18 ` John W. Linville 2008-01-25 21:56 ` Linus Torvalds 2008-01-25 22:02 ` Guy Cohen @ 2008-01-26 13:40 ` David Miller 2 siblings, 0 replies; 63+ messages in thread From: David Miller @ 2008-01-26 13:40 UTC (permalink / raw) To: linville; +Cc: torvalds, mb, dcbw, johannes, linux-wireless From: "John W. Linville" <linville@tuxdriver.com> 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 19:48 ` John W. Linville 2008-01-25 19:50 ` John W. Linville @ 2008-01-25 20:28 ` Linus Torvalds 2008-01-26 13:37 ` David Miller 1 sibling, 1 reply; 63+ messages in thread From: Linus Torvalds @ 2008-01-25 20:28 UTC (permalink / raw) To: John W. Linville Cc: Michael Buesch, Dan Williams, Johannes Berg, linux-wireless 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 20:28 ` Linus Torvalds @ 2008-01-26 13:37 ` David Miller 2008-01-27 6:32 ` Linus Torvalds 0 siblings, 1 reply; 63+ messages in thread From: David Miller @ 2008-01-26 13:37 UTC (permalink / raw) To: torvalds; +Cc: linville, mb, dcbw, johannes, linux-wireless From: Linus Torvalds <torvalds@linux-foundation.org> 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-26 13:37 ` David Miller @ 2008-01-27 6:32 ` Linus Torvalds 2008-01-27 7:16 ` Jeff Garzik 0 siblings, 1 reply; 63+ messages in thread From: Linus Torvalds @ 2008-01-27 6:32 UTC (permalink / raw) To: David Miller; +Cc: linville, mb, dcbw, johannes, linux-wireless 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-27 6:32 ` Linus Torvalds @ 2008-01-27 7:16 ` Jeff Garzik 2008-01-27 7:24 ` David Miller 0 siblings, 1 reply; 63+ messages in thread From: Jeff Garzik @ 2008-01-27 7:16 UTC (permalink / raw) To: Linus Torvalds; +Cc: David Miller, linville, mb, dcbw, johannes, linux-wireless 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-27 7:16 ` Jeff Garzik @ 2008-01-27 7:24 ` David Miller 2008-01-27 7:54 ` Linus Torvalds 0 siblings, 1 reply; 63+ messages in thread From: David Miller @ 2008-01-27 7:24 UTC (permalink / raw) To: jeff; +Cc: torvalds, linville, mb, dcbw, johannes, linux-wireless From: Jeff Garzik <jeff@garzik.org> 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-27 7:24 ` David Miller @ 2008-01-27 7:54 ` Linus Torvalds 2008-01-28 3:15 ` David Miller 0 siblings, 1 reply; 63+ messages in thread From: Linus Torvalds @ 2008-01-27 7:54 UTC (permalink / raw) To: David Miller; +Cc: jeff, linville, mb, dcbw, johannes, linux-wireless 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-27 7:54 ` Linus Torvalds @ 2008-01-28 3:15 ` David Miller 0 siblings, 0 replies; 63+ messages in thread From: David Miller @ 2008-01-28 3:15 UTC (permalink / raw) To: torvalds; +Cc: jeff, linville, mb, dcbw, johannes, linux-wireless From: Linus Torvalds <torvalds@linux-foundation.org> 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 19:07 ` Linus Torvalds 2008-01-25 19:34 ` Michael Buesch 2008-01-25 19:48 ` John W. Linville @ 2008-01-25 23:22 ` Jeff Garzik 2008-01-26 13:27 ` David Miller 3 siblings, 0 replies; 63+ messages in thread From: Jeff Garzik @ 2008-01-25 23:22 UTC (permalink / raw) To: Linus Torvalds, Michael Buesch Cc: Dan Williams, Johannes Berg, John W. Linville, linux-wireless 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 19:07 ` Linus Torvalds ` (2 preceding siblings ...) 2008-01-25 23:22 ` Jeff Garzik @ 2008-01-26 13:27 ` David Miller 2008-01-27 6:25 ` Linus Torvalds 3 siblings, 1 reply; 63+ messages in thread From: David Miller @ 2008-01-26 13:27 UTC (permalink / raw) To: torvalds; +Cc: mb, dcbw, johannes, linville, linux-wireless From: Linus Torvalds <torvalds@linux-foundation.org> 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-26 13:27 ` David Miller @ 2008-01-27 6:25 ` Linus Torvalds 0 siblings, 0 replies; 63+ messages in thread From: Linus Torvalds @ 2008-01-27 6:25 UTC (permalink / raw) To: David Miller; +Cc: mb, dcbw, johannes, linville, linux-wireless 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 18:22 ` Linus Torvalds 2008-01-25 18:30 ` Michael Buesch @ 2008-01-26 13:22 ` David Miller 1 sibling, 0 replies; 63+ messages in thread From: David Miller @ 2008-01-26 13:22 UTC (permalink / raw) To: torvalds; +Cc: dcbw, mb, johannes, linville, linux-wireless From: Linus Torvalds <torvalds@linux-foundation.org> 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 :-) ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 16:43 ` Linus Torvalds 2008-01-25 17:27 ` Dan Williams @ 2008-01-25 18:21 ` Michael Buesch 2008-01-25 18:34 ` Linus Torvalds 2008-01-25 18:34 ` John W. Linville 1 sibling, 2 replies; 63+ messages in thread From: Michael Buesch @ 2008-01-25 18:21 UTC (permalink / raw) To: Linus Torvalds; +Cc: Johannes Berg, John W. Linville, linux-wireless 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 18:21 ` Michael Buesch @ 2008-01-25 18:34 ` Linus Torvalds 2008-01-25 18:41 ` Michael Buesch 2008-01-25 18:34 ` John W. Linville 1 sibling, 1 reply; 63+ messages in thread From: Linus Torvalds @ 2008-01-25 18:34 UTC (permalink / raw) To: Michael Buesch; +Cc: Johannes Berg, John W. Linville, linux-wireless 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 18:34 ` Linus Torvalds @ 2008-01-25 18:41 ` Michael Buesch 2008-01-25 21:11 ` Inaky Perez-Gonzalez 0 siblings, 1 reply; 63+ messages in thread From: Michael Buesch @ 2008-01-25 18:41 UTC (permalink / raw) To: Linus Torvalds; +Cc: Johannes Berg, John W. Linville, linux-wireless 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 18:41 ` Michael Buesch @ 2008-01-25 21:11 ` Inaky Perez-Gonzalez 2008-01-25 21:21 ` Michael Buesch 0 siblings, 1 reply; 63+ messages in thread From: Inaky Perez-Gonzalez @ 2008-01-25 21:11 UTC (permalink / raw) To: Michael Buesch Cc: Linus Torvalds, Johannes Berg, John W. Linville, linux-wireless 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 21:11 ` Inaky Perez-Gonzalez @ 2008-01-25 21:21 ` Michael Buesch 2008-01-25 21:28 ` Inaky Perez-Gonzalez ` (3 more replies) 0 siblings, 4 replies; 63+ messages in thread From: Michael Buesch @ 2008-01-25 21:21 UTC (permalink / raw) To: Inaky Perez-Gonzalez Cc: Linus Torvalds, Johannes Berg, John W. Linville, linux-wireless 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 21:21 ` Michael Buesch @ 2008-01-25 21:28 ` Inaky Perez-Gonzalez 2008-01-26 13:42 ` David Miller 2008-01-25 21:46 ` John W. Linville ` (2 subsequent siblings) 3 siblings, 1 reply; 63+ messages in thread From: Inaky Perez-Gonzalez @ 2008-01-25 21:28 UTC (permalink / raw) To: Michael Buesch Cc: Linus Torvalds, Johannes Berg, John W. Linville, linux-wireless 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]. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 21:28 ` Inaky Perez-Gonzalez @ 2008-01-26 13:42 ` David Miller 2008-01-27 2:26 ` Luis R. Rodriguez 2008-01-29 19:07 ` Inaky Perez-Gonzalez 0 siblings, 2 replies; 63+ messages in thread From: David Miller @ 2008-01-26 13:42 UTC (permalink / raw) To: inaky; +Cc: mb, torvalds, johannes, linville, linux-wireless From: Inaky Perez-Gonzalez <inaky@linux.intel.com> 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-26 13:42 ` David Miller @ 2008-01-27 2:26 ` Luis R. Rodriguez 2008-01-29 19:07 ` Inaky Perez-Gonzalez 1 sibling, 0 replies; 63+ messages in thread From: Luis R. Rodriguez @ 2008-01-27 2:26 UTC (permalink / raw) To: David Miller Cc: inaky, mb, torvalds, johannes, linville, linux-wireless, Bradley M. Kuhn, Henry Ptasinski On Jan 26, 2008 8:42 AM, David Miller <davem@davemloft.net> wrote: > From: Inaky Perez-Gonzalez <inaky@linux.intel.com> > 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-26 13:42 ` David Miller 2008-01-27 2:26 ` Luis R. Rodriguez @ 2008-01-29 19:07 ` Inaky Perez-Gonzalez 1 sibling, 0 replies; 63+ messages in thread From: Inaky Perez-Gonzalez @ 2008-01-29 19:07 UTC (permalink / raw) To: David Miller; +Cc: mb, torvalds, johannes, linville, linux-wireless On Saturday 26 January 2008, David Miller wrote: > From: Inaky Perez-Gonzalez <inaky@linux.intel.com> > 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... :) ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 21:21 ` Michael Buesch 2008-01-25 21:28 ` Inaky Perez-Gonzalez @ 2008-01-25 21:46 ` John W. Linville 2008-01-25 22:15 ` Michael Buesch ` (2 more replies) 2008-01-25 21:46 ` Guy Cohen 2008-01-25 21:54 ` Linus Torvalds 3 siblings, 3 replies; 63+ messages in thread From: John W. Linville @ 2008-01-25 21:46 UTC (permalink / raw) To: Michael Buesch Cc: Inaky Perez-Gonzalez, Linus Torvalds, Johannes Berg, linux-wireless 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 linville@tuxdriver.com ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 21:46 ` John W. Linville @ 2008-01-25 22:15 ` Michael Buesch 2008-01-25 22:34 ` Tomas Winkler 2008-01-26 13:49 ` David Miller 2 siblings, 0 replies; 63+ messages in thread From: Michael Buesch @ 2008-01-25 22:15 UTC (permalink / raw) To: John W. Linville Cc: Inaky Perez-Gonzalez, Linus Torvalds, Johannes Berg, linux-wireless 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 21:46 ` John W. Linville 2008-01-25 22:15 ` Michael Buesch @ 2008-01-25 22:34 ` Tomas Winkler 2008-01-26 13:49 ` David Miller 2 siblings, 0 replies; 63+ messages in thread From: Tomas Winkler @ 2008-01-25 22:34 UTC (permalink / raw) To: John W. Linville Cc: Michael Buesch, Inaky Perez-Gonzalez, Linus Torvalds, Johannes Berg, linux-wireless On Jan 25, 2008 11:46 PM, John W. Linville <linville@tuxdriver.com> 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 > linville@tuxdriver.com > 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 21:46 ` John W. Linville 2008-01-25 22:15 ` Michael Buesch 2008-01-25 22:34 ` Tomas Winkler @ 2008-01-26 13:49 ` David Miller 2 siblings, 0 replies; 63+ messages in thread From: David Miller @ 2008-01-26 13:49 UTC (permalink / raw) To: linville; +Cc: mb, inaky, torvalds, johannes, linux-wireless From: "John W. Linville" <linville@tuxdriver.com> 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 21:21 ` Michael Buesch 2008-01-25 21:28 ` Inaky Perez-Gonzalez 2008-01-25 21:46 ` John W. Linville @ 2008-01-25 21:46 ` Guy Cohen 2008-01-25 21:54 ` Linus Torvalds 3 siblings, 0 replies; 63+ messages in thread From: Guy Cohen @ 2008-01-25 21:46 UTC (permalink / raw) To: Michael Buesch Cc: Inaky Perez-Gonzalez, Linus Torvalds, Johannes Berg, John W. Linville, linux-wireless On 1/25/08, Michael Buesch <mb@bu3sch.de> 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 21:21 ` Michael Buesch ` (2 preceding siblings ...) 2008-01-25 21:46 ` Guy Cohen @ 2008-01-25 21:54 ` Linus Torvalds 2008-01-26 13:46 ` David Miller 3 siblings, 1 reply; 63+ messages in thread From: Linus Torvalds @ 2008-01-25 21:54 UTC (permalink / raw) To: Michael Buesch Cc: Inaky Perez-Gonzalez, Johannes Berg, John W. Linville, linux-wireless 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 21:54 ` Linus Torvalds @ 2008-01-26 13:46 ` David Miller 0 siblings, 0 replies; 63+ messages in thread From: David Miller @ 2008-01-26 13:46 UTC (permalink / raw) To: torvalds; +Cc: mb, inaky, johannes, linville, linux-wireless From: Linus Torvalds <torvalds@linux-foundation.org> 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-25 18:21 ` Michael Buesch 2008-01-25 18:34 ` Linus Torvalds @ 2008-01-25 18:34 ` John W. Linville 1 sibling, 0 replies; 63+ messages in thread From: John W. Linville @ 2008-01-25 18:34 UTC (permalink / raw) To: Michael Buesch; +Cc: Linus Torvalds, Johannes Berg, linux-wireless 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 linville@tuxdriver.com ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-24 20:27 ` Linus Torvalds 2008-01-24 21:07 ` John W. Linville @ 2008-01-24 22:17 ` Michael Buesch 2008-01-24 22:26 ` Linus Torvalds 1 sibling, 1 reply; 63+ messages in thread From: Michael Buesch @ 2008-01-24 22:17 UTC (permalink / raw) To: Linus Torvalds; +Cc: linux-wireless 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-24 22:17 ` Michael Buesch @ 2008-01-24 22:26 ` Linus Torvalds 2008-01-24 22:33 ` Michael Buesch 0 siblings, 1 reply; 63+ messages in thread From: Linus Torvalds @ 2008-01-24 22:26 UTC (permalink / raw) To: Michael Buesch; +Cc: linux-wireless 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 ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: Linux 2.6.24-rc7 2008-01-24 22:26 ` Linus Torvalds @ 2008-01-24 22:33 ` Michael Buesch 0 siblings, 0 replies; 63+ messages in thread From: Michael Buesch @ 2008-01-24 22:33 UTC (permalink / raw) To: Linus Torvalds; +Cc: linux-wireless 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. ^ permalink raw reply [flat|nested] 63+ messages in thread
end of thread, other threads:[~2008-02-05 21:07 UTC | newest]
Thread overview: 63+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <alpine.LFD.1.00.0801061410290.3148@woody.linux-foundation.org>
2008-01-07 16:14 ` Linux 2.6.24-rc7 Alejandro Riveira Fernández
2008-01-07 16:24 ` Michael Buesch
2008-01-07 16:52 ` Alejandro Riveira Fernández
2008-01-07 17:30 ` Michael Buesch
2008-01-07 20:23 ` Alejandro Riveira Fernández
2008-01-08 15:30 ` Michael Buesch
2008-01-08 15:55 ` Alejandro Riveira Fernández
2008-01-24 20:27 ` Linus Torvalds
2008-01-24 21:07 ` John W. Linville
2008-01-24 21:34 ` Linus Torvalds
2008-01-25 12:29 ` Johannes Berg
2008-01-25 16:08 ` Linus Torvalds
2008-01-25 16:23 ` Michael Buesch
2008-01-25 16:43 ` Linus Torvalds
2008-01-25 17:27 ` Dan Williams
2008-01-25 17:38 ` Linus Torvalds
2008-01-25 17:42 ` Dan Williams
2008-02-05 20:55 ` Russell S. Senior
2008-01-25 18:22 ` Linus Torvalds
2008-01-25 18:30 ` Michael Buesch
2008-01-25 19:07 ` Linus Torvalds
2008-01-25 19:34 ` Michael Buesch
2008-01-25 19:48 ` John W. Linville
2008-01-25 19:50 ` John W. Linville
2008-01-25 21:18 ` John W. Linville
2008-01-25 21:56 ` Linus Torvalds
2008-01-25 22:46 ` John W. Linville
2008-01-25 23:20 ` Guy Cohen
2008-01-26 13:53 ` David Miller
2008-01-26 13:47 ` David Miller
2008-01-25 22:02 ` Guy Cohen
2008-01-26 13:40 ` David Miller
2008-01-25 20:28 ` Linus Torvalds
2008-01-26 13:37 ` David Miller
2008-01-27 6:32 ` Linus Torvalds
2008-01-27 7:16 ` Jeff Garzik
2008-01-27 7:24 ` David Miller
2008-01-27 7:54 ` Linus Torvalds
2008-01-28 3:15 ` David Miller
2008-01-25 23:22 ` Jeff Garzik
2008-01-26 13:27 ` David Miller
2008-01-27 6:25 ` Linus Torvalds
2008-01-26 13:22 ` David Miller
2008-01-25 18:21 ` Michael Buesch
2008-01-25 18:34 ` Linus Torvalds
2008-01-25 18:41 ` Michael Buesch
2008-01-25 21:11 ` Inaky Perez-Gonzalez
2008-01-25 21:21 ` Michael Buesch
2008-01-25 21:28 ` Inaky Perez-Gonzalez
2008-01-26 13:42 ` David Miller
2008-01-27 2:26 ` Luis R. Rodriguez
2008-01-29 19:07 ` Inaky Perez-Gonzalez
2008-01-25 21:46 ` John W. Linville
2008-01-25 22:15 ` Michael Buesch
2008-01-25 22:34 ` Tomas Winkler
2008-01-26 13:49 ` David Miller
2008-01-25 21:46 ` Guy Cohen
2008-01-25 21:54 ` Linus Torvalds
2008-01-26 13:46 ` David Miller
2008-01-25 18:34 ` John W. Linville
2008-01-24 22:17 ` Michael Buesch
2008-01-24 22:26 ` Linus Torvalds
2008-01-24 22:33 ` Michael Buesch
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).