* Linux 2.6.19-rc3
@ 2006-10-23 23:22 Linus Torvalds
2006-10-24 2:24 ` Gene Heskett
` (7 more replies)
0 siblings, 8 replies; 139+ messages in thread
From: Linus Torvalds @ 2006-10-23 23:22 UTC (permalink / raw)
To: Linux Kernel Mailing List
[-- Attachment #1: Type: TEXT/PLAIN, Size: 36476 bytes --]
Ok,
a few days late, because I'm a retard and didn't think of doing a release
when I should have.
I'm also a bit grumpy, because I think people are sending me more stuff
than they should at this stage in the game. We've been pretty good about
keeping the later -rc releases quiet, please keep it that way.
That said, it's mostly harmless cleanups and some architecture updates.
And some of the added warnings about unused return values have caused a
number of people to add error handling. And on the driver front, there's
mainly new driver ID's, and a couple of new drivers.
Shortlog appended,
Linus
----
Adrian Bunk (12):
RDMA/amso1100: Fix a NULL dereference in error path
drivers/char/specialix.c: fix the baud conversion
USB: ftdi-elan.c: remove dead code
USB: mos7840.c: fix a check-after-dereference
[GFS2] fs/gfs2/dir.c:gfs2_dir_write_data(): remove dead code
[GFS2] fs/gfs2/ops_fstype.c:gfs2_get_sb_meta(): remove unused variable
[GFS2] fs/gfs2/dir.c:gfs2_dir_write_data(): don't use an uninitialized variable
[GFS2] fs/gfs2/ops_fstype.c:fill_super_meta(): fix NULL dereference
[GFS2] gfs2_dir_read_data(): fix uninitialized variable usage
one more ARM IRQ fix
ATA must depend on BLOCK
drivers/ide/pci/generic.c: re-add the __setup("all-generic-ide",...)
Akinobu Mita (8):
[CRYPTO] api: fix crypto_alloc_base() return value
md: fix /proc/mdstat refcounting
rd: memory leak on rd_init() failure
epca: prevent panic on tty_register_driver() failure
usb devio: handle class_device_create() error
cpcihp_generic: prevent loading without "bridge" parameter
driver core: kmalloc() failure check in driver_probe_device
ocfs2: delete redundant memcmp()
Al Viro (31):
gfp_t in netlabel
new cifs endianness bugs
hp drivers/input stuff: C99 initializers, NULL noise removal, __user annotations
sun3_ioremap() prototype
serial167 __user annotations, NULL noise removal
[GFS2] gfs2 endianness bug: be16 assigned to be32 field
bug: nfsd/nfs4xdr.c misuse of ERR_PTR()
fix svc_procfunc declaration
lockd endianness annotations
xdr annotations: NFSv2
xdr annotations: NFSv3
xdr annotations: NFSv4
xdr annotations: NFS readdir entries
fs/nfs/callback* passes error values big-endian
xdr annotations: fs/nfs/callback*
nfs: verifier is network-endian
xdr annotations: mount_clnt
nfs_common endianness annotations
nfsd: nfserrno() endianness annotations
nfsfh simple endianness annotations
xdr annotations: nfsd_dispatch()
xdr annotations: NFSv2 server
xdr annotations: NFSv3 server
xdr annotations: NFSv4 server
nfsd: vfs.c endianness annotations
nfsd: nfs4 code returns error values in net-endian
nfsd: NFSv{2,3} trivial endianness annotations for error values
nfsd: NFSv4 errno endianness annotations
xdr annotations: nfsd callback*
nfsd: misc endianness annotations
nfsd: nfs_replay_me
Alan Cox (10):
rio: fix array checking
ide: add sanity checking to ide taskfile ioctl
[ARM] switch to new pci_get_bus_and_slot API
pci: Stamp out pci_find_* usage in fakephp
PCI: quirks: switch quirks code offender to use pci_get API
pci: Additional search functions
irq updates: make eata_pio compile
ahci: readability tweak
libata-sff: Allow for wacky systems
[ATM] nicstar: Fix a bogus casting warning
Alan Stern (6):
USB: unusual_devs entry for Nokia 6131
UHCI: workaround for Asus motherboard
usbcore: fix refcount bug in endpoint removal
usbcore: fix endpoint device creation
USB: unusual_devs entry for Nokia 6234
Driver core: Don't ignore error returns from probing
Alexey Dobriyan (6):
ACPI: asus_acpi: don't printk on writing garbage to proc files
sx: fix user-visible typo (devic)
USB: drivers/usb/net/*: use BUILD_BUG_ON
OOM killer meets userspace headers
kernel/nsproxy.c: use kmemdup()
i2o/exec-osm.c: use "unsigned long flags;"
Alexey Y. Starikovskiy (2):
ACPI: Remove deferred execution from global lock acquire wakeup path
ACPI: created a dedicated workqueue for notify() execution
Allan Stephens (12):
[TIPC]: Add missing unlock in port timeout code.
[TIPC]: Debug print buffer enhancements and fixes
[TIPC]: Stream socket can now send > 66000 bytes at a time
[TIPC]: Added duplicate node address detection capability
[TIPC]: Optimize wakeup logic when socket has no waiting processes
[TIPC]: Remove code bloat introduced by print buffer rework
[TIPC]: Add support for Ethernet VLANs
[TIPC]: Name publication events now delivered in chronological order
[TIPC]: Fixed slow link reactivation when link tolerance is large
[TIPC]: Can now list multicast link on an isolated network node
[TIPC]: Unrecognized configuration command now returns error message
[TIPC]: Updated TIPC version number to 1.6.2
Amit Choudhary (5):
V4L/DVB (4738): Bt8xx/dvb-bt8xx.c: check kmalloc() return value.
[ALSA] sound/isa/gus/interwave.c: check kmalloc() return value
[ALSA] sound/isa/cmi8330.c: check kmalloc() return value
[ALSA] sound/isa/ad1816a/ad1816a.c: check kmalloc() return value
[ALSA] sound/isa/opti9xx/opti92x-ad1848.c: check kmalloc() return value
Amol Lad (5):
[WATCHDOG] ioremap balanced with iounmap for drivers/char/watchdog/s3c2410_wdt.c
drivers/isdn/hysdn: save_flags()/cli(), restore_flags() replaced appropriately
drivers/isdn/isdnloop: save_flags()/cli(), restore_flags() replaced appropriately
PCI hotplug: ioremap balanced with iounmap
drivers/isdn: ioremap balanced with iounmap
Andi Kleen (8):
x86-64: Update defconfig
i386: Update defconfig
x86: Use -maccumulate-outgoing-args
x86-64: Revert interrupt backlink changes
i386: Disable nmi watchdog on all ThinkPads
x86: Revert new unwind kernel stack termination
x86-64: Revert timer routing behaviour back to 2.6.16 state
x86-64: Fix C3 timer test
Andrew Morton (14):
r8169: PCI ID for Corega Gigabit network card
Lockdep: fix compile error in drivers/input/serio/serio.c
invalidate: remove_mapping() fix
PROC_NUMBUF is wrong
remove carta_random32
vmalloc(): don't pass __GFP_ZERO to slab
acpi_processor_latency_notifier(): UP warning fix
swsusp: fix memory leaks
USB: fix usbatm tiny race
PCI: pcie-check-and-return-bus_register-errors fix
separate bdi congestion functions from queue congestion functions
highest_possible_node_id() linkage fix
i386: fix .cfi_signal_frame copy-n-paste error
pci: declare pci_get_device_reverse()
Andrew Victor (1):
[WATCHDOG] Atmel AT91RM9200 rename.
Andrey Mirkin (1):
scsi: megaraid_{mm,mbox}: 64-bit DMA capability fix
Andy Whitcroft (1):
Reintroduce NODES_SPAN_OTHER_NODES for powerpc
Aneesh Kumar K.V (1):
Add entry.S labels to tag file
Anton Blanchard (4):
[POWERPC] Never panic when taking altivec exceptions from userspace
[POWERPC] POWER6 has 6 PMCs
[POWERPC] Better check in show_instructions
[POWERPC] Check for offline nodes in pci NUMA code
Arnaud Patard (1):
r8169: fix infinite loop during hotplug
Arnaud Patard (Rtp) (1):
[WATCHDOG] add ich8 support to iTCO_wdt.c
Arnd Bergmann (3):
USB: driver for mcs7830 (aka DeLOCK) USB ethernet adapter
usbnet: improve generic ethtool support
usbnet: add a mutex around phy register access
Aron Griffis (1):
[IA64] move ioremap/ioremap_nocache under __KERNEL__
Arthur Kepner (1):
IB/mthca: Use mmiowb after doorbell ring
Atsushi Nemoto (1):
[MIPS] save_context_stack fix
Auke Kok (1):
e100: fix reboot -f with netconsole enabled
Ben Collins (13):
[SPARC]: Fix some section mismatch warnings in sparc drivers.
[alim7101] Add pci dev table for auto module loading.
[mv643xx] Add pci device table for auto module loading.
[BusLogic] Add pci dev table for auto module loading.
[fdomain] Add pci dev table for module auto loading.
[initio] Add pci dev table for module auto loading.
[ixj] Add pci dev table for module auto loading.
[hid-core] TurboX Keyboard needs NOGET quirk.
[controlfb] Ifdef for when CONFIG_NVRAM isn't enabled.
[igafb] Add pci dev table for module auto loading.
[platinumfb] Ifdef for when CONFIG_NVRAM isn't enabled.
[valkyriefb] Ifdef for when CONFIG_NVRAM isn't enabled.
[pci_ids] Add Quicknet XJ vendor/device ID's.
Benjamin Herrenschmidt (1):
[POWERPC] Don't crash on cell with 2 BEs when !CONFIG_NUMA
bibo,mao (1):
x86-64: x86_64 add NX mask for PTE entry
Bjorn Helgaas (3):
[IA64] remove unused PAL_CALL_IC_OFF
[IA64] reformat pal.S to fit in 80 columns, fix typos
[IA64] remove unused acpi_kbd_controller_present, acpi_legacy_devices
Björn Steinbrink (1):
[NETFILTER]: Missing check for CAP_NET_ADMIN in iptables compat layer
Borislav Petkov (1):
readjust comments of task_timeslice for kernel doc
Brent Casavant (2):
ioc4: Remove SN2 feature and config dependencies
ioc4: Enable build on non-SN2
Brice Goglin (2):
PCI: Improve pci_msi_supported() comments
PCI: Update MSI-HOWTO.txt according to pci_msi_supported()
Cedric Le Goater (1):
[S390] fix vmlinux link when CONFIG_SYSIPC=n
Chandra Seetharaman (1):
configfs: handle kzalloc() failure in check_perm()
Chris Malley (1):
USB: Support for BT On-Air USB modem in cdc-acm.c
Christoph Lameter (1):
Slab: Do not fallback to nodes that have not been bootstrapped yet
Chuck Lever (5):
NFS: fix minor bug in new NFS symlink code
NFS: __nfs_revalidate_inode() can use "inode" before checking it is non-NULL
NFS: remove unused check in nfs4_open_revalidate
SUNRPC: fix race in in-kernel RPC portmapper client
SUNRPC: fix a typo
Corey Minyard (1):
x86-64: Fix for arch/x86_64/pci/Makefile CFLAGS
Cornelia Huck (8):
[S390] cio: sch_no -> schid.sch_no conversion.
[S390] cio: update documentation.
driver core fixes: sysfs_create_link() retval check in class.c
driver core fixes: bus_add_attrs() retval check
driver core fixes: bus_add_device() cleanup on error
driver core fixes: device_add() cleanup on error
driver core fixes: device_create_file() retval check in dmapool.c
driver core fixes: sysfs_create_group() retval in topology.c
Craig Shelley (1):
USB-SERIAL:cp2101 Add new device ID
Daniel Drake (1):
PCI: VIA IRQ quirk behaviour change
Daniel Ritz (2):
usbtouchscreen: fix data reading for ITM touchscreens
PCI: add ICH7/8 ACPI/GPIO io resource quirks
Daniel Walker (1):
clocksource: acpi_pm: add another greylist chipset
Darren Jenkins (1):
ACPI: asus_acpi: fix proc files parsing
Darrick J. Wong (1):
fix "ACPI: Processor native C-states using MWAIT"
Dave Jones (2):
ipmi: fix return codes in failure case
Remove useless comment from sb1250
Dave Kleikamp (3):
JFS: pageno needs to be long
airo: check if need to freeze
null dereference in fs/jbd2/journal.c
David Brownell (2):
USB: ohci-pnx4008 build fixes
USB: ftdi_sio whitespace fixes
David Gibson (2):
ibmveth: Fix index increment calculation
ibmveth: Fix index increment calculation
David Howells (2):
FRV: Use the correct preemption primitives in kmap_atomic() and co
autofs3: Make sure all dentries refs are released before calling kill_anon_super()
David M. Grimes (1):
knfsd: add nfs-export support to tmpfs
David S. Miller (12):
[XFRM]: Fix xfrm_state_num going negative.
[SPARC]: Kill BOOTME_SINGLE.
[SPARC64]: Fix PCI memory space root resource on Hummingbird.
[SPARC] {bbc_,}envctrl: Use call_usermodehelper().
[SPARC64]: Update defconfig.
[TG3]: Bump driver version and release date.
[IPV6]: Fix route.c warnings when multiple tables are disabled.
[SPARC64]: Compute dma_end argument to sabre_pbm_init() correctly.
[SPARC64]: Fix of_ioremap().
[DCCP] ipv6: Fix opt_skb leak.
[PKT_SCHED] netem: Orphan SKB when adding to queue.
[SPARC64]: 8-byte align return value from compat_alloc_user_space()
David Woodhouse (2):
fix `make headers_install'
[SPARC]: Clean up asm-sparc/elf.h pollution in userspace.
Deepak Saxena (1):
Update smc91x driver with ARM Versatile board info
Denis M. Sadykov (5):
ACPI: EC: Remove unnecessary delay added by previous transation patch.
ACPI: EC: Remove unused variables and duplicated code
ACPI: EC: Unify poll and interrupt mode transaction functions
ACPI: EC: Unify poll and interrupt gpe handlers
ACPI: EC: Simplify acpi_hw_low_level*() with inb()/outb().
Diego Calleja (1):
HOWTO: bug report addition
Dmitriy Monakhov (1):
mm: D-cache aliasing issue in cow_user_page
Dmitry Torokhov (6):
Input: add missing exports to fix modular build
Input: i8042 - supress ACK/NAKs when blinking during panic
Input: atkbd - supress "too many keys" error message
Input: serio core - handle errors returned by device_bind_driver()
Input: gameport core - handle errors returned by device_bind_driver()
ACPI: fix potential OOPS in power driver with CONFIG_ACPI_DEBUG
Dominic Cerquetti (1):
USB: xpad: dance pad support
Dominik Brodowski (1):
Documentation: feature-removal-schedule typo
Doug Warzecha (1):
firmware/dcdbas: add size check in smi_data_write
Duncan Sands (4):
usbatm: fix tiny race
speedtch: "extended reach"
cxacru: add the ZTE ZXDSL 852
Driver core: plug device probe memory leak
Ed L Cashin (14):
aoe: eliminate isbusy message
aoe: update copyright date
aoe: remove unused NARGS enum
aoe: zero copy write 1 of 2
aoe: jumbo frame support 1 of 2
aoe: clean up printks via macros
aoe: jumbo frame support 2 of 2
aoe: improve retransmission heuristics
aoe: zero copy write 2 of 2
aoe: module parameter for device timeout
aoe: use bio->bi_idx
aoe: remove sysfs comment
aoe: update driver version
aoe: revert printk macros
Eiichiro Oiwa (1):
ACPICA: Fix incorrect handling of PCI Express Root Bridge _HID
eiichiro.oiwa.nm@hitachi.com (1):
PCI: Turn pci_fixup_video into generic for embedded VGA
Enrico Scholz (1):
V4L/DVB (4740): Fixed an if-block to avoid floating with debug-messages
Eric Dumazet (6):
[NET]: reduce sizeof(struct inet_peer), cleanup, change in peer_check_expire()
[NET]: reduce per cpu ram used for loopback stats
[TCP]: One NET_INC_STATS() could be NET_INC_STATS_BH in tcp_v4_err()
[IPV4] inet_peer: Group together avl_left, avl_right, v4daddr to speedup lookups on some CPUS
[NET]: Can use __get_cpu_var() instead of per_cpu() in loopback driver.
[NET]: Reduce sizeof(struct flowi) by 20 bytes.
Eric Sesterhenn (7):
[POWERPC] Off-by-one in /arch/ppc/platforms/mpc8*
zd1201: Possible NULL dereference
USB: BUG_ON conversion for wacom.c
USB: fix use after free in wacom_sys.c
USB: fix dereference in drivers/usb/misc/adutux.c
USB: Memory leak in drivers/usb/serial/airprime.c
pciehp: Remove unnecessary check in pciehp_ctrl.c
Eric W. Biederman (2):
x86-64: Use irq_domain in ioapic_retrigger_irq
x86-64: Put more than one cpu in TARGET_CPUS
Evgeniy Polyakov (1):
w1 kconfig fix
Felix Kuehling (1):
[ALSA] hda_intel: add ATI RS690 HDMI audio support
Florin Malita (1):
airo.c: check returned values
Francisco Larramendi (1):
rtc-max6902: month conversion fix
Franck Bui-Huu (1):
[MIPS] Use kallsyms_lookup_size_offset() instead of kallsyms_lookup()
Geert Uytterhoeven (1):
CONFIG_TELCLOCK depends on X86
Gerrit Renker (1):
[DCCP]: Fix Oops in DCCPv6
Grant Coady (1):
adm9240: Update Grant Coady's email address
Grant Grundler (1):
USB: input: extract() and implement() are bit field manipulation routines
Greg Banks (1):
kbuild: allow multi-word $M in Makefile.modpost
Greg Kroah-Hartman (7):
USB: revert EHCI VIA workaround patch
USB: ftdi-elan: fix sparse warnings
USB: move trancevibrator.c to the proper usb directory
USB: add USB serial mos7720 driver
USB: cleanup sierra wireless driver a bit
PCI Hotplug: move pci_hotplug.h to include/linux/
aoe: fix sysfs_create_file warnings
Hans Verkuil (3):
V4L/DVB (4729): Fix VIDIOC_G_FMT for NTSC in cx25840.
V4L/DVB (4744): The Samsung TCPN2121P30A does not have a tda9887
V4L/DVB (4746): HM12 is YUV 4:2:0, not YUV 4:1:1
Hartmut Hackmann (1):
V4L/DVB (4727): Support status readout for saa713x based FM radio
Heiko Carstens (1):
[S390] Wire up epoll_pwait syscall.
Henrik Kretzschmar (1):
RDMA/amso1100: pci_module_init() conversion
Herbert Xu (1):
[CRYPTO] api: Select cryptomgr where needed
Hidetoshi Seto (2):
sysfs: remove duplicated dput in sysfs_update_file
sysfs: update obsolete comment in sysfs_update_file
Ingo Molnar (3):
lockdep: increase max allowed recursion depth
genirq: clean up irq-flow-type naming
genirq: clean up irq-flow-type naming, fix
J. Bruce Fields (4):
knfsd: nfsd4: fix owner-override on open
knfsd: nfsd4: fix open permission checking
knfsd: nfsd4: Fix error handling in nfsd's callback client
nfs4: initialize cl_ipaddr
Jack Steiner (2):
[IA64] - Allow IPIs in timer loop
[IA64] Count resched interrupts
Jan Beulich (2):
x86-64: Speed up dwarf2 unwinder
x86-64: Fix ENOSYS in system call tracing
Jan Dittmer (1):
[IPV6] sit: Add missing MODULE_LICENSE
Jan Kara (1):
Fix IO error reporting on fsync()
Jan Luebbe (1):
USB: Add device id for Sierra Wireless MC8755
Jan Mate (1):
USB Storage: unusual_devs.h entry for Sony Ericsson P990i
Jarek Poplawski (1):
USB: fix cdc-acm problems with hard irq? (inconsistent lock state)
Jaroslav Kysela (1):
[ALSA] version 1.0.13
Jean Delvare (5):
[WATCHDOG] includes for sample watchdog program.
hwmon: Fix documentation typos
smsc47m1: List the SMSC LPC47M112 as supported
hwmon: Let w83781d and lm78 load again
hwmon: Fix debug messages in w83781d
Jean Tourrilhes (2):
orinoco: fix WE-21 buffer overflow
wireless: More WE-21 potential overflows...
Jeff Dike (1):
uml: MODE_TT is bust
Jeff Garzik (15):
[WATCHDOG] watchdog/iTCO_wdt: fix bug related to gcc uninit warning
Input: fm801-gp - handle errors from pci_enable_device()
V4L/DVB (4741): {ov511,stv680}: handle sysfs errors
V4L/DVB (4742): Drivers/media/video: handle sysfs errors
drivers/led: handle sysfs errors
I2O: handle a few sysfs errors
fs/partitions/check: add sysfs error handling
rtc: fix printk of 64-bit res on 32-bit platform
ISDN: fix drivers, by handling errors thrown by ->readstat()
ISDN: check for userspace copy faults
USB/gadget/net2280: handle sysfs errors
Driver core: bus: remove indentation level
WAN/pc300: handle, propagate minor errors
[ATM]: handle sysfs errors
[ATM] firestream: handle thrown error
Jeff Moyer (1):
direct-io: sync and invalidate file region when falling back to buffered write
Jens Axboe (2):
Add lockless helpers for remove_suid()
Remove SUID when splicing into an inode
Jeremy Fitzhardinge (1):
i386: Fix fake return address
Jes Sorensen (1):
[IA64] update sn2_defconfig
Jesper Juhl (1):
Driver core: Don't leak 'old_class_name' in drivers/base/core.c::device_rename()
Jim Cromie (1):
w83791d: Fix unchecked return status
Jiri Kosina (3):
Input: serio - add lockdep annotations
ACPI: acpi_pci_link_set() can allocate with either GFP_ATOMIC or GFP_KERNEL
ACPI: check battery status on resume for un/plug events during sleep
Jiri Slaby (1):
Char: correct pci_get_device changes
John Heffner (1):
[TCP]: Bound TSO defer time
john stultz (1):
i386 Time: Avoid PIT SMP lockups
John W. Linville (2):
zd1211rw: fix build-break caused by association race fix
wireless: WE-20 compatibility for ESSID and NICKN ioctls
Jonathan Corbet (1):
V4L/DVB (4743): Fix oops in VIDIOC_G_PARM
keith mannthey (1):
x86-64: x86_64 hot-add memory srat.c fix
Kenji Kaneshige (5):
shpchp: fix shpchp_wait_cmd in poll
pciehp: fix improper info messages
pciehp - add missing locking
shpchp: fix command completion check
shpchp: remove unnecessary cmd_busy member from struct controller
Kevin Lloyd (1):
USB: Sierra Wireless driver update
Kimball Murray (1):
ACPI: SCI interrupt source override
Kristen Carlson Accardi (2):
change pci hotplug subsystem maintainer to Kristen
libata: use correct map_db values for ICH8
Kristoffer Ericson (2):
[ARM] 3889/1: [Jornada7xx] Addition of correct SDRAM params into cpu-sa1110.c
[ARM] 3890/1: [Jornada7xx] Addition of MCU commands into jornada720.h
Krzysztof Helt (1):
[SPARC]: Sparc compilation fix with floppy enabled
Kumar Gala (1):
[POWERPC] ppc: Add missing calls to set_irq_regs
Larry Finger (2):
bcm43xx-softmac: check returned value from pci_enable_device
bcm43xx-softmac: Fix system hang for x86-64 with >1GB RAM
Laurent Riffard (1):
sotftmac: fix a slab corruption in WEP restricted key association
Lebedev, Vladimir P (2):
ACPI: sbs: check for NULL device pointer
ACPI: sbs: fix module_param() initializers
Len Brown (1):
ACPI: update comments in motherboard.c
Lennart Poettering (3):
ACPI: consolidate functions in acpi ec driver
ACPI: EC: export ec_transaction() for msi-laptop driver
MSI S270 Laptop support: backlight, wlan, bluetooth states
Li Yang (3):
[POWERPC] Fix MPC8360EMDS PB board support
[POWERPC] Add Makefile entry for MPC832x_mds support
ucc_geth: changes to ucc_geth driver as a result of qe_lib changes and bugfixes
Liam Girdwood (1):
[ARM] 3888/1: add pxa27x SSP FSRT register bit definition
Lijun Chen (1):
[TIPC]: Added subscription cancellation capability
Linas Vepstas (1):
e1000: Reset all functions after a PCI error
Linus Torvalds (5):
Fix VM_MAYEXEC calculation
Fix USB gadget net2280.c compile
Revert "[mv643xx] Add pci device table for auto module loading."
Revert unintentional and bogus change to drivers/pci/quirks.c
Linux 2.6.19-rc3
Luiz Fernando N. Capitulino (1):
airprime: New device ID.
Marcel Holtmann (12):
[Bluetooth] Fix compat ioctl for BNEP, CMTP and HIDP
[Bluetooth] Handle return values from driver core functions
[Bluetooth] Make use of virtual devices tree
[Bluetooth] Support concurrent connect requests
[Bluetooth] Disconnect HID interrupt channel first
[Bluetooth] Fix reference count when connection lookup fails
[Bluetooth] Check if DLC is still attached to the TTY
[Bluetooth] Add locking for bt_proto array manipulation
[Bluetooth] Use work queue to trigger URB submission
[Bluetooth] Add support for newer ANYCOM USB dongles
[Bluetooth] Add missing entry for Nokia DTL-4 PCMCIA card
[Bluetooth] Fix HID disconnect NULL pointer dereference
Marcus Junker (1):
[WATCHDOG] w83697hf WDT driver
Marek W (1):
ACPI: asus_acpi: W3000 support
Mark Fasheh (4):
Take i_mutex in splice_from_pipe()
Introduce generic_file_splice_write_nolock()
ocfs2: fix page zeroing during simple extends
ocfs2: cond_resched() in ocfs2_zero_extend()
Martin Habets (1):
[SPARC]: Add sparc profiling support
Martin Schwidefsky (2):
[S390] Fix pte type checking.
[S390] update default configuration
Matt Domsch (1):
PCI: optionally sort device lists breadth-first
Matthew Wilcox (3):
V4L/DVB (4725): Fix vivi compile on parisc
Fix dev_printk() is now GPL-only
cciss: Fix warnings (and bug on 1TB discs)
matthieu castet (4):
UEAGLE : be suspend friendly
UEAGLE : use interruptible sleep
UEAGLE : comestic changes
UEAGLE: fix ueagle-atm Oops
Melissa Howland (1):
[S390] monwriter find header logic.
Michael Buesch (2):
bcm43xx: fix race condition in periodic work handler
softmac: Fix WX and association related races
Michael Chan (1):
[TG3]: Add lower bound checks for tx ring size.
Michael Krufky (3):
V4L/DVB (4731a): Kconfig: restore pvrusb2 menu items
V4L/DVB (4733): Tda10086: fix frontend selection for dvb_attach
V4L/DVB (4734): Tda826x: fix frontend selection for dvb_attach
Michel Dänzer (1):
[AGPGART] uninorth: Add module param 'aperture' for aperture size
Miklos Szeredi (6):
fuse: fix hang on SMP
document i_size_write locking rules
fuse: locking fix for nlookup
fuse: fix spurious BUG
fuse: fix handling of moved directory
fuse: fix dereferencing dentry parent
Muli Ben-Yehuda (1):
x86-64: increase PHB1 split transaction timeout
Neil Brown (1):
Convert cpu hotplug notifiers to use raw_notifier instead of blocking_notifier
NeilBrown (7):
knfsd: Fix bug in recent lockd patches that can cause reclaim to fail
knfsd: Allow lockd to drop replies as appropriate
knfsd: fix race that can disable NFS server
md: fix calculation of ->degraded for multipath and raid10
md: add another COMPAT_IOCTL for md
md: endian annotation for v1 superblock access
md: endian annotations for the bitmap superblock
Nick Piggin (1):
mm: more commenting on lock ordering
Nicolas Pitre (1):
fix PXA2xx UDC compilation error
Noguchi, Masato (1):
[POWERPC] spufs: fix support for read/write on cntl
OGAWA Hirofumi (1):
ext3/4: fix J_ASSERT(transaction->t_updates > 0) in journal_stop()
Olaf Hering (1):
Fix up rpaphp driver for pci hotplug header move
Oliver Neukum (3):
USB: remove private debug macros from kaweth
USB: suspend/resume support for kaweth
USB: fix suspend support for usblp
Pablo Neira Ayuso (1):
[NETFILTER]: ctnetlink: Remove debugging messages
Paolo 'Blaisorblade' Giarrusso (9):
fix typo in memory barrier docs
uml: remove some leftover PPC code
uml: split memory allocation prototypes out of user.h
uml: code convention cleanup of a file
uml: reenable compilation of enable_timer, disabled by mistake
uml: use DEFCONFIG_LIST to avoid reading host's config
uml: cleanup run_helper() API to fix a leak
uml: kconfig - silence warning
uml: mmapper - remove just added but wrong "const" attribute
Patrick Boettcher (2):
V4L/DVB (4748): Fixed oops for Nova-T USB2
V4L/DVB (4750): AGC command1/2 is board specific
Patrick Caulfield (1):
[DLM] fix iovec length in recvmsg
Patrick McHardy (6):
[DECNET]: Use correct config option for routing by fwmark in compare_keys()
[NETFILTER]: fix cut-and-paste error in exit functions
[NETFILTER]: arp_tables: missing unregistration on module unload
[NETFILTER]: ipt_ECN/ipt_TOS: fix incorrect checksum update
[NETFILTER]: xt_CONNSECMARK: fix Kconfig dependencies
[NETFILTER]: Update MAINTAINERS entry
Paul Fulghum (1):
synclink: remove PAGE_SIZE reference
Paul Jackson (1):
cpuset: mempolicy migration typo fix
Paul Moore (3):
NetLabel: only deref the CIPSOv4 standard map fields when using standard mapping
NetLabel: better error handling involving mls_export_cat()
NetLabel: the CIPSOv4 passthrough mapping does not pass categories correctly
Paul Mundt (7):
sh: Proper show_stack/show_trace() implementation.
sh: Remove board-specific ide.h headers.
sh: Cleanup board header directories.
sh: Fix exception_handling_table alignment.
sh: Add some missing board headers.
sh: Updates for irq-flow-type naming changes.
sh: Convert INTC2 to IRQ table registration.
Pavel Machek (1):
ACPI: ibm_acpi: delete obsolete documentation
Pekka Enberg (1):
ecryptfs: use special_file()
Peter Oberparleiter (1):
[S390] cio: invalid device operational notification
Peter Zijlstra (3):
Lockdep: add lockdep_set_class_and_subclass() and lockdep_set_subclass()
lockdep: annotate i386 apm
rt-mutex: fixup rt-mutex debug code
Petr Vandrovec (1):
Fix core files so they make sense to gdb...
Pierre Ossman (2):
ACPI: fix section for CPU init functions
New MMC maintainer
Ping Cheng (1):
USB: Wacom driver updates
Pádraig Brady (1):
V4L/DVB (4739): SECAM support for saa7113 into saa7115
Ralf Baechle (11):
[MIPS] Delete unneeded pt_regs forward declaration.
[MIPS] Malta: Fix uninitialized regs pointer.
[MIPS] A few more pt_regs fixups.
[MIPS] Use compat_sys_mount.
[MIPS] Reserve syscall numbers for kexec_load.
[MIPS] Fix iounmap argument to const volatile.
Make <linux/personality.h> userspace proof
Fix warnings for WARN_ON if CONFIG_BUG is disabled
Fix timer race
[MIPS] Cleanup remaining references to mips_counter_frequency.
[MIPS] Fix aliasing bug in copy_to_user_page / copy_from_user_page
Randy Dunlap (6):
ACPI: fix printk format warnings
fix epoll_pwait when EPOLL=n
Kconfig serial typos
cad_pid sysctl with PROC_FS=n
fs/Kconfig: move GENERIC_ACL, fix acl() call errors
[NET]: kernel-doc fix for sock.h
Randy Vinson (1):
[POWERPC] Fix IO Window Updates on P2P bridges.
Ranjit Manomohan (1):
[TG3]: Fix set ring params tx ring size implementation
Robert Walsh (1):
IB/ipath: Initialize diagpkt file on device init only
Rudolf Marek (2):
k8temp: Documentation update
w83627ehf: Fix the detection of fan5
Russell King (4):
[ARM] Fix fallout from IRQ regs changes
[ARM] Fix Zaurii keyboard/touchscreen drivers
[ARM] Update mach-types
Remove __must_check for device_for_each_child()
Samuel Tardieu (17):
[WATCHDOG] w83697hf/hg WDT driver - patch 1
[WATCHDOG] w83697hf/hg WDT driver - patch 2
[WATCHDOG] w83697hf/hg WDT driver - patch 3
[WATCHDOG] w83697hf/hg WDT driver - patch 4
[WATCHDOG] w83697hf/hg WDT driver - patch 5
[WATCHDOG] w83697hf/hg WDT driver - patch 6
[WATCHDOG] w83697hf/hg WDT driver - patch 7
[WATCHDOG] w83697hf/hg WDT driver - patch 8
[WATCHDOG] w83697hf/hg WDT driver - patch 9
[WATCHDOG] w83697hf/hg WDT driver - patch 10
[WATCHDOG] w83697hf/hg WDT driver - patch 11
[WATCHDOG] w83697hf/hg WDT driver - patch 12
[WATCHDOG] w83697hf/hg WDT driver - patch 13
[WATCHDOG] w83697hf/hg WDT driver - patch 14
[WATCHDOG] w83697hf/hg WDT driver - patch 15
[WATCHDOG] w83697hf/hg WDT driver - patch 16
[WATCHDOG] w83697hf/hg WDT driver - Kconfig patch
Satoru Takeuchi (1):
doc: fixing cpu-hotplug documentation
Stefan Schmidt (3):
ACPI: ibm_acpi: Remove experimental status for brightness and volume.
ACPI: ibm_acpi: Update documentation for brightness and volume.
ACPI: ibm_acpi: Documentation the wan feature.
Stefan Weinhuber (1):
[S390] dasd: clean up timer.
Stephen Hemminger (16):
[BRIDGE]: flush forwarding table when device carrier off
rename net_random to random32
sky2: MSI test is only a warning
sky2: turn of workaround timer
sky2: phy irq on shutdown
sky2: fiber pause bits
sky2: advertising register 16 bits
sky2: use duplex result bits
sky2: don't reset PHY twice
sky2: flow control setting fixes
sky2: no message on rx fifo overflow
sky2: version 1.9
sky2: accept multicast pause frames
sky2: GMAC pause frame
[NETPOLL]: initialize skb for UDP
sky2: 88E803X transmit lockup
Steven Toth (1):
V4L/DVB (4692): Add WinTV-HVR3000 DVB-T support
Steven Whitehouse (2):
[DECNET]: Fix input routing bug
[GFS2] Fix bmap to map extents properly
Sunil Mushran (1):
ocfs2: remove spurious d_count check in ocfs2_rename()
Sven Anders (1):
[WATCHDOG] Winbond SMsC37B787 watchdog driver
Takashi Iwai (8):
[ALSA] hda-codec - Fix assignment of PCM devices for Realtek codecs
[ALSA] Various fixes for suspend/resume of ALSA PCI drivers
[ALSA] Fix dependency of snd-adlib driver in Kconfig
[ALSA] hda-codec - Add model entry for ASUS U5F laptop
[ALSA] Fix re-use of va_list
[ALSA] Fix AC97 power-saving mode
[ALSA] Fix addition of user-defined boolean controls
[ALSA] hda-intel - Add check of MSI availabity
Tejun Heo (1):
libata: typo fix
Thiemo Seufer (1):
[MIPS] Fix O32 personality(2) call with 0xffffffff argument.
Thomas Gleixner (1):
posix-cpu-timers: prevent signal delivery starvation
Thomas Graf (4):
[IPv6] rules: Use RT6_LOOKUP_F_HAS_SADDR and fix source based selectors
[IPv4] fib: Remove unused fib_config members
[IPv6] route: Fix prohibit and blackhole routing decision
[IPv6] fib: initialize tb6_lock in common place to give lockdep a key
Thomas Maier (1):
export clear_queue_congested and set_queue_congested
Timur Tabi (1):
[POWERPC] Add DOS partition table support to mpc834x_itx_defconfig
Tobias Klauser (1):
[ATM]: No need to return void
Tobias Lorenz (1):
USB: Mitsumi USB FDD 061M: UNUSUAL_DEV multilun fix
Tony Luck (1):
[IA64] perfmon fix for global IRQ fix
Trond Myklebust (7):
NFSv4: Fix thinko in fs/nfs/super.c
NFS: Fix oops in nfs_cancel_commit_list
NFS: Fix error handling in nfs_direct_write_result()
NFS: Fix NFSv4 callback regression
NFS: Deal with failure of invalidate_inode_pages2()
VFS: Make d_materialise_unique() enforce directory uniqueness
NFS: Cache invalidation fixup
Ulrich Drepper (1):
make UML compile (FC6/x86-64)
Uwe Bugla (1):
V4L/DVB (4732): Fix spelling error in Kconfig help text for DVB_CORE_ATTACH
Venkatesh Pallipadi (1):
ACPI: Processor native C-states using MWAIT
Ville Nuorvala (6):
[IPV6]: Remove struct pol_chain.
[SCTP]: Fix minor typo
[IPV6]: Make sure error handling is done when calling ip6_route_output().
[IPV6]: Clean up BACKTRACK().
[IPV6]: Make IPV6_SUBTREES depend on IPV6_MULTIPLE_TABLES.
[IPV6]: Always copy rt->u.dst.error when copying a rt6_info.
Vivek Goyal (2):
x86-64: fix page align in e820 allocator
x86-64: Overlapping program headers in physical addr space fix
Vojtech Pavlik (1):
Fix DMA resource allocation in ACPIPnP
Wim Van Sebroeck (9):
[WATCHDOG] Winbond SMsC37B787 - remove trailing whitespace
[WATCHDOG] Winbond SMsC37B787 watchdog fixes
[WATCHDOG] Kconfig clean-up
[WATCHDOG] w836?7hf_wdt spinlock fixes.
[WATCHDOG] Kconfig clean up
[WATCHDOG] use ENOTTY instead of ENOIOCTLCMD in ioctl()
[WATCHDOG] w83697hf/hg WDT driver - autodetect patch
[WATCHDOG] add ich8 support to iTCO_wdt.c (patch 2)
[WATCHDOG] remove experimental on iTCO_wdt.c
Yasunori Goto (2):
Change log level of a message of acpi_memhotplug to KERN_DEBUG
acpi memory hotplug: remove strange add_memory fail message
Yinghai Lu (1):
x86-64: typo in __assign_irq_vector when updating pos for vector and offset
Yoichi Yuasa (4):
[MIPS] More vr41xx pt_regs fixups
[MIPS] Update pnx8500-jbs_defconfig
[MIPS] Update pnx8550-v2pci_defconfig
[MIPS] Update tb0287_defconfig
YOSHIFUJI Hideaki (1):
[IPV6]: Remove bogus WARN_ON in Proxy-NA handling.
Zachary Amsden (1):
Fix potential interrupts during alternative patching
Zhang, Yanmin (1):
PCI: fix pcie_portdrv_restore_config undefined without CONFIG_PM error
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Linux 2.6.19-rc3
2006-10-23 23:22 Linux 2.6.19-rc3 Linus Torvalds
@ 2006-10-24 2:24 ` Gene Heskett
2006-10-24 7:46 ` Muli Ben-Yehuda
` (6 subsequent siblings)
7 siblings, 0 replies; 139+ messages in thread
From: Gene Heskett @ 2006-10-24 2:24 UTC (permalink / raw)
To: linux-kernel; +Cc: Linus Torvalds
On Monday 23 October 2006 19:22, Linus Torvalds wrote:
>Ok,
> a few days late, because I'm a retard and didn't think of doing a
> release when I should have.
A couple of things noted in a dmesg report after booting it.
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
-----
warning: process `date' used the removed sysctl system call
-----
warning: process `date' used the removed sysctl system call
-----
warning: process `quotaon' used the removed sysctl system call
------
warning: process `kudzu' used the removed sysctl system call
ieee1394: Host added: ID:BUS[0-00:1023] GUID[00d0035600a886d8]
warning: process `kudzu' used the removed sysctl system call
The system seems to be ok so far.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Linux 2.6.19-rc3
2006-10-23 23:22 Linux 2.6.19-rc3 Linus Torvalds
2006-10-24 2:24 ` Gene Heskett
@ 2006-10-24 7:46 ` Muli Ben-Yehuda
2006-10-24 18:07 ` Badari Pulavarty
2006-10-24 20:21 ` 2.6.19-rc3: known unfixed regressions Adrian Bunk
` (5 subsequent siblings)
7 siblings, 1 reply; 139+ messages in thread
From: Muli Ben-Yehuda @ 2006-10-24 7:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List, Eric W. Biederman, Andi Kleen
On Mon, Oct 23, 2006 at 04:22:59PM -0700, Linus Torvalds wrote:
>
> Ok,
> a few days late, because I'm a retard and didn't think of doing a release
> when I should have.
>
> I'm also a bit grumpy, because I think people are sending me more stuff
> than they should at this stage in the game. We've been pretty good about
> keeping the later -rc releases quiet, please keep it that way.
>
> That said, it's mostly harmless cleanups and some architecture updates.
> And some of the added warnings about unused return values have caused a
> number of people to add error handling. And on the driver front, there's
> mainly new driver ID's, and a couple of new drivers.
The genirq changes broke boot on my x86-64 x366 machine. It needs
these two patches:
http://marc.theaimsgroup.com/?l=linux-kernel&m=116157813623508&w=2
http://marc.theaimsgroup.com/?l=linux-kernel&m=116157837104613&w=2
It also broke tg3 on at least one other machine, so this is not
specific to my machine.
Cheers,
Muli
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Linux 2.6.19-rc3
2006-10-24 7:46 ` Muli Ben-Yehuda
@ 2006-10-24 18:07 ` Badari Pulavarty
0 siblings, 0 replies; 139+ messages in thread
From: Badari Pulavarty @ 2006-10-24 18:07 UTC (permalink / raw)
To: Muli Ben-Yehuda
Cc: Linus Torvalds, Linux Kernel Mailing List, Eric W. Biederman,
Andi Kleen
On Tue, 2006-10-24 at 09:46 +0200, Muli Ben-Yehuda wrote:
> On Mon, Oct 23, 2006 at 04:22:59PM -0700, Linus Torvalds wrote:
> >
> > Ok,
> > a few days late, because I'm a retard and didn't think of doing a release
> > when I should have.
> >
> > I'm also a bit grumpy, because I think people are sending me more stuff
> > than they should at this stage in the game. We've been pretty good about
> > keeping the later -rc releases quiet, please keep it that way.
> >
> > That said, it's mostly harmless cleanups and some architecture updates.
> > And some of the added warnings about unused return values have caused a
> > number of people to add error handling. And on the driver front, there's
> > mainly new driver ID's, and a couple of new drivers.
>
> The genirq changes broke boot on my x86-64 x366 machine. It needs
> these two patches:
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=116157813623508&w=2
> http://marc.theaimsgroup.com/?l=linux-kernel&m=116157837104613&w=2
Yes. Without these patches, I can't seem to get my qlogic driver
to work :(
Thanks,
Badari
ACPI: PCI Interrupt 0000:01:05.0[A] -> GSI 17 (level, low) -> IRQ 17
qla2xxx 0000:01:05.0: Found an ISP2200, irq 17, iobase
0xffffc20000064000
qla2xxx 0000:01:05.0: Configuring PCI space...
qla2xxx 0000:01:05.0: Configure NVRAM parameters...
qla2xxx 0000:01:05.0: Verifying loaded RISC code...
qla2xxx 0000:01:05.0: Allocated (252 KB) for firmware dump...
qla2xxx 0000:01:05.0: LIP reset occured (f723).
qla2xxx 0000:01:05.0: Waiting for LIP to complete...
qla2xxx 0000:01:05.0: LIP occured (f723).
qla2xxx 0000:01:05.0: LOOP UP detected (1 Gbps).
qla2xxx 0000:01:05.0: Topology - (Loop), Host Loop address 0x7d
qla2xxx 0000:01:05.0: Failed to reserve interrupt 17 already in use.
qla2xxx: probe of 0000:01:05.0 failed with error -38
ACPI: PCI Interrupt 0000:0f:01.0[A] -> GSI 29 (level, low) -> IRQ 29
qla2xxx 0000:0f:01.0: Found an ISP2312, irq 29, iobase
0xffffc20000064000
qla2xxx 0000:0f:01.0: Configuring PCI space...
qla2xxx 0000:0f:01.0: Configure NVRAM parameters...
qla2xxx 0000:0f:01.0: Verifying loaded RISC code...
qla2xxx 0000:0f:01.0: Allocated (412 KB) for firmware dump...
qla2xxx 0000:0f:01.0: Waiting for LIP to complete...
qla2xxx 0000:0f:01.0: Cable is unplugged...
qla2xxx 0000:0f:01.0: Failed to reserve interrupt 29 already in use.
qla2xxx: probe of 0000:0f:01.0 failed with error -38
ACPI: PCI Interrupt 0000:19:01.0[A] -> GSI 37 (level, low) -> IRQ 37
qla2xxx 0000:19:01.0: Found an ISP2200, irq 37, iobase
0xffffc20000064000
qla2xxx 0000:19:01.0: Configuring PCI space...
qla2xxx 0000:19:01.0: Configure NVRAM parameters...
qla2xxx 0000:19:01.0: Verifying loaded RISC code...
qla2xxx 0000:19:01.0: Allocated (252 KB) for firmware dump...
qla2xxx 0000:19:01.0: LIP reset occured (f725).
qla2xxx 0000:19:01.0: Waiting for LIP to complete...
qla2xxx 0000:19:01.0: LIP occured (f725).
qla2xxx 0000:19:01.0: LOOP UP detected (1 Gbps).
qla2xxx 0000:19:01.0: Topology - (Loop), Host Loop address 0x8
qla2xxx 0000:19:01.0: Failed to reserve interrupt 37 already in use.
qla2xxx: probe of 0000:19:01.0 failed with error -38
^ permalink raw reply [flat|nested] 139+ messages in thread
* 2.6.19-rc3: known unfixed regressions
2006-10-23 23:22 Linux 2.6.19-rc3 Linus Torvalds
2006-10-24 2:24 ` Gene Heskett
2006-10-24 7:46 ` Muli Ben-Yehuda
@ 2006-10-24 20:21 ` Adrian Bunk
2006-10-24 21:44 ` 2.6.19-rc3: known unfixed regressions: confirmations teunis
2006-10-25 1:51 ` 2.6.19-rc3: known regressions with patches Adrian Bunk
` (4 subsequent siblings)
7 siblings, 1 reply; 139+ messages in thread
From: Adrian Bunk @ 2006-10-24 20:21 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: Linux Kernel Mailing List, art, teunis, Jiri Slaby, pavel,
linux-pm, ak, Martin Lorenz, len.brown, linux-acpi,
Michael S. Tsirkin, Thierry Vignaud, jgarzik, linux-ide,
Alex Romosan, Jens Axboe, Komuro, Thomas Gleixner,
Benjamin Herrenschmidt, Stefan Richter, linux1394-devel,
Christian, Mark Langsdorf, davej, cpufreq, Stephen Hemminger,
Greg KH, linux-pci
This email lists some known unfixed regressions in 2.6.19-rc3 compared
to 2.6.18.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.
Due to the huge amount of recipients, please trim the Cc when answering.
Subject : shutdown problem
References : http://lkml.org/lkml/2006/10/22/140
Submitter : art@usfltd.com
teunis@wintersgift.com
Jiri Slaby <jirislaby@gmail.com>
Status : unknown
Subject : X60s: BUG()s, lose ACPI events after suspend/resume
References : http://lkml.org/lkml/2006/10/10/39
Submitter : Martin Lorenz <martin@lorenz.eu.org>
Status : unknown
Subject : T60 stops triggering any ACPI events
References : http://lkml.org/lkml/2006/10/4/425
http://lkml.org/lkml/2006/10/16/262
http://bugzilla.kernel.org/show_bug.cgi?id=7408
Submitter : "Michael S. Tsirkin" <mst@mellanox.co.il>
Status : unknown
Subject : sata-via doesn't detect anymore disks attached to VIA vt6421
References : http://bugzilla.kernel.org/show_bug.cgi?id=7255
Submitter : Thierry Vignaud <tvignaud@mandriva.com>
Status : unknown
Subject : unable to rip cd
References : http://lkml.org/lkml/2006/10/13/100
Submitter : Alex Romosan <romosan@sycorax.lbl.gov>
Status : unknown
Subject : SMP kernel can not generate ISA irq properly
References : http://lkml.org/lkml/2006/10/22/15
Submitter : Komuro <komurojun-mbn@nifty.com>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Status : Thomas will investigate
Subject : ohci1394 on PPC_PMAC:
pci_set_power_state() failure and breaking suspend
References : http://lkml.org/lkml/2006/10/24/13
Submitter : Benjamin Herrenschmidt <benh@kernel.crashing.org>
Caused-By : Stefan Richter <stefanr@s5r6.in-berlin.de>
commit ea6104c22468239083857fa07425c312b1ecb424
Handled-By : Stefan Richter <stefanr@s5r6.in-berlin.de>
Status : Stefan Richter: looking for an answer when to ignore
the return code of pci_set_power_state
Subject : cpufreq not working on AMD K8
References : http://lkml.org/lkml/2006/10/10/114
Submitter : Christian <christiand59@web.de>
Handled-By : Mark Langsdorf <mark.langsdorf@amd.com>
Status : Mark is investigating
Subject : MSI errors during boot (CONFIG_PCI_MULTITHREAD_PROBE)
References : http://lkml.org/lkml/2006/10/16/291
Submitter : Stephen Hemminger <shemminger@osdl.org>
Handled-By : Greg KH <greg@kroah.com>
Status : Greg is working on a fix
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions: confirmations
2006-10-24 20:21 ` 2.6.19-rc3: known unfixed regressions Adrian Bunk
@ 2006-10-24 21:44 ` teunis
2006-10-26 15:31 ` Adrian Bunk
0 siblings, 1 reply; 139+ messages in thread
From: teunis @ 2006-10-24 21:44 UTC (permalink / raw)
To: Adrian Bunk, linux-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Adrian Bunk wrote:
> This email lists some known unfixed regressions in 2.6.19-rc3 compared
> to 2.6.18.
...
I'm not directly testing -rc3 as yet... rc2-mm2 + a few modifications
works on the equipment I'm testing and as I can't afford more lost time
due to faults - I'm keeping to that build for the short term.
> Subject : shutdown problem
> References : http://lkml.org/lkml/2006/10/22/140
> Submitter : art@usfltd.com
> teunis@wintersgift.com
> Jiri Slaby <jirislaby@gmail.com>
> Status : unknown
repaired by Jeff Dike's patch to fs/proc/array.c
VFAT failure: inode.c patch worked. Has this been fixed in -rc3?
(email I've reviewed implies no)
HP nx6110 and nx6310 (i945G chipsets) - ACPI S3 and S4 (is that right?)
now fully operational. speedstep not yet operational on nx6310 (Yonah).
synaptic driver: does not recover in S3 mode on nx7400 () or Acer
TravelMate 8000 (Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
USB UHCI)
Suspect USB host problem as synaptic driver DOES recover on nx6130.
This IS a regression as these worked fine in kernels where S3 formerly
worked. Video does not yet fully recover on nx7400 - but it never has
so that's not a regression (backlight fails to recover).
Any idea when Yonah (family 6/model 14/stepping 8) will be supported by
either speedstep, P4 or ACPI driver? NONE of these work. P4 did work
briefly (-rc1-git4 and -rc1-git6) but I'm not sure that it's optimal.
acpi-cpufreq hasn't loaded since 2.6.18 (which didn't work properly
with other parts of the laptops so went with 2.6.19 rc series).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFPokhbFT/SAfwLKMRAgFrAKCS/3jAVs12uk2LWhAcN/vFZe7nvACfeLr2
EJOWO0HZ4hVk3UXZoxe4BbQ=
=wO+m
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 139+ messages in thread
* 2.6.19-rc3: known regressions with patches
2006-10-23 23:22 Linux 2.6.19-rc3 Linus Torvalds
` (2 preceding siblings ...)
2006-10-24 20:21 ` 2.6.19-rc3: known unfixed regressions Adrian Bunk
@ 2006-10-25 1:51 ` Adrian Bunk
2006-10-25 11:25 ` Linux 2.6.19-rc3 Jean Delvare
` (3 subsequent siblings)
7 siblings, 0 replies; 139+ messages in thread
From: Adrian Bunk @ 2006-10-25 1:51 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: Linux Kernel Mailing List, Muli Ben-Yehuda, Gleb Natapov,
Yinghai Lu, Eric W. Biederman, Alistair John Strachan,
Patrick McHardy, herbert, linux-crypto, Paul Mundt,
Heiko Carstens, linux-390, David Miller, Eiichiro Oiwa, gregkh,
linux-pci, Jesper Juhl, David Howells, Andrey Panin,
linux-visws-devel, Andrew de Quincey, Trent Piepho,
v4l-dvb-maintainer
This email lists some known regressions in 2.6.19-rc3 compared
to 2.6.18 with patches available.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.
Due to the huge amount of recipients, please trim the Cc when answering.
Subject : "ACPI: PCI interrupt for device ... disabled"
References : http://lkml.org/lkml/2006/10/21/227
http://lkml.org/lkml/2006/10/23/89
Submitter : Muli Ben-Yehuda <muli@il.ibm.com>
Gleb Natapov <glebn@voltaire.com>
Caused-By : Yinghai Lu <yinghai.lu@amd.com>
commit 45edfd1db02f818b3dc7e4743ee8585af6b78f78
Handled-By : Eric W. Biederman <ebiederm@xmission.com>
Patch : http://marc.theaimsgroup.com/?l=linux-kernel&m=116157813623508&w=2
http://marc.theaimsgroup.com/?l=linux-kernel&m=116157837104613&w=2
Status : patches available
Subject : missing select's of CRYPTO_ECB
References : http://lkml.org/lkml/2006/10/22/203
Submitter : Alistair John Strachan <s0348365@sms.ed.ac.uk>
Handled-By : Patrick McHardy <kaber@trash.net>
Patch : http://lkml.org/lkml/2006/10/23/207
Status : patch available
Subject : s390: Point sys_getcpu_wrapper at the proper syscall
References : http://lkml.org/lkml/2006/10/19/72
Submitter : Paul Mundt <lethal@linux-sh.org>
Caused-By : Heiko Carstens <heiko.carstens@de.ibm.com>
commit 8abfe01dae8c0ed7ca6bfb153a7fcab47df72a52
Handled-By : Paul Mundt <lethal@linux-sh.org>
Patch : http://lkml.org/lkml/2006/10/19/72
Status : patch available
Subject : pci_fixup_video change blows up on sparc64
References : http://lkml.org/lkml/2006/10/19/17
Submitter : David Miller <davem@davemloft.net>
Caused-By : Eiichiro Oiwa <eiichiro.oiwa.nm@hitachi.com>
commit b5e4efe7e061ff52ac97b9fa45acca529d8daeea
Handled-By : Eiichiro Oiwa <eiichiro.oiwa.nm@hitachi.com>
Patch : http://lkml.org/lkml/2006/10/23/31
Status : patch available
Subject : CONFIG_X86_VISWS=y, CONFIG_SMP=n compile error
References : http://lkml.org/lkml/2006/10/7/51
Submitter : Jesper Juhl <jesper.juhl@gmail.com>
Caused-By : David Howells <dhowells@redhat.com>
commit 7d12e780e003f93433d49ce78cfedf4b4c52adc5
Handled-By : Andrey Panin <pazke@donpac.ru>
Patch : http://lkml.org/lkml/2006/10/23/118
Status : patch available
Subject : DVB frontend selection causes compile errors
References : http://lkml.org/lkml/2006/10/8/244
Submitter : Adrian Bunk <bunk@stusta.de>
Caused-By : "Andrew de Quincey" <adq_dvb@lidskialf.net>
commit 176ac9da4f09820a43fd48f0e74b1486fc3603ba
Handled-By : Trent Piepho <xyzzy@speakeasy.org>
Patch : http://lkml.org/lkml/2006/10/14/157
Status : patch available
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Linux 2.6.19-rc3
2006-10-23 23:22 Linux 2.6.19-rc3 Linus Torvalds
` (3 preceding siblings ...)
2006-10-25 1:51 ` 2.6.19-rc3: known regressions with patches Adrian Bunk
@ 2006-10-25 11:25 ` Jean Delvare
2006-10-25 12:01 ` Damien Wyart
2006-10-25 20:13 ` Linux 2.6.19-rc3: !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB Athanasius
` (2 subsequent siblings)
7 siblings, 1 reply; 139+ messages in thread
From: Jean Delvare @ 2006-10-25 11:25 UTC (permalink / raw)
To: Auke Kok, Jeff Garzik
Cc: Linux Kernel Mailing List, Linus Torvalds, Adrian Bunk
On Mon, 23 Oct 2006 16:22:59 -0700 (PDT), Linus Torvalds wrote:
>
> Ok,
> a few days late, because I'm a retard and didn't think of doing a release
> when I should have.
>
> I'm also a bit grumpy, because I think people are sending me more stuff
> than they should at this stage in the game. We've been pretty good about
> keeping the later -rc releases quiet, please keep it that way.
>
> That said, it's mostly harmless cleanups and some architecture updates.
> And some of the added warnings about unused return values have caused a
> number of people to add error handling. And on the driver front, there's
> mainly new driver ID's, and a couple of new drivers.
>
> Shortlog appended,
> (...)
> Auke Kok (1):
> e100: fix reboot -f with netconsole enabled
This one breaks power-off and reboot on my laptop (thanks to git
bisect for isolating it). The shutdown freezes after "Shutdown: hda" or
"Rebooting". SysRq-p says the CPU is idle. If you need additional
information on my config or want me to do more tests, just ask.
Adrian, you can add this to your list of known regressions.
Thanks,
--
Jean Delvare
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Linux 2.6.19-rc3
2006-10-25 11:25 ` Linux 2.6.19-rc3 Jean Delvare
@ 2006-10-25 12:01 ` Damien Wyart
2006-10-25 16:25 ` Auke Kok
0 siblings, 1 reply; 139+ messages in thread
From: Damien Wyart @ 2006-10-25 12:01 UTC (permalink / raw)
To: Jean Delvare
Cc: Auke Kok, Jeff Garzik, Linux Kernel Mailing List, Linus Torvalds,
Adrian Bunk
> > Auke Kok (1):
> > e100: fix reboot -f with netconsole enabled
* Jean Delvare <khali@linux-fr.org> [2006-10-25 13:25]: This one breaks
> power-off and reboot on my laptop (thanks to git bisect for isolating
> it). The shutdown freezes after "Shutdown: hda" or "Rebooting".
> SysRq-p says the CPU is idle. If you need additional information on my
> config or want me to do more tests, just ask.
This has already been discussed, a fix has been posted (see recent
netdev messages) and should be pulled soon into mainline (I guess).
--
Damien Wyart
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Linux 2.6.19-rc3
2006-10-25 12:01 ` Damien Wyart
@ 2006-10-25 16:25 ` Auke Kok
2006-10-26 7:20 ` Jean Delvare
0 siblings, 1 reply; 139+ messages in thread
From: Auke Kok @ 2006-10-25 16:25 UTC (permalink / raw)
To: Damien Wyart
Cc: Jean Delvare, Jeff Garzik, Linux Kernel Mailing List,
Linus Torvalds, Adrian Bunk
Damien Wyart wrote:
>>> Auke Kok (1):
>>> e100: fix reboot -f with netconsole enabled
>
> * Jean Delvare <khali@linux-fr.org> [2006-10-25 13:25]: This one breaks
>> power-off and reboot on my laptop (thanks to git bisect for isolating
>> it). The shutdown freezes after "Shutdown: hda" or "Rebooting".
>> SysRq-p says the CPU is idle. If you need additional information on my
>> config or want me to do more tests, just ask.
>
> This has already been discussed, a fix has been posted (see recent
> netdev messages) and should be pulled soon into mainline (I guess).
>
for those interested, here's the fix (which is already pushed to jgarzik)
Cheers,
Auke
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index d4a2572..815eb29 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -2719,7 +2719,10 @@ static int e100_suspend(struct pci_dev *
struct net_device *netdev = pci_get_drvdata(pdev);
struct nic *nic = netdev_priv(netdev);
- netif_poll_disable(nic->netdev);
+#ifdef CONFIG_E100_NAPI
+ if (netif_running(netdev))
+ netif_poll_disable(nic->netdev);
+#endif
del_timer_sync(&nic->watchdog);
netif_carrier_off(nic->netdev);
@@ -2763,7 +2766,10 @@ static void e100_shutdown(struct pci_dev
struct net_device *netdev = pci_get_drvdata(pdev);
struct nic *nic = netdev_priv(netdev);
- netif_poll_disable(nic->netdev);
+#ifdef CONFIG_E100_NAPI
+ if (netif_running(netdev))
+ netif_poll_disable(nic->netdev);
+#endif
del_timer_sync(&nic->watchdog);
netif_carrier_off(nic->netdev);
^ permalink raw reply related [flat|nested] 139+ messages in thread
* Linux 2.6.19-rc3: !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB
2006-10-23 23:22 Linux 2.6.19-rc3 Linus Torvalds
` (4 preceding siblings ...)
2006-10-25 11:25 ` Linux 2.6.19-rc3 Jean Delvare
@ 2006-10-25 20:13 ` Athanasius
2006-10-25 22:17 ` [PATCH] " Randy Dunlap
2006-10-26 22:45 ` 2.6.19-rc3: known unfixed regressions (v2) Adrian Bunk
2006-10-29 23:13 ` 2.6.19-rc3: known unfixed regressions (v3) Adrian Bunk
7 siblings, 1 reply; 139+ messages in thread
From: Athanasius @ 2006-10-25 20:13 UTC (permalink / raw)
To: Linus Torvalds, linux-kernel; +Cc: David Brownell, Roman Zippel
[-- Attachment #1.1: Type: text/plain, Size: 6816 bytes --]
1) It's possible in Device Drivers -> Network device support to go from
having both:
PHY device support
Ethernet (10 or 100Mbit)
set, to turning off the latter option, which automatically turns off the
prior option, but still being able to get into
the "PHY device support" option, although the options area is blank, and
trying to cursor up/down just prints a ^@ (NUL ?).
If an option is disabled in this way it really needs to be clearer as
to what's happened to it.
2) With both those sections off it's possible to configure in "Device
Drivers -> USB Support -> USB Network Adapters" options and modules, but
then not have usbnet.ko successfully build because it now tries to use
mii_* symbols which aren't available, cf:
make bzImage
...
<completes successfully>
make V=1 modules
...
make -f scripts/Makefile.build obj=lib/zlib_deflate
make -f scripts/Makefile.build obj=lib/zlib_inflate
make -f scripts/Makefile.build obj=arch/i386/lib
Building modules, stage 2.
make -f /usr/local/src/kernels/linux-2.6.19-rc3/scripts/Makefile.modpost
scripts/mod/modpost -m -a -o /usr/local/src/kernels/linux-2.6.19-rc3/Module.symvers vmlinux arch/i386/crypto/aes-i586.o arch/i386/crypto/twofish-i586.o crypto/aes.o crypto/anubis.o crypto/arc4.o crypto/blowfish.o crypto/cast5.o crypto/cast6.o crypto/crc32c.o crypto/crypto_null.o crypto/ecb.o crypto/khazad.o crypto/md4.o crypto/michael_mic.o crypto/serpent.o crypto/sha256.o crypto/sha512.o crypto/tcrypt.o crypto/tea.o crypto/tgr192.o crypto/twofish.o crypto/twofish_common.o crypto/wp512.o drivers/ata/ahci.o drivers/ata/sata_promise.o drivers/ata/sata_sx4.o drivers/ata/sata_via.o drivers/base/firmware_class.o drivers/block/cryptoloop.o drivers/block/loop.o drivers/block/nbd.o drivers/block/rd.o drivers/bluetooth/bcm203x.o drivers/bluetooth/bfusb.o drivers/bluetooth/bpa10x.o drivers/bluetooth/hci_uart.o drivers/bluetooth/hci_usb.o drivers/bluetooth/hci_vhci.o drivers/char/ipmi/ipmi_devintf.o drivers/char/ipmi/ipmi_msghandler.o drivers/char/ipmi/ipmi_poweroff.o drivers/char/ipmi/ipmi_si.o drivers/char/ipmi/ipmi_watchdog.o drivers/char/lp.o drivers/connector/cn.o drivers/crypto/padlock-sha.o drivers/hwmon/hwmon-vid.o drivers/hwmon/hwmon.o drivers/hwmon/k8temp.o drivers/hwmon/lm75.o drivers/hwmon/w83627hf.o drivers/i2c/busses/i2c-isa.o drivers/i2c/busses/i2c-via.o drivers/i2c/busses/i2c-viapro.o drivers/i2c/chips/eeprom.o drivers/ide/ide-cd.o drivers/ieee1394/dv1394.o drivers/ieee1394/eth1394.o drivers/ieee1394/ieee1394.o drivers/ieee1394/ohci1394.o drivers/ieee1394/raw1394.o drivers/ieee1394/sbp2.o drivers/ieee1394/video1394.o drivers/input/evbug.o drivers/input/evdev.o drivers/input/gameport/gameport.o drivers/input/gameport/ns558.o drivers/input/joydev.o drivers/input/joystick/analog.o drivers/input/joystick/joydump.o drivers/input/misc/pcspkr.o drivers/input/misc/uinput.o drivers/input/mouse/psmouse.o drivers/media/video/c-qcam.o drivers/media/video/compat_ioctl32.o drivers/media/video/v4l1-compat.o drivers/media/video/v4l2-common.o drivers/media/video/video-buf.o drivers/media/video/videodev.o drivers/media/video/vivi.o drivers/misc/tifm_7xx1.o drivers/misc/tifm_core.o drivers/mmc/mmc_block.o drivers/mmc/mmc_core.o drivers/mmc/sdhci.o drivers/mmc/tifm_sd.o drivers/mmc/wbsd.o drivers/net/bsd_comp.o drivers/net/dummy.o drivers/net/ppp_async.o drivers/net/ppp_deflate.o drivers/net/ppp_generic.o drivers/net/ppp_mppe.o drivers/net/ppp_synctty.o drivers/net/pppoe.o drivers/net/pppox.o drivers/net/sk98lin/sk98lin.o drivers/net/slhc.o drivers/net/slip.o drivers/net/tun.o drivers/parport/parport.o drivers/parport/parport_pc.o drivers/scsi/ide-scsi.o drivers/scsi/scsi_transport_fc.o drivers/scsi/scsi_transport_iscsi.o drivers/scsi/scsi_transport_sas.o drivers/scsi/scsi_transport_spi.o drivers/scsi/sd_mod.o drivers/scsi/sg.o drivers/scsi/sr_mod.o drivers/serial/8250.o drivers/serial/8250_pci.o drivers/serial/8250_pnp.o drivers/serial/serial_core.o drivers/usb/class/cdc-acm.o drivers/usb/class/usblp.o drivers/usb/host/ehci-hcd.o drivers/usb/host/uhci-hcd.o drivers/usb/input/usbhid.o drivers/usb/net/cdc_ether.o drivers/usb/net/cdc_subset.o drivers/usb/net/net1080.o drivers/usb/net/usbnet.o drivers/usb/net/zaurus.o drivers/usb/serial/aircable.o drivers/usb/serial/option.o drivers/usb/serial/usbserial.o drivers/usb/storage/usb-storage.o drivers/video/cfbcopyarea.o drivers/video/cfbfillrect.o drivers/video/cfbimgblt.o drivers/video/console/bitblit.o drivers/video/console/fbcon.o drivers/video/console/font.o drivers/video/console/softcursor.o drivers/video/console/tileblit.o drivers/video/fb.o drivers/video/nvidia/nvidiafb.o fs/autofs/autofs.o fs/autofs4/autofs4.o fs/binfmt_aout.o fs/binfmt_misc.o fs/cifs/cifs.o fs/dlm/dlm.o fs/exportfs/exportfs.o fs/minix/minix.o fs/msdos/msdos.o fs/nfsd/nfsd.o fs/nls/nls_ascii.o fs/smbfs/smbfs.o lib/crc-ccitt.o lib/crc16.o lib/crc32.o lib/libcrc32c.o net/bluetooth/bluetooth.o net/bluetooth/bnep/bnep.o net/bluetooth/hidp/hidp.o net/bluetooth/l2cap.o net/bluetooth/rfcomm/rfcomm.o net/bluetooth/sco.o net/core/pktgen.o net/dccp/ccids/dccp_ccid2.o net/dccp/ccids/dccp_ccid3.o net/dccp/ccids/lib/dccp_tfrc_lib.o net/dccp/dccp.o net/dccp/dccp_diag.o net/dccp/dccp_ipv4.o net/ipv6/ip6_tunnel.o net/ipv6/netfilter/ip6_queue.o net/key/af_key.o net/sched/sch_netem.o net/sctp/sctp.o net/sunrpc/auth_gss/rpcsec_gss_spkm3.o sound/core/oss/snd-mixer-oss.o sound/core/oss/snd-pcm-oss.o sound/core/seq/oss/snd-seq-oss.o sound/core/seq/snd-seq-device.o sound/core/seq/snd-seq-dummy.o sound/core/seq/snd-seq-midi-event.o sound/core/seq/snd-seq-midi.o sound/core/seq/snd-seq-virmidi.o sound/core/seq/snd-seq.o sound/core/snd-page-alloc.o sound/core/snd-pcm.o sound/core/snd-rawmidi.o sound/core/snd-rtctimer.o sound/core/snd-timer.o sound/core/snd.o sound/drivers/mpu401/snd-mpu401-uart.o sound/drivers/mpu401/snd-mpu401.o sound/drivers/snd-dummy.o sound/drivers/snd-serial-u16550.o sound/drivers/snd-virmidi.o sound/pci/ac97/snd-ac97-bus.o sound/pci/ac97/snd-ac97-codec.o sound/pci/snd-via82xx-modem.o sound/pci/snd-via82xx.o sound/soundcore.o
WARNING: "mii_ethtool_gset" [drivers/usb/net/usbnet.ko] undefined!
WARNING: "mii_nway_restart" [drivers/usb/net/usbnet.ko] undefined!
WARNING: "mii_link_ok" [drivers/usb/net/usbnet.ko] undefined!
WARNING: "mii_ethtool_sset" [drivers/usb/net/usbnet.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
My example .config is attached. This worked fine with 2.6.19-rc2 before
usbnet started referencing mii_* symbols.
-Ath
--
- Athanasius = Athanasius(at)miggy.org / http://www.miggy.org/
Finger athan(at)fysh.org for PGP key
"And it's me who is my enemy. Me who beats me up.
Me who makes the monsters. Me who strips my confidence." Paula Cole - ME
[-- Attachment #1.2: emelia-2.6.19-rc3 --]
[-- Type: text/plain, Size: 52677 bytes --]
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.19-rc3
# Wed Oct 25 20:57:36 2006
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_IPC_NS is not set
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
# CONFIG_UTS_NS is not set
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_RELAY=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_TASK_XACCT=y
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_KMOD=y
#
# Block layer
#
CONFIG_BLOCK=y
# CONFIG_LBD is not set
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_LSF=y
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
#
# Processor type and features
#
# CONFIG_SMP is not set
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
CONFIG_MK8=y
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
# CONFIG_X86_MCE_P4THERMAL is not set
CONFIG_VM86=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
CONFIG_X86_REBOOTFIXUPS=y
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
#
# Firmware Drivers
#
CONFIG_EDD=y
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_HIGHMEM=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not set
# CONFIG_HIGHPTE is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_REGPARM=y
CONFIG_SECCOMP=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
CONFIG_PHYSICAL_START=0x100000
# CONFIG_COMPAT_VDSO is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
CONFIG_PM_LEGACY=y
# CONFIG_PM_DEBUG is not set
# CONFIG_PM_SYSFS_DEPRECATED is not set
# CONFIG_SOFTWARE_SUSPEND is not set
#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
# CONFIG_ACPI_SLEEP is not set
# CONFIG_ACPI_AC is not set
# CONFIG_ACPI_BATTERY is not set
# CONFIG_ACPI_BUTTON is not set
CONFIG_ACPI_VIDEO=y
# CONFIG_ACPI_HOTKEY is not set
CONFIG_ACPI_FAN=y
# CONFIG_ACPI_DOCK is not set
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_IBM is not set
# CONFIG_ACPI_TOSHIBA is not set
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not set
# CONFIG_ACPI_SBS is not set
#
# APM (Advanced Power Management) BIOS Support
#
# CONFIG_APM is not set
#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
# CONFIG_CPU_FREQ_DEBUG is not set
CONFIG_CPU_FREQ_STAT=y
CONFIG_CPU_FREQ_STAT_DETAILS=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
#
# CPUFreq processor drivers
#
# CONFIG_X86_ACPI_CPUFREQ is not set
# CONFIG_X86_POWERNOW_K6 is not set
# CONFIG_X86_POWERNOW_K7 is not set
CONFIG_X86_POWERNOW_K8=y
CONFIG_X86_POWERNOW_K8_ACPI=y
# CONFIG_X86_GX_SUSPMOD is not set
# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
# CONFIG_X86_SPEEDSTEP_ICH is not set
# CONFIG_X86_SPEEDSTEP_SMI is not set
# CONFIG_X86_P4_CLOCKMOD is not set
# CONFIG_X86_CPUFREQ_NFORCE2 is not set
# CONFIG_X86_LONGRUN is not set
# CONFIG_X86_LONGHAUL is not set
#
# shared options
#
CONFIG_X86_ACPI_CPUFREQ_PROC_INTF=y
# CONFIG_X86_SPEEDSTEP_LIB is not set
#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
# CONFIG_PCIEPORTBUS is not set
# CONFIG_PCI_MSI is not set
# CONFIG_PCI_MULTITHREAD_PROBE is not set
# CONFIG_PCI_DEBUG is not set
CONFIG_HT_IRQ=y
CONFIG_ISA_DMA_API=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set
#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set
#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_MISC=m
#
# Networking
#
CONFIG_NET=y
#
# Networking options
#
# CONFIG_NETDEBUG is not set
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
CONFIG_XFRM_SUB_POLICY=y
CONFIG_NET_KEY=m
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=y
CONFIG_NET_IPGRE=y
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=y
CONFIG_INET_ESP=y
CONFIG_INET_IPCOMP=y
CONFIG_INET_XFRM_TUNNEL=y
CONFIG_INET_TUNNEL=y
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
CONFIG_IPV6=y
CONFIG_IPV6_PRIVACY=y
CONFIG_IPV6_ROUTER_PREF=y
CONFIG_IPV6_ROUTE_INFO=y
CONFIG_INET6_AH=y
CONFIG_INET6_ESP=y
CONFIG_INET6_IPCOMP=y
CONFIG_IPV6_MIP6=y
CONFIG_INET6_XFRM_TUNNEL=y
CONFIG_INET6_TUNNEL=y
CONFIG_INET6_XFRM_MODE_TRANSPORT=y
CONFIG_INET6_XFRM_MODE_TUNNEL=y
CONFIG_INET6_XFRM_MODE_BEET=y
CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=y
CONFIG_IPV6_SIT=y
CONFIG_IPV6_TUNNEL=m
CONFIG_IPV6_MULTIPLE_TABLES=y
# CONFIG_IPV6_SUBTREES is not set
CONFIG_IPV6_ROUTE_FWMARK=y
CONFIG_NETWORK_SECMARK=y
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=y
CONFIG_NETFILTER_NETLINK_QUEUE=y
CONFIG_NETFILTER_NETLINK_LOG=y
CONFIG_NETFILTER_XTABLES=y
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=y
CONFIG_NETFILTER_XT_TARGET_CONNMARK=y
CONFIG_NETFILTER_XT_TARGET_DSCP=y
CONFIG_NETFILTER_XT_TARGET_MARK=y
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=y
CONFIG_NETFILTER_XT_TARGET_NOTRACK=y
CONFIG_NETFILTER_XT_TARGET_SECMARK=y
CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=y
CONFIG_NETFILTER_XT_MATCH_COMMENT=y
CONFIG_NETFILTER_XT_MATCH_CONNBYTES=y
CONFIG_NETFILTER_XT_MATCH_CONNMARK=y
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y
CONFIG_NETFILTER_XT_MATCH_DCCP=y
CONFIG_NETFILTER_XT_MATCH_DSCP=y
CONFIG_NETFILTER_XT_MATCH_ESP=y
CONFIG_NETFILTER_XT_MATCH_HELPER=y
CONFIG_NETFILTER_XT_MATCH_LENGTH=y
CONFIG_NETFILTER_XT_MATCH_LIMIT=y
CONFIG_NETFILTER_XT_MATCH_MAC=y
CONFIG_NETFILTER_XT_MATCH_MARK=y
CONFIG_NETFILTER_XT_MATCH_POLICY=y
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=y
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=y
CONFIG_NETFILTER_XT_MATCH_QUOTA=y
CONFIG_NETFILTER_XT_MATCH_REALM=y
CONFIG_NETFILTER_XT_MATCH_SCTP=y
CONFIG_NETFILTER_XT_MATCH_STATE=y
CONFIG_NETFILTER_XT_MATCH_STATISTIC=y
CONFIG_NETFILTER_XT_MATCH_STRING=y
CONFIG_NETFILTER_XT_MATCH_TCPMSS=y
#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_CT_ACCT=y
CONFIG_IP_NF_CONNTRACK_MARK=y
CONFIG_IP_NF_CONNTRACK_SECMARK=y
CONFIG_IP_NF_CONNTRACK_EVENTS=y
CONFIG_IP_NF_CONNTRACK_NETLINK=y
CONFIG_IP_NF_CT_PROTO_SCTP=y
CONFIG_IP_NF_FTP=y
CONFIG_IP_NF_IRC=y
CONFIG_IP_NF_NETBIOS_NS=y
CONFIG_IP_NF_TFTP=y
CONFIG_IP_NF_AMANDA=y
CONFIG_IP_NF_PPTP=y
CONFIG_IP_NF_H323=y
CONFIG_IP_NF_SIP=y
CONFIG_IP_NF_QUEUE=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_IPRANGE=y
CONFIG_IP_NF_MATCH_TOS=y
CONFIG_IP_NF_MATCH_RECENT=y
CONFIG_IP_NF_MATCH_ECN=y
CONFIG_IP_NF_MATCH_AH=y
CONFIG_IP_NF_MATCH_TTL=y
CONFIG_IP_NF_MATCH_OWNER=y
CONFIG_IP_NF_MATCH_ADDRTYPE=y
CONFIG_IP_NF_MATCH_HASHLIMIT=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y
CONFIG_IP_NF_TARGET_TCPMSS=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_IP_NF_TARGET_NETMAP=y
CONFIG_IP_NF_TARGET_SAME=y
CONFIG_IP_NF_NAT_SNMP_BASIC=y
CONFIG_IP_NF_NAT_IRC=y
CONFIG_IP_NF_NAT_FTP=y
CONFIG_IP_NF_NAT_TFTP=y
CONFIG_IP_NF_NAT_AMANDA=y
CONFIG_IP_NF_NAT_PPTP=y
CONFIG_IP_NF_NAT_H323=y
CONFIG_IP_NF_NAT_SIP=y
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_TOS=y
CONFIG_IP_NF_TARGET_ECN=y
CONFIG_IP_NF_TARGET_TTL=y
CONFIG_IP_NF_TARGET_CLUSTERIP=y
CONFIG_IP_NF_RAW=y
CONFIG_IP_NF_ARPTABLES=y
CONFIG_IP_NF_ARPFILTER=y
CONFIG_IP_NF_ARP_MANGLE=y
#
# IPv6: Netfilter Configuration (EXPERIMENTAL)
#
CONFIG_IP6_NF_QUEUE=m
CONFIG_IP6_NF_IPTABLES=y
CONFIG_IP6_NF_MATCH_RT=y
CONFIG_IP6_NF_MATCH_OPTS=y
CONFIG_IP6_NF_MATCH_FRAG=y
CONFIG_IP6_NF_MATCH_HL=y
CONFIG_IP6_NF_MATCH_OWNER=y
CONFIG_IP6_NF_MATCH_IPV6HEADER=y
CONFIG_IP6_NF_MATCH_AH=y
CONFIG_IP6_NF_MATCH_EUI64=y
CONFIG_IP6_NF_FILTER=y
CONFIG_IP6_NF_TARGET_LOG=y
CONFIG_IP6_NF_TARGET_REJECT=y
CONFIG_IP6_NF_MANGLE=y
CONFIG_IP6_NF_TARGET_HL=y
CONFIG_IP6_NF_RAW=y
#
# DCCP Configuration (EXPERIMENTAL)
#
CONFIG_IP_DCCP=m
CONFIG_INET_DCCP_DIAG=m
CONFIG_IP_DCCP_ACKVEC=y
#
# DCCP CCIDs Configuration (EXPERIMENTAL)
#
CONFIG_IP_DCCP_CCID2=m
# CONFIG_IP_DCCP_CCID2_DEBUG is not set
CONFIG_IP_DCCP_CCID3=m
CONFIG_IP_DCCP_TFRC_LIB=m
#
# DCCP Kernel Hacking
#
# CONFIG_IP_DCCP_DEBUG is not set
#
# SCTP Configuration (EXPERIMENTAL)
#
CONFIG_IP_SCTP=m
CONFIG_SCTP_DBG_MSG=y
CONFIG_SCTP_DBG_OBJCNT=y
# CONFIG_SCTP_HMAC_NONE is not set
CONFIG_SCTP_HMAC_SHA1=y
# CONFIG_SCTP_HMAC_MD5 is not set
#
# TIPC Configuration (EXPERIMENTAL)
#
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_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
#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CLK_JIFFIES=y
# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
# CONFIG_NET_SCH_CLK_CPU is not set
#
# Queueing/Scheduling
#
CONFIG_NET_SCH_CBQ=y
CONFIG_NET_SCH_HTB=y
CONFIG_NET_SCH_HFSC=y
CONFIG_NET_SCH_PRIO=y
CONFIG_NET_SCH_RED=y
CONFIG_NET_SCH_SFQ=y
CONFIG_NET_SCH_TEQL=y
CONFIG_NET_SCH_TBF=y
CONFIG_NET_SCH_GRED=y
CONFIG_NET_SCH_DSMARK=y
CONFIG_NET_SCH_NETEM=m
CONFIG_NET_SCH_INGRESS=y
#
# Classification
#
CONFIG_NET_CLS=y
CONFIG_NET_CLS_BASIC=y
CONFIG_NET_CLS_TCINDEX=y
CONFIG_NET_CLS_ROUTE4=y
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=y
CONFIG_NET_CLS_U32=y
CONFIG_CLS_U32_PERF=y
CONFIG_CLS_U32_MARK=y
CONFIG_NET_CLS_RSVP=y
CONFIG_NET_CLS_RSVP6=y
CONFIG_NET_EMATCH=y
CONFIG_NET_EMATCH_STACK=32
CONFIG_NET_EMATCH_CMP=y
CONFIG_NET_EMATCH_NBYTE=y
CONFIG_NET_EMATCH_U32=y
CONFIG_NET_EMATCH_META=y
CONFIG_NET_EMATCH_TEXT=y
CONFIG_NET_CLS_ACT=y
CONFIG_NET_ACT_POLICE=y
CONFIG_NET_ACT_GACT=y
CONFIG_GACT_PROB=y
CONFIG_NET_ACT_MIRRED=y
CONFIG_NET_ACT_IPT=y
CONFIG_NET_ACT_PEDIT=y
CONFIG_NET_ACT_SIMP=y
CONFIG_NET_CLS_IND=y
CONFIG_NET_ESTIMATOR=y
#
# Network testing
#
CONFIG_NET_PKTGEN=m
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
CONFIG_BT=m
CONFIG_BT_L2CAP=m
CONFIG_BT_SCO=m
CONFIG_BT_RFCOMM=m
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_BNEP=m
CONFIG_BT_BNEP_MC_FILTER=y
CONFIG_BT_BNEP_PROTO_FILTER=y
CONFIG_BT_HIDP=m
#
# Bluetooth device drivers
#
CONFIG_BT_HCIUSB=m
CONFIG_BT_HCIUSB_SCO=y
CONFIG_BT_HCIUART=m
CONFIG_BT_HCIUART_H4=y
CONFIG_BT_HCIUART_BCSP=y
CONFIG_BT_HCIBCM203X=m
CONFIG_BT_HCIBPA10X=m
CONFIG_BT_HCIBFUSB=m
CONFIG_BT_HCIVHCI=m
# CONFIG_IEEE80211 is not set
CONFIG_FIB_RULES=y
#
# Device Drivers
#
#
# Generic Driver Options
#
# CONFIG_STANDALONE is not set
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_SYS_HYPERVISOR is not set
#
# Connector - unified userspace <-> kernelspace linker
#
CONFIG_CONNECTOR=m
#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set
#
# Parallel port support
#
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
# CONFIG_PARPORT_SERIAL is not set
CONFIG_PARPORT_PC_FIFO=y
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_AX88796 is not set
# CONFIG_PARPORT_1284 is not set
#
# Plug and Play support
#
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set
#
# Protocols
#
CONFIG_ISAPNP=y
# CONFIG_PNPBIOS is not set
CONFIG_PNPACPI=y
#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_BLK_DEV_NBD=m
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
CONFIG_BLK_DEV_INITRD=y
CONFIG_CDROM_PKTCDVD=y
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
# CONFIG_ATA_OVER_ETH is not set
#
# Misc devices
#
# CONFIG_IBM_ASM is not set
# CONFIG_SGI_IOC4 is not set
CONFIG_TIFM_CORE=m
CONFIG_TIFM_7XX1=m
#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
# CONFIG_IDEDISK_MULTI_MODE is not set
CONFIG_BLK_DEV_IDECD=m
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
CONFIG_BLK_DEV_IDESCSI=m
# CONFIG_IDE_TASK_IOCTL is not set
#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_IDEPNP is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
# CONFIG_BLK_DEV_GENERIC is not set
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_IDEDMA_ONLYDISK=y
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_CS5535 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_JMICRON is not set
# CONFIG_BLK_DEV_SC1200 is not set
# CONFIG_BLK_DEV_PIIX is not set
# CONFIG_BLK_DEV_IT821X is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
CONFIG_BLK_DEV_VIA82CXXX=y
# CONFIG_IDE_ARM is not set
# CONFIG_IDE_CHIPSETS is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_NETLINK=y
CONFIG_SCSI_PROC_FS=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=m
# CONFIG_BLK_DEV_SR_VENDOR is not set
CONFIG_CHR_DEV_SG=m
# CONFIG_CHR_DEV_SCH is not set
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=m
CONFIG_SCSI_FC_ATTRS=m
CONFIG_SCSI_ISCSI_ATTRS=m
CONFIG_SCSI_SAS_ATTRS=m
# CONFIG_SCSI_SAS_LIBSAS is not set
#
# SCSI low-level drivers
#
# CONFIG_ISCSI_TCP is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC94XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_SCSI_ARCMSR is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_PPA is not set
# CONFIG_SCSI_IMM is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_STEX is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_QLA_ISCSI is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set
#
# Serial ATA (prod) and Parallel ATA (experimental) drivers
#
CONFIG_ATA=y
CONFIG_SATA_AHCI=m
# CONFIG_SATA_SVW is not set
# CONFIG_ATA_PIIX 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=m
CONFIG_SATA_SX4=m
# CONFIG_SATA_SIL is not set
# CONFIG_SATA_SIL24 is not set
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_ULI is not set
CONFIG_SATA_VIA=m
# CONFIG_SATA_VITESSE is not set
CONFIG_SATA_INTEL_COMBINED=y
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CS5535 is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
CONFIG_ATA_GENERIC=y
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_ISAPNP is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_PATA_LEGACY is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_QDI is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RZ1000 is not set
# CONFIG_PATA_SC1200 is not set
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
CONFIG_PATA_VIA=y
# CONFIG_PATA_WINBOND is not set
#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set
#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
# CONFIG_FUSION_SPI is not set
# CONFIG_FUSION_FC is not set
# CONFIG_FUSION_SAS is not set
#
# IEEE 1394 (FireWire) support
#
CONFIG_IEEE1394=m
#
# Subsystem Options
#
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
CONFIG_IEEE1394_OUI_DB=y
CONFIG_IEEE1394_EXTRA_CONFIG_ROMS=y
CONFIG_IEEE1394_CONFIG_ROM_IP1394=y
# CONFIG_IEEE1394_EXPORT_FULL_API is not set
#
# Device Drivers
#
# CONFIG_IEEE1394_PCILYNX is not set
CONFIG_IEEE1394_OHCI1394=m
#
# Protocol Drivers
#
CONFIG_IEEE1394_VIDEO1394=m
CONFIG_IEEE1394_SBP2=m
# CONFIG_IEEE1394_SBP2_PHYS_DMA is not set
CONFIG_IEEE1394_ETH1394=m
CONFIG_IEEE1394_DV1394=m
CONFIG_IEEE1394_RAWIO=m
#
# I2O device support
#
# CONFIG_I2O is not set
#
# Network device support
#
CONFIG_NETDEVICES=y
# CONFIG_IFB is not set
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=m
# CONFIG_NET_SB1000 is not set
#
# ARCnet devices
#
# CONFIG_ARCNET is not set
#
# PHY device support
#
#
# Ethernet (10 or 100Mbit)
#
# CONFIG_NET_ETHERNET is not set
#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
CONFIG_SK98LIN=m
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set
# CONFIG_QLA3XXX is not set
#
# Ethernet (10000 Mbit)
#
# CONFIG_CHELSIO_T1 is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set
# CONFIG_MYRI10GE is not set
#
# Token Ring devices
#
# CONFIG_TR is not set
#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set
#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
CONFIG_PPP=m
# CONFIG_PPP_MULTILINK is not set
# CONFIG_PPP_FILTER is not set
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPP_MPPE=m
CONFIG_PPPOE=m
CONFIG_SLIP=m
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLHC=m
CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
CONFIG_NETCONSOLE=y
CONFIG_NETPOLL=y
CONFIG_NETPOLL_RX=y
CONFIG_NETPOLL_TRAP=y
CONFIG_NET_POLL_CONTROLLER=y
#
# ISDN subsystem
#
# CONFIG_ISDN is not set
#
# Telephony Support
#
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1280
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=1024
CONFIG_INPUT_JOYDEV=m
# CONFIG_INPUT_TSDEV is not set
CONFIG_INPUT_EVDEV=m
CONFIG_INPUT_EVBUG=m
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=m
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
# CONFIG_MOUSE_VSXXXAA is not set
CONFIG_INPUT_JOYSTICK=y
CONFIG_JOYSTICK_ANALOG=m
# CONFIG_JOYSTICK_A3D is not set
# CONFIG_JOYSTICK_ADI is not set
# CONFIG_JOYSTICK_COBRA is not set
# CONFIG_JOYSTICK_GF2K is not set
# CONFIG_JOYSTICK_GRIP is not set
# CONFIG_JOYSTICK_GRIP_MP is not set
# CONFIG_JOYSTICK_GUILLEMOT is not set
# CONFIG_JOYSTICK_INTERACT is not set
# CONFIG_JOYSTICK_SIDEWINDER is not set
# CONFIG_JOYSTICK_TMDC is not set
# CONFIG_JOYSTICK_IFORCE is not set
# CONFIG_JOYSTICK_WARRIOR is not set
# CONFIG_JOYSTICK_MAGELLAN is not set
# CONFIG_JOYSTICK_SPACEORB is not set
# CONFIG_JOYSTICK_SPACEBALL is not set
# CONFIG_JOYSTICK_STINGER is not set
# CONFIG_JOYSTICK_TWIDJOY is not set
# CONFIG_JOYSTICK_DB9 is not set
# CONFIG_JOYSTICK_GAMECON is not set
# CONFIG_JOYSTICK_TURBOGRAFX is not set
CONFIG_JOYSTICK_JOYDUMP=m
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=m
# CONFIG_INPUT_WISTRON_BTNS is not set
CONFIG_INPUT_UINPUT=m
#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
CONFIG_GAMEPORT=m
CONFIG_GAMEPORT_NS558=m
# CONFIG_GAMEPORT_L4 is not set
# CONFIG_GAMEPORT_EMU10K1 is not set
# CONFIG_GAMEPORT_FM801 is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
# CONFIG_SERIAL_NONSTANDARD is not set
#
# Serial drivers
#
CONFIG_SERIAL_8250=m
CONFIG_SERIAL_8250_PCI=m
CONFIG_SERIAL_8250_PNP=m
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
# CONFIG_SERIAL_8250_MANY_PORTS is not set
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
# CONFIG_SERIAL_8250_RSA is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=m
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_PRINTER=m
# CONFIG_LP_CONSOLE is not set
# CONFIG_PPDEV is not set
# CONFIG_TIPAR is not set
#
# IPMI
#
CONFIG_IPMI_HANDLER=m
# CONFIG_IPMI_PANIC_EVENT is not set
CONFIG_IPMI_DEVICE_INTERFACE=m
CONFIG_IPMI_SI=m
CONFIG_IPMI_WATCHDOG=m
CONFIG_IPMI_POWEROFF=m
#
# Watchdog Cards
#
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set
#
# Watchdog Device Drivers
#
CONFIG_SOFT_WATCHDOG=y
# CONFIG_ACQUIRE_WDT is not set
# CONFIG_ADVANTECH_WDT is not set
# CONFIG_ALIM1535_WDT is not set
# CONFIG_ALIM7101_WDT is not set
# CONFIG_SC520_WDT is not set
# CONFIG_EUROTECH_WDT is not set
# CONFIG_IB700_WDT is not set
# CONFIG_IBMASR is not set
# CONFIG_WAFER_WDT is not set
# CONFIG_I6300ESB_WDT is not set
# CONFIG_I8XX_TCO is not set
# CONFIG_ITCO_WDT is not set
# CONFIG_SC1200_WDT is not set
# CONFIG_60XX_WDT is not set
# CONFIG_SBC8360_WDT is not set
# CONFIG_CPU5_WDT is not set
# CONFIG_SMSC37B787_WDT is not set
# CONFIG_W83627HF_WDT is not set
# CONFIG_W83697HF_WDT is not set
# CONFIG_W83877F_WDT is not set
# CONFIG_W83977F_WDT is not set
# CONFIG_MACHZ_WDT is not set
# CONFIG_SBC_EPX_C3_WATCHDOG is not set
#
# ISA-based Watchdog Cards
#
# CONFIG_PCWATCHDOG is not set
# CONFIG_MIXCOMWD is not set
# CONFIG_WDT is not set
#
# PCI-based Watchdog Cards
#
# CONFIG_PCIPCWATCHDOG is not set
# CONFIG_WDTPCI is not set
#
# USB-based Watchdog Cards
#
# CONFIG_USBPCWATCHDOG is not set
# CONFIG_HW_RANDOM is not set
CONFIG_NVRAM=y
CONFIG_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set
#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=y
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_ATI is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not set
# CONFIG_AGP_INTEL is not set
# CONFIG_AGP_NVIDIA is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
CONFIG_AGP_VIA=y
# CONFIG_AGP_EFFICEON is not set
CONFIG_DRM=y
# 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_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
# CONFIG_NSC_GPIO is not set
# CONFIG_CS5535_GPIO is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_HPET=y
# CONFIG_HPET_RTC_IRQ is not set
CONFIG_HPET_MMAP=y
CONFIG_HANGCHECK_TIMER=y
#
# TPM devices
#
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set
#
# I2C support
#
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_ALGOPCF=y
CONFIG_I2C_ALGOPCA=y
#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_ELEKTOR is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
# CONFIG_I2C_PIIX4 is not set
CONFIG_I2C_ISA=m
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PARPORT is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_STUB is not set
CONFIG_I2C_VIA=m
CONFIG_I2C_VIAPRO=m
# CONFIG_I2C_VOODOO3 is not set
# CONFIG_I2C_PCA_ISA is not set
#
# Miscellaneous I2C Chip support
#
# CONFIG_SENSORS_DS1337 is not set
# CONFIG_SENSORS_DS1374 is not set
CONFIG_SENSORS_EEPROM=m
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_MAX6875 is not set
CONFIG_I2C_DEBUG_CORE=y
CONFIG_I2C_DEBUG_ALGO=y
CONFIG_I2C_DEBUG_BUS=y
CONFIG_I2C_DEBUG_CHIP=y
#
# SPI support
#
CONFIG_SPI=y
# CONFIG_SPI_DEBUG is not set
CONFIG_SPI_MASTER=y
#
# SPI Master Controller Drivers
#
# CONFIG_SPI_BITBANG is not set
# CONFIG_SPI_BUTTERFLY is not set
#
# SPI Protocol Masters
#
#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set
#
# Hardware Monitoring support
#
CONFIG_HWMON=m
CONFIG_HWMON_VID=m
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
CONFIG_SENSORS_K8TEMP=m
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_FSCPOS is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM70 is not set
CONFIG_SENSORS_LM75=m
# 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_MAX1619 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 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_W83L785TS is not set
CONFIG_SENSORS_W83627HF=m
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_SENSORS_HDAPS is not set
CONFIG_HWMON_DEBUG_CHIP=y
#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m
CONFIG_VIDEO_V4L1=y
CONFIG_VIDEO_V4L1_COMPAT=y
CONFIG_VIDEO_V4L2=y
#
# Video Capture Adapters
#
#
# Video Capture Adapters
#
# CONFIG_VIDEO_ADV_DEBUG is not set
CONFIG_VIDEO_HELPER_CHIPS_AUTO=y
CONFIG_VIDEO_VIVI=m
# CONFIG_VIDEO_BT848 is not set
# CONFIG_VIDEO_PMS is not set
# CONFIG_VIDEO_BWQCAM is not set
CONFIG_VIDEO_CQCAM=m
# CONFIG_VIDEO_CPIA is not set
# CONFIG_VIDEO_CPIA2 is not set
# CONFIG_VIDEO_SAA5246A is not set
# CONFIG_VIDEO_SAA5249 is not set
# CONFIG_TUNER_3036 is not set
# CONFIG_VIDEO_STRADIS is not set
# CONFIG_VIDEO_ZORAN is not set
# CONFIG_VIDEO_SAA7134 is not set
# CONFIG_VIDEO_MXB is not set
# CONFIG_VIDEO_DPC is not set
# CONFIG_VIDEO_HEXIUM_ORION is not set
# CONFIG_VIDEO_HEXIUM_GEMINI is not set
# CONFIG_VIDEO_CX88 is not set
#
# V4L USB devices
#
# CONFIG_VIDEO_PVRUSB2 is not set
# CONFIG_VIDEO_EM28XX is not set
# CONFIG_USB_VICAM is not set
# CONFIG_USB_IBMCAM is not set
# CONFIG_USB_KONICAWC is not set
# CONFIG_USB_QUICKCAM_MESSENGER is not set
# CONFIG_USB_ET61X251 is not set
# CONFIG_VIDEO_OVCAMCHIP is not set
# CONFIG_USB_W9968CF is not set
# CONFIG_USB_OV511 is not set
# CONFIG_USB_SE401 is not set
# CONFIG_USB_SN9C102 is not set
# CONFIG_USB_STV680 is not set
# CONFIG_USB_ZC0301 is not set
# CONFIG_USB_PWC is not set
#
# Radio Adapters
#
# CONFIG_RADIO_CADET is not set
# CONFIG_RADIO_RTRACK is not set
# CONFIG_RADIO_RTRACK2 is not set
# CONFIG_RADIO_AZTECH is not set
# CONFIG_RADIO_GEMTEK is not set
# CONFIG_RADIO_GEMTEK_PCI is not set
# CONFIG_RADIO_MAXIRADIO is not set
# CONFIG_RADIO_MAESTRO is not set
# CONFIG_RADIO_SF16FMI is not set
# CONFIG_RADIO_SF16FMR2 is not set
# CONFIG_RADIO_TERRATEC is not set
# CONFIG_RADIO_TRUST is not set
# CONFIG_RADIO_TYPHOON is not set
# CONFIG_RADIO_ZOLTRIX is not set
# CONFIG_USB_DSBR is not set
#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
CONFIG_VIDEO_BUF=m
# CONFIG_USB_DABUSB is not set
#
# Graphics support
#
CONFIG_FIRMWARE_EDID=y
CONFIG_FB=m
# CONFIG_FB_DDC is not set
CONFIG_FB_CFB_FILLRECT=m
CONFIG_FB_CFB_COPYAREA=m
CONFIG_FB_CFB_IMAGEBLIT=m
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_VGA16 is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
CONFIG_FB_NVIDIA=m
CONFIG_FB_NVIDIA_I2C=y
# CONFIG_FB_RIVA is not set
# CONFIG_FB_I810 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_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_CYBLA is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
CONFIG_VIDEO_SELECT=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=m
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
#
# Logo configuration
#
# CONFIG_LOGO is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
# Sound
#
CONFIG_SOUND=m
#
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_PCM_OSS_PLUGINS=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y
# CONFIG_SND_DYNAMIC_MINORS is not set
CONFIG_SND_SUPPORT_OLD_API=y
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
#
# Generic devices
#
CONFIG_SND_MPU401_UART=m
CONFIG_SND_AC97_CODEC=m
CONFIG_SND_AC97_BUS=m
CONFIG_SND_DUMMY=m
CONFIG_SND_VIRMIDI=m
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_MTS64 is not set
CONFIG_SND_SERIAL_U16550=m
CONFIG_SND_MPU401=m
#
# ISA devices
#
# CONFIG_SND_ADLIB is not set
# CONFIG_SND_AD1816A is not set
# CONFIG_SND_AD1848 is not set
# CONFIG_SND_ALS100 is not set
# CONFIG_SND_AZT2320 is not set
# CONFIG_SND_CMI8330 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
# CONFIG_SND_DT019X is not set
# CONFIG_SND_ES968 is not set
# CONFIG_SND_ES1688 is not set
# CONFIG_SND_ES18XX is not set
# CONFIG_SND_GUSCLASSIC is not set
# CONFIG_SND_GUSEXTREME is not set
# CONFIG_SND_GUSMAX is not set
# CONFIG_SND_INTERWAVE is not set
# CONFIG_SND_INTERWAVE_STB is not set
# CONFIG_SND_OPL3SA2 is not set
# CONFIG_SND_OPTI92X_AD1848 is not set
# CONFIG_SND_OPTI92X_CS4231 is not set
# CONFIG_SND_OPTI93X is not set
# CONFIG_SND_MIRO is not set
# CONFIG_SND_SB8 is not set
# CONFIG_SND_SB16 is not set
# CONFIG_SND_SBAWE is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_SSCAPE is not set
# CONFIG_SND_WAVEFRONT is not set
#
# PCI devices
#
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS5535AUDIO is not set
# CONFIG_SND_DARLA20 is not set
# CONFIG_SND_GINA20 is not set
# CONFIG_SND_LAYLA20 is not set
# CONFIG_SND_DARLA24 is not set
# CONFIG_SND_GINA24 is not set
# CONFIG_SND_LAYLA24 is not set
# CONFIG_SND_MONA is not set
# CONFIG_SND_MIA is not set
# CONFIG_SND_ECHO3G is not set
# CONFIG_SND_INDIGO is not set
# CONFIG_SND_INDIGOIO is not set
# CONFIG_SND_INDIGODJ is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_HDA_INTEL is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
# CONFIG_SND_INTEL8X0 is not set
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_PCXHR is not set
# CONFIG_SND_RIPTIDE is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_TRIDENT is not set
CONFIG_SND_VIA82XX=m
CONFIG_SND_VIA82XX_MODEM=m
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI is not set
CONFIG_SND_AC97_POWER_SAVE=y
#
# USB devices
#
# CONFIG_SND_USB_AUDIO is not set
# CONFIG_SND_USB_USX2Y is not set
#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set
#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
CONFIG_USB_DEBUG=y
#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
CONFIG_USB_BANDWIDTH=y
CONFIG_USB_DYNAMIC_MINORS=y
# CONFIG_USB_SUSPEND is not set
# CONFIG_USB_OTG is not set
#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_EHCI_SPLIT_ISO=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
CONFIG_USB_UHCI_HCD=m
# CONFIG_USB_SL811_HCD is not set
#
# USB Device Class drivers
#
CONFIG_USB_ACM=m
CONFIG_USB_PRINTER=m
#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#
#
# may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=m
CONFIG_USB_STORAGE_DEBUG=y
CONFIG_USB_STORAGE_DATAFAB=y
CONFIG_USB_STORAGE_FREECOM=y
CONFIG_USB_STORAGE_ISD200=y
CONFIG_USB_STORAGE_DPCM=y
CONFIG_USB_STORAGE_USBAT=y
CONFIG_USB_STORAGE_SDDR09=y
CONFIG_USB_STORAGE_SDDR55=y
CONFIG_USB_STORAGE_JUMPSHOT=y
CONFIG_USB_STORAGE_ALAUDA=y
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_LIBUSUAL is not set
#
# USB Input Devices
#
CONFIG_USB_HID=m
CONFIG_USB_HIDINPUT=y
# CONFIG_USB_HIDINPUT_POWERBOOK is not set
# CONFIG_HID_FF is not set
CONFIG_USB_HIDDEV=y
#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_ACECAD is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_TOUCHSCREEN is not set
# CONFIG_USB_YEALINK is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set
# CONFIG_USB_ATI_REMOTE2 is not set
# CONFIG_USB_KEYSPAN_REMOTE is not set
# CONFIG_USB_APPLETOUCH is not set
#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
CONFIG_USB_USBNET=m
CONFIG_USB_NET_CDCETHER=m
# CONFIG_USB_NET_GL620A is not set
CONFIG_USB_NET_NET1080=m
# CONFIG_USB_NET_PLUSB is not set
# CONFIG_USB_NET_MCS7830 is not set
# CONFIG_USB_NET_RNDIS_HOST is not set
CONFIG_USB_NET_CDC_SUBSET=m
# CONFIG_USB_ALI_M5632 is not set
# CONFIG_USB_AN2720 is not set
CONFIG_USB_BELKIN=y
CONFIG_USB_ARMLINUX=y
# CONFIG_USB_EPSON2888 is not set
CONFIG_USB_NET_ZAURUS=m
CONFIG_USB_MON=y
#
# USB port drivers
#
# CONFIG_USB_USS720 is not set
#
# USB Serial Converter support
#
CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_GENERIC=y
CONFIG_USB_SERIAL_AIRCABLE=m
# CONFIG_USB_SERIAL_AIRPRIME is not set
# CONFIG_USB_SERIAL_ARK3116 is not set
# CONFIG_USB_SERIAL_BELKIN is not set
# CONFIG_USB_SERIAL_WHITEHEAT is not set
# CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set
# CONFIG_USB_SERIAL_CP2101 is not set
# CONFIG_USB_SERIAL_CYPRESS_M8 is not set
# CONFIG_USB_SERIAL_EMPEG is not set
# CONFIG_USB_SERIAL_FTDI_SIO is not set
# CONFIG_USB_SERIAL_FUNSOFT is not set
# CONFIG_USB_SERIAL_VISOR is not set
# CONFIG_USB_SERIAL_IPAQ is not set
# CONFIG_USB_SERIAL_IR is not set
# CONFIG_USB_SERIAL_EDGEPORT is not set
# CONFIG_USB_SERIAL_EDGEPORT_TI is not set
# CONFIG_USB_SERIAL_GARMIN is not set
# CONFIG_USB_SERIAL_IPW is not set
# CONFIG_USB_SERIAL_KEYSPAN_PDA is not set
# CONFIG_USB_SERIAL_KEYSPAN is not set
# CONFIG_USB_SERIAL_KLSI is not set
# CONFIG_USB_SERIAL_KOBIL_SCT is not set
# CONFIG_USB_SERIAL_MCT_U232 is not set
# CONFIG_USB_SERIAL_MOS7720 is not set
# CONFIG_USB_SERIAL_MOS7840 is not set
# CONFIG_USB_SERIAL_NAVMAN is not set
# CONFIG_USB_SERIAL_PL2303 is not set
# CONFIG_USB_SERIAL_HP4X is not set
# CONFIG_USB_SERIAL_SAFE is not set
# CONFIG_USB_SERIAL_SIERRAWIRELESS is not set
# CONFIG_USB_SERIAL_TI is not set
# CONFIG_USB_SERIAL_CYBERJACK is not set
# CONFIG_USB_SERIAL_XIRCOM is not set
CONFIG_USB_SERIAL_OPTION=m
# CONFIG_USB_SERIAL_OMNINET 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_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGET is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_TEST is not set
#
# USB DSL modem support
#
#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
#
# MMC/SD Card support
#
CONFIG_MMC=m
# CONFIG_MMC_DEBUG is not set
CONFIG_MMC_BLOCK=m
CONFIG_MMC_SDHCI=m
CONFIG_MMC_WBSD=m
CONFIG_MMC_TIFM_SD=m
#
# LED devices
#
# CONFIG_NEW_LEDS is not set
#
# LED drivers
#
#
# LED Triggers
#
#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set
#
# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
#
CONFIG_EDAC=y
#
# Reporting subsystems
#
# CONFIG_EDAC_DEBUG is not set
CONFIG_EDAC_MM_EDAC=y
# CONFIG_EDAC_AMD76X is not set
# CONFIG_EDAC_E7XXX is not set
# CONFIG_EDAC_E752X is not set
# CONFIG_EDAC_I82875P is not set
# CONFIG_EDAC_I82860 is not set
# CONFIG_EDAC_R82600 is not set
CONFIG_EDAC_POLL=y
#
# Real Time Clock
#
# CONFIG_RTC_CLASS is not set
#
# DMA Engine support
#
CONFIG_DMA_ENGINE=y
#
# DMA Clients
#
CONFIG_NET_DMA=y
#
# DMA Devices
#
CONFIG_INTEL_IOATDMA=y
#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
# CONFIG_EXT3_FS_XATTR is not set
# CONFIG_EXT4DEV_FS is not set
CONFIG_JBD=y
CONFIG_JBD_DEBUG=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
CONFIG_MINIX_FS=m
# CONFIG_ROMFS_FS is not set
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_QUOTA=y
# CONFIG_QFMT_V1 is not set
# CONFIG_QFMT_V2 is not set
CONFIG_QUOTACTL=y
CONFIG_DNOTIFY=y
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m
# CONFIG_FUSE_FS is not set
#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_NTFS_FS=y
CONFIG_NTFS_DEBUG=y
CONFIG_NTFS_RW=y
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
CONFIG_CONFIGFS_FS=y
#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
#
# Network File Systems
#
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
CONFIG_NFS_V4=y
# CONFIG_NFS_DIRECTIO is not set
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V3_ACL is not set
CONFIG_NFSD_V4=y
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
CONFIG_RPCSEC_GSS_KRB5=y
CONFIG_RPCSEC_GSS_SPKM3=m
CONFIG_SMB_FS=m
CONFIG_SMB_NLS_DEFAULT=y
CONFIG_SMB_NLS_REMOTE="cp850"
CONFIG_CIFS=m
CONFIG_CIFS_STATS=y
# CONFIG_CIFS_STATS2 is not set
CONFIG_CIFS_WEAK_PW_HASH=y
CONFIG_CIFS_XATTR=y
CONFIG_CIFS_POSIX=y
# CONFIG_CIFS_DEBUG2 is not set
CONFIG_CIFS_EXPERIMENTAL=y
# CONFIG_CIFS_UPCALL is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set
#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
CONFIG_LDM_PARTITION=y
CONFIG_LDM_DEBUG=y
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso-8859-1"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=y
CONFIG_NLS_CODEPAGE_852=y
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=m
CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_ISO8859_2=y
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=y
#
# Distributed Lock Manager
#
CONFIG_DLM=m
# CONFIG_DLM_DEBUG is not set
#
# Instrumentation Support
#
# CONFIG_PROFILING is not set
# CONFIG_KPROBES is not set
#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_PRINTK_TIME=y
# CONFIG_ENABLE_MUST_CHECK is not set
CONFIG_MAGIC_SYSRQ=y
CONFIG_UNUSED_SYMBOLS=y
CONFIG_DEBUG_KERNEL=y
CONFIG_LOG_BUF_SHIFT=17
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
CONFIG_DEBUG_PREEMPT=y
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
CONFIG_DEBUG_MUTEXES=y
# CONFIG_DEBUG_RWSEMS is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
CONFIG_DEBUG_FS=y
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_LIST is not set
CONFIG_FRAME_POINTER=y
CONFIG_UNWIND_INFO=y
CONFIG_STACK_UNWIND=y
CONFIG_FORCED_INLINING=y
# CONFIG_HEADERS_CHECK is not set
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_DEBUG_RODATA=y
# CONFIG_4KSTACKS is not set
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
CONFIG_DOUBLEFAULT=y
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_WP512=m
CONFIG_CRYPTO_TGR192=m
CONFIG_CRYPTO_ECB=m
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_DES=y
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_TWOFISH_COMMON=m
CONFIG_CRYPTO_TWOFISH_586=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_AES_586=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_CRC32C=m
CONFIG_CRYPTO_TEST=m
#
# Hardware crypto devices
#
CONFIG_CRYPTO_DEV_PADLOCK=y
CONFIG_CRYPTO_DEV_PADLOCK_AES=y
CONFIG_CRYPTO_DEV_PADLOCK_SHA=m
#
# Library routines
#
CONFIG_CRC_CCITT=m
CONFIG_CRC16=m
CONFIG_CRC32=m
CONFIG_LIBCRC32C=m
CONFIG_AUDIT_GENERIC=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=y
CONFIG_TEXTSEARCH_BM=y
CONFIG_TEXTSEARCH_FSM=y
CONFIG_PLIST=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_KTIME_SCALAR=y
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH] !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB
2006-10-25 20:13 ` Linux 2.6.19-rc3: !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB Athanasius
@ 2006-10-25 22:17 ` Randy Dunlap
2006-10-25 22:27 ` David Brownell
0 siblings, 1 reply; 139+ messages in thread
From: Randy Dunlap @ 2006-10-25 22:17 UTC (permalink / raw)
To: Athanasius, toralf.foerster, gregkh, akpm, netdev, lud
Cc: Linus Torvalds, linux-kernel, David Brownell, Roman Zippel
From: Randy Dunlap <randy.dunlap@oracle.com>
USB network drivers that use mii_*() interfaces should
cause those interfaces to be built. Or depend on them,
but this is what all drivers/net/ drivers do.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
drivers/usb/net/Kconfig | 3 +++
1 file changed, 3 insertions(+)
--- linux-2619-rc3-pv.orig/drivers/usb/net/Kconfig
+++ linux-2619-rc3-pv/drivers/usb/net/Kconfig
@@ -84,6 +84,7 @@ config USB_PEGASUS
config USB_RTL8150
tristate "USB RTL8150 based ethernet device support (EXPERIMENTAL)"
depends on EXPERIMENTAL
+ select MII
help
Say Y here if you have RTL8150 based usb-ethernet adapter.
Send me <petkan@users.sourceforge.net> any comments you may have.
@@ -94,6 +95,7 @@ config USB_RTL8150
config USB_USBNET
tristate "Multi-purpose USB Networking Framework"
+ select MII
---help---
This driver supports several kinds of network links over USB,
with "minidrivers" built around a common network driver core
@@ -210,6 +212,7 @@ config USB_NET_PLUSB
config USB_NET_MCS7830
tristate "MosChip MCS7830 based Ethernet adapters"
depends on USB_USBNET
+ select MII
help
Choose this option if you're using a 10/100 Ethernet USB2
adapter based on the MosChip 7830 controller. This includes
---
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [PATCH] !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB
2006-10-25 22:17 ` [PATCH] " Randy Dunlap
@ 2006-10-25 22:27 ` David Brownell
2006-10-25 23:58 ` [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled Randy Dunlap
2006-10-25 23:59 ` [PATCH 1/2] !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB Randy Dunlap
0 siblings, 2 replies; 139+ messages in thread
From: David Brownell @ 2006-10-25 22:27 UTC (permalink / raw)
To: toralf.foerster, randy.dunlap, netdev, linux-usb-devel, link,
greg, akpm
Cc: zippel, torvalds, linux-kernel, dbrownell
> @@ -94,6 +95,7 @@ config USB_RTL8150
>
> config USB_USBNET
> tristate "Multi-purpose USB Networking Framework"
> + select MII
> ---help---
> This driver supports several kinds of network links over USB,
> with "minidrivers" built around a common network driver core
The other parts are right, this isn't.
Instead, "usbnet.c" should #ifdef the relevant ethtool hooks
according to CONFIG_MII ... since it's completely legit to
use usbnet with peripherals that don't need MII.
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled
2006-10-25 22:27 ` David Brownell
@ 2006-10-25 23:58 ` Randy Dunlap
2006-10-26 2:22 ` David Brownell
` (2 more replies)
2006-10-25 23:59 ` [PATCH 1/2] !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB Randy Dunlap
1 sibling, 3 replies; 139+ messages in thread
From: Randy Dunlap @ 2006-10-25 23:58 UTC (permalink / raw)
To: David Brownell
Cc: toralf.foerster, netdev, linux-usb-devel, link, greg, akpm,
zippel, torvalds, linux-kernel, dbrownell
On Wed, 25 Oct 2006 15:27:09 -0700 David Brownell wrote:
> Instead, "usbnet.c" should #ifdef the relevant ethtool hooks
> according to CONFIG_MII ... since it's completely legit to
> use usbnet with peripherals that don't need MII.
---
From: Randy Dunlap <randy.dunlap@oracle.com>
usbnet driver should use mii_*() interfaces if they are available
in the kernel (config enabled) but usbnet does not require or depend
on these interfaces.
Build tested with CONFIG_MII=y, m, n.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
drivers/usb/net/usbnet.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
--- linux-2619-rc3-pv.orig/drivers/usb/net/usbnet.c
+++ linux-2619-rc3-pv/drivers/usb/net/usbnet.c
@@ -47,6 +47,12 @@
#define DRIVER_VERSION "22-Aug-2005"
+#if defined(CONFIG_MII) || defined(CONFIG_MII_MODULE)
+#define HAVE_MII 1
+#else
+#define HAVE_MII 0
+#endif
+
/*-------------------------------------------------------------------------*/
@@ -676,7 +682,10 @@ int usbnet_get_settings (struct net_devi
if (!dev->mii.mdio_read)
return -EOPNOTSUPP;
+#if HAVE_MII
return mii_ethtool_gset(&dev->mii, cmd);
+#endif
+ return -EOPNOTSUPP;
}
EXPORT_SYMBOL_GPL(usbnet_get_settings);
@@ -688,7 +697,11 @@ int usbnet_set_settings (struct net_devi
if (!dev->mii.mdio_write)
return -EOPNOTSUPP;
+#if HAVE_MII
retval = mii_ethtool_sset(&dev->mii, cmd);
+#else
+ retval = -EOPNOTSUPP;
+#endif
/* link speed/duplex might have changed */
if (dev->driver_info->link_reset)
@@ -721,9 +734,11 @@ u32 usbnet_get_link (struct net_device *
if (dev->driver_info->check_connect)
return dev->driver_info->check_connect (dev) == 0;
+#if HAVE_MII
/* if the device has mii operations, use those */
if (dev->mii.mdio_read)
return mii_link_ok(&dev->mii);
+#endif
/* Otherwise, say we're up (to avoid breaking scripts) */
return 1;
@@ -753,7 +768,10 @@ int usbnet_nway_reset(struct net_device
if (!dev->mii.mdio_write)
return -EOPNOTSUPP;
+#if HAVE_MII
return mii_nway_restart(&dev->mii);
+#endif
+ return -EOPNOTSUPP;
}
EXPORT_SYMBOL_GPL(usbnet_nway_reset);
^ permalink raw reply [flat|nested] 139+ messages in thread
* [PATCH 1/2] !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB
2006-10-25 22:27 ` David Brownell
2006-10-25 23:58 ` [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled Randy Dunlap
@ 2006-10-25 23:59 ` Randy Dunlap
2006-10-26 2:24 ` David Brownell
1 sibling, 1 reply; 139+ messages in thread
From: Randy Dunlap @ 2006-10-25 23:59 UTC (permalink / raw)
To: David Brownell
Cc: toralf.foerster, netdev, linux-usb-devel, link, greg, akpm,
zippel, torvalds, linux-kernel, dbrownell
On Wed, 25 Oct 2006 15:27:09 -0700 David Brownell wrote:
> The other parts are right, this isn't.
>
> Instead, "usbnet.c" should #ifdef the relevant ethtool hooks
> according to CONFIG_MII ... since it's completely legit to
> use usbnet with peripherals that don't need MII.
Ugh. OK. How's this? (2 patches)
(oh, OP mentioned CONFIG_PHYLIB but it's actually CONFIG_MII AFAIK)
---
From: Randy Dunlap <randy.dunlap@oracle.com>
pegasus and mcs7830 drivers use MII interfaces and should
select MII in the same way that drivers/net/ drivers do.
However, the MII config symbol should not be in the 10/100 Ethernet
menu, so that other drivers can use (enable) it or so that users
can enable it without needing to enable 10/100 Ethernet.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
drivers/net/Kconfig | 15 +++++++--------
drivers/usb/net/Kconfig | 2 ++
2 files changed, 9 insertions(+), 8 deletions(-)
--- linux-2619-rc3-pv.orig/drivers/usb/net/Kconfig
+++ linux-2619-rc3-pv/drivers/usb/net/Kconfig
@@ -84,6 +84,7 @@ config USB_PEGASUS
config USB_RTL8150
tristate "USB RTL8150 based ethernet device support (EXPERIMENTAL)"
depends on EXPERIMENTAL
+ select MII
help
Say Y here if you have RTL8150 based usb-ethernet adapter.
Send me <petkan@users.sourceforge.net> any comments you may have.
@@ -210,6 +211,7 @@ config USB_NET_PLUSB
config USB_NET_MCS7830
tristate "MosChip MCS7830 based Ethernet adapters"
depends on USB_USBNET
+ select MII
help
Choose this option if you're using a 10/100 Ethernet USB2
adapter based on the MosChip 7830 controller. This includes
--- linux-2619-rc3-pv.orig/drivers/net/Kconfig
+++ linux-2619-rc3-pv/drivers/net/Kconfig
@@ -145,6 +145,13 @@ config NET_SB1000
source "drivers/net/arcnet/Kconfig"
+config MII
+ tristate "Generic Media Independent Interface device support"
+ help
+ Most ethernet controllers have MII transceiver either as an external
+ or internal device. It is safe to say Y or M here even if your
+ ethernet card lacks MII.
+
source "drivers/net/phy/Kconfig"
#
@@ -180,14 +187,6 @@ config NET_ETHERNET
kernel: saying N will just cause the configurator to skip all
the questions about Ethernet network cards. If unsure, say N.
-config MII
- tristate "Generic Media Independent Interface device support"
- depends on NET_ETHERNET
- help
- Most ethernet controllers have MII transceiver either as an external
- or internal device. It is safe to say Y or M here even if your
- ethernet card lack MII.
-
source "drivers/net/arm/Kconfig"
config MACE
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled
2006-10-25 23:58 ` [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled Randy Dunlap
@ 2006-10-26 2:22 ` David Brownell
2006-11-02 7:15 ` Greg KH
2006-10-26 15:46 ` [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled Adrian Bunk
2006-10-28 11:21 ` Christoph Hellwig
2 siblings, 1 reply; 139+ messages in thread
From: David Brownell @ 2006-10-26 2:22 UTC (permalink / raw)
To: Randy Dunlap
Cc: toralf.foerster, netdev, linux-usb-devel, link, greg, akpm,
zippel, torvalds, linux-kernel
On Wednesday 25 October 2006 4:58 pm, Randy Dunlap wrote:
> On Wed, 25 Oct 2006 15:27:09 -0700 David Brownell wrote:
>
> > Instead, "usbnet.c" should #ifdef the relevant ethtool hooks
> > according to CONFIG_MII ... since it's completely legit to
> > use usbnet with peripherals that don't need MII.
I had in mind something simpler -- #ifdeffing the entire functions,
as in this patch. It looks more complicated than it is, because
"diff" gets confused by moving two functions earlier in the file.
(Thanks for starting this, Randy ... these two patches should be merged
before RC4 ships.)
- Dave
The usbnet infrastructure must not reference MII symbols unless they're
provided in the kernel being built. This extends also to the ethtool
hooks that reference those symbols.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Index: g26/drivers/usb/net/usbnet.c
===================================================================
--- g26.orig/drivers/usb/net/usbnet.c 2006-10-24 18:29:28.000000000 -0700
+++ g26/drivers/usb/net/usbnet.c 2006-10-25 19:07:16.000000000 -0700
@@ -669,6 +669,9 @@ done:
* they'll probably want to use this base set.
*/
+#if defined(CONFIG_MII) || defined(CONFIG_MII_MODULE)
+#define HAVE_MII
+
int usbnet_get_settings (struct net_device *net, struct ethtool_cmd *cmd)
{
struct usbnet *dev = netdev_priv(net);
@@ -699,20 +702,6 @@ int usbnet_set_settings (struct net_devi
}
EXPORT_SYMBOL_GPL(usbnet_set_settings);
-
-void usbnet_get_drvinfo (struct net_device *net, struct ethtool_drvinfo *info)
-{
- struct usbnet *dev = netdev_priv(net);
-
- /* REVISIT don't always return "usbnet" */
- strncpy (info->driver, driver_name, sizeof info->driver);
- strncpy (info->version, DRIVER_VERSION, sizeof info->version);
- strncpy (info->fw_version, dev->driver_info->description,
- sizeof info->fw_version);
- usb_make_path (dev->udev, info->bus_info, sizeof info->bus_info);
-}
-EXPORT_SYMBOL_GPL(usbnet_get_drvinfo);
-
u32 usbnet_get_link (struct net_device *net)
{
struct usbnet *dev = netdev_priv(net);
@@ -730,40 +719,57 @@ u32 usbnet_get_link (struct net_device *
}
EXPORT_SYMBOL_GPL(usbnet_get_link);
-u32 usbnet_get_msglevel (struct net_device *net)
+int usbnet_nway_reset(struct net_device *net)
{
struct usbnet *dev = netdev_priv(net);
- return dev->msg_enable;
+ if (!dev->mii.mdio_write)
+ return -EOPNOTSUPP;
+
+ return mii_nway_restart(&dev->mii);
}
-EXPORT_SYMBOL_GPL(usbnet_get_msglevel);
+EXPORT_SYMBOL_GPL(usbnet_nway_reset);
-void usbnet_set_msglevel (struct net_device *net, u32 level)
+#endif /* HAVE_MII */
+
+void usbnet_get_drvinfo (struct net_device *net, struct ethtool_drvinfo *info)
{
struct usbnet *dev = netdev_priv(net);
- dev->msg_enable = level;
+ /* REVISIT don't always return "usbnet" */
+ strncpy (info->driver, driver_name, sizeof info->driver);
+ strncpy (info->version, DRIVER_VERSION, sizeof info->version);
+ strncpy (info->fw_version, dev->driver_info->description,
+ sizeof info->fw_version);
+ usb_make_path (dev->udev, info->bus_info, sizeof info->bus_info);
}
-EXPORT_SYMBOL_GPL(usbnet_set_msglevel);
+EXPORT_SYMBOL_GPL(usbnet_get_drvinfo);
-int usbnet_nway_reset(struct net_device *net)
+u32 usbnet_get_msglevel (struct net_device *net)
{
struct usbnet *dev = netdev_priv(net);
- if (!dev->mii.mdio_write)
- return -EOPNOTSUPP;
+ return dev->msg_enable;
+}
+EXPORT_SYMBOL_GPL(usbnet_get_msglevel);
- return mii_nway_restart(&dev->mii);
+void usbnet_set_msglevel (struct net_device *net, u32 level)
+{
+ struct usbnet *dev = netdev_priv(net);
+
+ dev->msg_enable = level;
}
-EXPORT_SYMBOL_GPL(usbnet_nway_reset);
+EXPORT_SYMBOL_GPL(usbnet_set_msglevel);
/* drivers may override default ethtool_ops in their bind() routine */
static struct ethtool_ops usbnet_ethtool_ops = {
+#ifdef HAVE_MII
.get_settings = usbnet_get_settings,
.set_settings = usbnet_set_settings,
- .get_drvinfo = usbnet_get_drvinfo,
.get_link = usbnet_get_link,
.nway_reset = usbnet_nway_reset,
+#endif
+ .get_drvinfo = usbnet_get_drvinfo,
.get_msglevel = usbnet_get_msglevel,
.set_msglevel = usbnet_set_msglevel,
};
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [PATCH 1/2] !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB
2006-10-25 23:59 ` [PATCH 1/2] !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB Randy Dunlap
@ 2006-10-26 2:24 ` David Brownell
2006-10-26 5:05 ` Randy.Dunlap
0 siblings, 1 reply; 139+ messages in thread
From: David Brownell @ 2006-10-26 2:24 UTC (permalink / raw)
To: Randy Dunlap
Cc: toralf.foerster, netdev, linux-usb-devel, link, greg, akpm,
zippel, torvalds, linux-kernel, dbrownell
On Wednesday 25 October 2006 4:59 pm, Randy Dunlap wrote:
> On Wed, 25 Oct 2006 15:27:09 -0700 David Brownell wrote:
>
> > The other parts are right, this isn't.
> >
> > Instead, "usbnet.c" should #ifdef the relevant ethtool hooks
> > according to CONFIG_MII ... since it's completely legit to
> > use usbnet with peripherals that don't need MII.
>
> Ugh. OK. How's this? (2 patches)
Looks about right, but ...
> However, the MII config symbol should not be in the 10/100 Ethernet
> menu, so that other drivers can use (enable) it or so that users
> can enable it without needing to enable 10/100 Ethernet.
... MII should still depend on ETHERNET, right?
Just not limited to 10/100 Ethernet.
> --- linux-2619-rc3-pv.orig/drivers/net/Kconfig
> +++ linux-2619-rc3-pv/drivers/net/Kconfig
> @@ -145,6 +145,13 @@ config NET_SB1000
>
> source "drivers/net/arcnet/Kconfig"
>
> +config MII
> + tristate "Generic Media Independent Interface device support"
> + help
> + Most ethernet controllers have MII transceiver either as an external
> + or internal device. It is safe to say Y or M here even if your
> + ethernet card lacks MII.
> +
> source "drivers/net/phy/Kconfig"
>
> #
> @@ -180,14 +187,6 @@ config NET_ETHERNET
> kernel: saying N will just cause the configurator to skip all
> the questions about Ethernet network cards. If unsure, say N.
>
> -config MII
> - tristate "Generic Media Independent Interface device support"
> - depends on NET_ETHERNET
> - help
> - Most ethernet controllers have MII transceiver either as an external
> - or internal device. It is safe to say Y or M here even if your
> - ethernet card lack MII.
> -
> source "drivers/net/arm/Kconfig"
>
> config MACE
>
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [PATCH 1/2] !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB
2006-10-26 2:24 ` David Brownell
@ 2006-10-26 5:05 ` Randy.Dunlap
2006-10-26 5:24 ` David Brownell
0 siblings, 1 reply; 139+ messages in thread
From: Randy.Dunlap @ 2006-10-26 5:05 UTC (permalink / raw)
To: David Brownell
Cc: toralf.foerster, netdev, linux-usb-devel, link, greg, akpm,
zippel, torvalds, linux-kernel, dbrownell
David Brownell wrote:
> On Wednesday 25 October 2006 4:59 pm, Randy Dunlap wrote:
>> On Wed, 25 Oct 2006 15:27:09 -0700 David Brownell wrote:
>>
>>> The other parts are right, this isn't.
>>>
>>> Instead, "usbnet.c" should #ifdef the relevant ethtool hooks
>>> according to CONFIG_MII ... since it's completely legit to
>>> use usbnet with peripherals that don't need MII.
>> Ugh. OK. How's this? (2 patches)
>
> Looks about right, but ...
>
>
>> However, the MII config symbol should not be in the 10/100 Ethernet
>> menu, so that other drivers can use (enable) it or so that users
>> can enable it without needing to enable 10/100 Ethernet.
>
> ... MII should still depend on ETHERNET, right?
> Just not limited to 10/100 Ethernet.
There is no such config symbol. NET_ETHERNET means 10/100 ethernet.
Gigabit ethernet doesn't use the ETHERNET symbol (and doesn't use
this flavor of MII IIRC).
And all of this config space is surrounded by:
# All the following symbols are dependent on NETDEVICES - do not repeat
# that for each of the symbols.
if NETDEVICES
so it is actually
config MII
depends on NETDEVICES
What do you suggest?
>> --- linux-2619-rc3-pv.orig/drivers/net/Kconfig
>> +++ linux-2619-rc3-pv/drivers/net/Kconfig
>> @@ -145,6 +145,13 @@ config NET_SB1000
>>
>> source "drivers/net/arcnet/Kconfig"
>>
>> +config MII
>> + tristate "Generic Media Independent Interface device support"
>> + help
>> + Most ethernet controllers have MII transceiver either as an external
>> + or internal device. It is safe to say Y or M here even if your
>> + ethernet card lacks MII.
>> +
>> source "drivers/net/phy/Kconfig"
>>
>> #
>> @@ -180,14 +187,6 @@ config NET_ETHERNET
>> kernel: saying N will just cause the configurator to skip all
>> the questions about Ethernet network cards. If unsure, say N.
>>
>> -config MII
>> - tristate "Generic Media Independent Interface device support"
>> - depends on NET_ETHERNET
>> - help
>> - Most ethernet controllers have MII transceiver either as an external
>> - or internal device. It is safe to say Y or M here even if your
>> - ethernet card lack MII.
>> -
>> source "drivers/net/arm/Kconfig"
>>
>> config MACE
>>
--
~Randy
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [PATCH 1/2] !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB
2006-10-26 5:05 ` Randy.Dunlap
@ 2006-10-26 5:24 ` David Brownell
0 siblings, 0 replies; 139+ messages in thread
From: David Brownell @ 2006-10-26 5:24 UTC (permalink / raw)
To: Randy.Dunlap
Cc: toralf.foerster, netdev, linux-usb-devel, link, greg, akpm,
zippel, torvalds, linux-kernel, dbrownell
On Wednesday 25 October 2006 10:05 pm, Randy.Dunlap wrote:
> >
> > ... MII should still depend on ETHERNET, right?
> > Just not limited to 10/100 Ethernet.
>
> There is no such config symbol. NET_ETHERNET means 10/100 ethernet.
> Gigabit ethernet doesn't use the ETHERNET symbol (and doesn't use
> this flavor of MII IIRC).
Ah, you're right -- sorry. Only Kconfig and net/ipv4/arp.c even
look for that config symbol.
- Dave
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Linux 2.6.19-rc3
2006-10-25 16:25 ` Auke Kok
@ 2006-10-26 7:20 ` Jean Delvare
0 siblings, 0 replies; 139+ messages in thread
From: Jean Delvare @ 2006-10-26 7:20 UTC (permalink / raw)
To: Auke Kok
Cc: Damien Wyart, Jeff Garzik, Linux Kernel Mailing List,
Linus Torvalds, Adrian Bunk
Hi Auke,
On Wed, 25 Oct 2006 09:25:14 -0700, Auke Kok wrote:
> Damien Wyart wrote:
> > > > Auke Kok (1):
> > > > e100: fix reboot -f with netconsole enabled
> >
> > * Jean Delvare <khali@linux-fr.org> [2006-10-25 13:25]: This one breaks
> > > power-off and reboot on my laptop (thanks to git bisect for isolating
> > > it). The shutdown freezes after "Shutdown: hda" or "Rebooting".
> > > SysRq-p says the CPU is idle. If you need additional information on my
> > > config or want me to do more tests, just ask.
> >
> > This has already been discussed, a fix has been posted (see recent
> > netdev messages) and should be pulled soon into mainline (I guess).
>
> for those interested, here's the fix (which is already pushed to jgarzik)
>
> diff --git a/drivers/net/e100.c b/drivers/net/e100.c
> index d4a2572..815eb29 100644
> --- a/drivers/net/e100.c
> +++ b/drivers/net/e100.c
> @@ -2719,7 +2719,10 @@ static int e100_suspend(struct pci_dev *
> struct net_device *netdev = pci_get_drvdata(pdev);
> struct nic *nic = netdev_priv(netdev);
>
> - netif_poll_disable(nic->netdev);
> +#ifdef CONFIG_E100_NAPI
> + if (netif_running(netdev))
> + netif_poll_disable(nic->netdev);
> +#endif
> del_timer_sync(&nic->watchdog);
> netif_carrier_off(nic->netdev);
>
> @@ -2763,7 +2766,10 @@ static void e100_shutdown(struct pci_dev
> struct net_device *netdev = pci_get_drvdata(pdev);
> struct nic *nic = netdev_priv(netdev);
>
> - netif_poll_disable(nic->netdev);
> +#ifdef CONFIG_E100_NAPI
> + if (netif_running(netdev))
> + netif_poll_disable(nic->netdev);
> +#endif
> del_timer_sync(&nic->watchdog);
> netif_carrier_off(nic->netdev);
The patch above had some formating problems, but after fixing that I
could apply it and I confirm it fixes my problem. Thanks!
--
Jean Delvare
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions: confirmations
2006-10-24 21:44 ` 2.6.19-rc3: known unfixed regressions: confirmations teunis
@ 2006-10-26 15:31 ` Adrian Bunk
2006-10-26 15:54 ` teunis
0 siblings, 1 reply; 139+ messages in thread
From: Adrian Bunk @ 2006-10-26 15:31 UTC (permalink / raw)
To: teunis; +Cc: linux-kernel, art, Jiri Slaby, Jeff Dike, pavel, linux-pm
On Tue, Oct 24, 2006 at 02:44:01PM -0700, teunis wrote:
> Adrian Bunk wrote:
> > This email lists some known unfixed regressions in 2.6.19-rc3 compared
> > to 2.6.18.
> ...
>
> I'm not directly testing -rc3 as yet... rc2-mm2 + a few modifications
> works on the equipment I'm testing and as I can't afford more lost time
> due to faults - I'm keeping to that build for the short term.
>
> > Subject : shutdown problem
> > References : http://lkml.org/lkml/2006/10/22/140
> > Submitter : art@usfltd.com
> > teunis@wintersgift.com
> > Jiri Slaby <jirislaby@gmail.com>
> > Status : unknown
>
> repaired by Jeff Dike's patch to fs/proc/array.c
>...
Can you give me a pointer to this patch?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled
2006-10-25 23:58 ` [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled Randy Dunlap
2006-10-26 2:22 ` David Brownell
@ 2006-10-26 15:46 ` Adrian Bunk
2006-10-26 15:51 ` Randy.Dunlap
2006-10-28 11:21 ` Christoph Hellwig
2 siblings, 1 reply; 139+ messages in thread
From: Adrian Bunk @ 2006-10-26 15:46 UTC (permalink / raw)
To: Randy Dunlap
Cc: David Brownell, toralf.foerster, netdev, linux-usb-devel, link,
greg, akpm, zippel, torvalds, linux-kernel, dbrownell,
Arnd Bergmann
On Wed, Oct 25, 2006 at 04:58:58PM -0700, Randy Dunlap wrote:
>...
> Build tested with CONFIG_MII=y, m, n.
>...
> --- linux-2619-rc3-pv.orig/drivers/usb/net/usbnet.c
> +++ linux-2619-rc3-pv/drivers/usb/net/usbnet.c
> @@ -47,6 +47,12 @@
>
> #define DRIVER_VERSION "22-Aug-2005"
>
> +#if defined(CONFIG_MII) || defined(CONFIG_MII_MODULE)
> +#define HAVE_MII 1
> +#else
> +#define HAVE_MII 0
> +#endif
>...
I'm too lame to test it, but I bet this will break with
CONFIG_USB_USBNET=y, CONFIG_MII=m, and you'll actually need
#if defined(CONFIG_MII) || (defined(CONFIG_MII_MODULE) && defined(MODULE))
And then there's the question whether this amount of #ifdef's is
actually worth avoiding the "select MII"...
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled
2006-10-26 15:46 ` [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled Adrian Bunk
@ 2006-10-26 15:51 ` Randy.Dunlap
0 siblings, 0 replies; 139+ messages in thread
From: Randy.Dunlap @ 2006-10-26 15:51 UTC (permalink / raw)
To: Adrian Bunk
Cc: David Brownell, toralf.foerster, netdev, linux-usb-devel, link,
greg, akpm, zippel, torvalds, linux-kernel, dbrownell,
Arnd Bergmann
Adrian Bunk wrote:
> On Wed, Oct 25, 2006 at 04:58:58PM -0700, Randy Dunlap wrote:
>> ...
>> Build tested with CONFIG_MII=y, m, n.
>> ...
>> --- linux-2619-rc3-pv.orig/drivers/usb/net/usbnet.c
>> +++ linux-2619-rc3-pv/drivers/usb/net/usbnet.c
>> @@ -47,6 +47,12 @@
>>
>> #define DRIVER_VERSION "22-Aug-2005"
>>
>> +#if defined(CONFIG_MII) || defined(CONFIG_MII_MODULE)
>> +#define HAVE_MII 1
>> +#else
>> +#define HAVE_MII 0
>> +#endif
>> ...
>
> I'm too lame to test it, but I bet this will break with
> CONFIG_USB_USBNET=y, CONFIG_MII=m, and you'll actually need
>
> #if defined(CONFIG_MII) || (defined(CONFIG_MII_MODULE) && defined(MODULE))
>
> And then there's the question whether this amount of #ifdef's is
> actually worth avoiding the "select MII"...
Thanks, but that's OK, David posted a different patch for it.
--
~Randy
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions: confirmations
2006-10-26 15:31 ` Adrian Bunk
@ 2006-10-26 15:54 ` teunis
0 siblings, 0 replies; 139+ messages in thread
From: teunis @ 2006-10-26 15:54 UTC (permalink / raw)
To: Adrian Bunk
Cc: teunis, linux-kernel, art, Jiri Slaby, Jeff Dike, pavel, linux-pm
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Adrian Bunk wrote:
> On Tue, Oct 24, 2006 at 02:44:01PM -0700, teunis wrote:
>> Adrian Bunk wrote:
>>> This email lists some known unfixed regressions in 2.6.19-rc3 compared
>>> to 2.6.18.
>> ...
>>
>> I'm not directly testing -rc3 as yet... rc2-mm2 + a few modifications
>> works on the equipment I'm testing and as I can't afford more lost time
>> due to faults - I'm keeping to that build for the short term.
>>
>>> Subject : shutdown problem
>>> References : http://lkml.org/lkml/2006/10/22/140
>>> Submitter : art@usfltd.com
>>> teunis@wintersgift.com
>>> Jiri Slaby <jirislaby@gmail.com>
>>> Status : unknown
>> repaired by Jeff Dike's patch to fs/proc/array.c
>> ...
>
> Can you give me a pointer to this patch?
>
> cu
> Adrian
>
I have no idea how to look up the link any other way - so here's a copy
of the details from my mailbox (I've been keeping an archive local as I
frequently work offline)
posted by: akpm@osdl.org; 23/10/06 10:34 AM
From: Jeff Dike <jdike@addtoit.com>
add-process_session-helper-routine-deprecate-old-field-fix-warnings.patch
in -mm causes UML to hang at shutdown - init is sitting in a select on the
initctl socket.
This patch fixes it for me.
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Cc: Cedric Le Goater <clg@fr.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
- ---
fs/proc/array.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -puN
fs/proc/array.c~add-process_session-helper-routine-deprecate-old-field-fix-warnings-fix
fs/proc/array.c
- ---
a/fs/proc/array.c~add-process_session-helper-routine-deprecate-old-field-fix-warnings-fix
+++ a/fs/proc/array.c
@@ -388,7 +388,7 @@ static int do_task_stat(struct task_stru
stime = cputime_add(stime, sig->stime);
}
- - signal_session(sig);
+ sid = signal_session(sig);
pgid = process_group(task);
ppid = rcu_dereference(task->real_parent)->tgid;
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFQNojbFT/SAfwLKMRAqioAJ9+l+87bNRFJaHknJBGu6bYfrTlrACeOyts
gkeCAiYDPBmR7E052LEMAtU=
=eyIw
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 139+ messages in thread
* 2.6.19-rc3: known unfixed regressions (v2)
2006-10-23 23:22 Linux 2.6.19-rc3 Linus Torvalds
` (5 preceding siblings ...)
2006-10-25 20:13 ` Linux 2.6.19-rc3: !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB Athanasius
@ 2006-10-26 22:45 ` Adrian Bunk
2006-10-27 1:02 ` [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN Adrian Bunk
2006-10-29 23:13 ` 2.6.19-rc3: known unfixed regressions (v3) Adrian Bunk
7 siblings, 1 reply; 139+ messages in thread
From: Adrian Bunk @ 2006-10-26 22:45 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: Linux Kernel Mailing List, Pavel Machek, Greg KH, linux-pci,
Stephen Hemminger, Philipp Zabel, rmk, Martin Lorenz, len.brown,
linux-acpi, linux-pm, Michael S. Tsirkin, Thierry Vignaud,
jgarzik, linux-ide, Alex Romosan, Jens Axboe, Komuro,
Thomas Gleixner, Benjamin Herrenschmidt, Stefan Richter,
linux1394-devel, Christian, Mark Langsdorf, davej, cpufreq
This email lists some known regressions in 2.6.19-rc3 compared to 2.6.18
that are not yet fixed Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.
Due to the huge amount of recipients, please trim the Cc when answering.
Subject : swsusp initialized after SATA (CONFIG_PCI_MULTITHREAD_PROBE)
References : http://lkml.org/lkml/2006/10/14/31
Submitter : Pavel Machek <pavel@ucw.cz>
Status : unknown
Subject : MSI errors during boot (CONFIG_PCI_MULTITHREAD_PROBE)
References : http://lkml.org/lkml/2006/10/16/291
Submitter : Stephen Hemminger <shemminger@osdl.org>
Handled-By : Greg KH <greg@kroah.com>
Status : Greg is working on a fix
Subject : arm: Oops in __wake_up_common during htc magician resume
References : http://lkml.org/lkml/2006/10/25/73
Submitter : Philipp Zabel <philipp.zabel@gmail.com>
Status : unknown
Subject : X60s: BUG()s, lose ACPI events after suspend/resume
References : http://lkml.org/lkml/2006/10/10/39
Submitter : Martin Lorenz <martin@lorenz.eu.org>
Status : unknown
Subject : T60 stops triggering any ACPI events
References : http://lkml.org/lkml/2006/10/4/425
http://lkml.org/lkml/2006/10/16/262
http://bugzilla.kernel.org/show_bug.cgi?id=7408
Submitter : "Michael S. Tsirkin" <mst@mellanox.co.il>
Status : unknown
Subject : sata-via doesn't detect anymore disks attached to VIA vt6421
References : http://bugzilla.kernel.org/show_bug.cgi?id=7255
Submitter : Thierry Vignaud <tvignaud@mandriva.com>
Status : unknown
Subject : unable to rip cd
References : http://lkml.org/lkml/2006/10/13/100
Submitter : Alex Romosan <romosan@sycorax.lbl.gov>
Status : unknown
Subject : SMP kernel can not generate ISA irq properly
References : http://lkml.org/lkml/2006/10/22/15
Submitter : Komuro <komurojun-mbn@nifty.com>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Status : Thomas will investigate
Subject : ohci1394 on PPC_PMAC:
pci_set_power_state() failure and breaking suspend
References : http://lkml.org/lkml/2006/10/24/13
Submitter : Benjamin Herrenschmidt <benh@kernel.crashing.org>
Caused-By : Stefan Richter <stefanr@s5r6.in-berlin.de>
commit ea6104c22468239083857fa07425c312b1ecb424
Handled-By : Stefan Richter <stefanr@s5r6.in-berlin.de>
Status : Stefan Richter: looking for an answer when to ignore
the return code of pci_set_power_state
Subject : cpufreq not working on AMD K8
References : http://lkml.org/lkml/2006/10/10/114
Submitter : Christian <christiand59@web.de>
Handled-By : Mark Langsdorf <mark.langsdorf@amd.com>
Status : Mark is investigating
^ permalink raw reply [flat|nested] 139+ messages in thread
* [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN
2006-10-26 22:45 ` 2.6.19-rc3: known unfixed regressions (v2) Adrian Bunk
@ 2006-10-27 1:02 ` Adrian Bunk
2006-10-27 1:20 ` Matthew Wilcox
0 siblings, 1 reply; 139+ messages in thread
From: Adrian Bunk @ 2006-10-27 1:02 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: Linux Kernel Mailing List, Pavel Machek, Greg KH, linux-pci,
Stephen Hemminger
On Fri, Oct 27, 2006 at 12:45:41AM +0200, Adrian Bunk wrote:
>...
> Subject : swsusp initialized after SATA (CONFIG_PCI_MULTITHREAD_PROBE)
> References : http://lkml.org/lkml/2006/10/14/31
> Submitter : Pavel Machek <pavel@ucw.cz>
> Status : unknown
>
>
> Subject : MSI errors during boot (CONFIG_PCI_MULTITHREAD_PROBE)
> References : http://lkml.org/lkml/2006/10/16/291
> Submitter : Stephen Hemminger <shemminger@osdl.org>
> Handled-By : Greg KH <greg@kroah.com>
> Status : Greg is working on a fix
>...
PCI_MULTITHREAD_PROBE is an interesting feature, but in it's current
state it seems to be more of a trap for users who accidentally
enable it.
This patch lets PCI_MULTITHREAD_PROBE depend on BROKEN for 2.6.19.
The intention is to get this patch reversed in -mm as soon as it's in
Linus' tree, and reverse it for 2.6.20 or 2.6.21 after the fallout of
in-kernel problems PCI_MULTITHREAD_PROBE causes got fixed.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6/drivers/pci/Kconfig.old 2006-10-27 02:40:02.000000000 +0200
+++ linux-2.6/drivers/pci/Kconfig 2006-10-27 02:58:25.000000000 +0200
@@ -19,7 +19,7 @@
config PCI_MULTITHREAD_PROBE
bool "PCI Multi-threaded probe (EXPERIMENTAL)"
- depends on PCI && EXPERIMENTAL
+ depends on PCI && EXPERIMENTAL && BROKEN
help
Say Y here if you want the PCI core to spawn a new thread for
every PCI device that is probed. This can cause a huge
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN
2006-10-27 1:02 ` [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN Adrian Bunk
@ 2006-10-27 1:20 ` Matthew Wilcox
2006-10-27 1:28 ` Andrew Morton
2006-10-27 8:27 ` Pavel Machek
0 siblings, 2 replies; 139+ messages in thread
From: Matthew Wilcox @ 2006-10-27 1:20 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
Pavel Machek, Greg KH, linux-pci, Stephen Hemminger
On Fri, Oct 27, 2006 at 03:02:52AM +0200, Adrian Bunk wrote:
> PCI_MULTITHREAD_PROBE is an interesting feature, but in it's current
> state it seems to be more of a trap for users who accidentally
> enable it.
>
> This patch lets PCI_MULTITHREAD_PROBE depend on BROKEN for 2.6.19.
>
> The intention is to get this patch reversed in -mm as soon as it's in
> Linus' tree, and reverse it for 2.6.20 or 2.6.21 after the fallout of
> in-kernel problems PCI_MULTITHREAD_PROBE causes got fixed.
People who enable features clearly marked as EXPERIMENTAL deserve what
they get, IMO.
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN
2006-10-27 1:20 ` Matthew Wilcox
@ 2006-10-27 1:28 ` Andrew Morton
2006-10-27 2:11 ` Stephen Hemminger
2006-10-27 8:27 ` Pavel Machek
1 sibling, 1 reply; 139+ messages in thread
From: Andrew Morton @ 2006-10-27 1:28 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List,
Pavel Machek, Greg KH, linux-pci, Stephen Hemminger
On Thu, 26 Oct 2006 19:20:58 -0600
Matthew Wilcox <matthew@wil.cx> wrote:
> On Fri, Oct 27, 2006 at 03:02:52AM +0200, Adrian Bunk wrote:
> > PCI_MULTITHREAD_PROBE is an interesting feature, but in it's current
> > state it seems to be more of a trap for users who accidentally
> > enable it.
> >
> > This patch lets PCI_MULTITHREAD_PROBE depend on BROKEN for 2.6.19.
> >
> > The intention is to get this patch reversed in -mm as soon as it's in
> > Linus' tree, and reverse it for 2.6.20 or 2.6.21 after the fallout of
> > in-kernel problems PCI_MULTITHREAD_PROBE causes got fixed.
>
> People who enable features clearly marked as EXPERIMENTAL deserve what
> they get, IMO.
It's not the impact on "people" which is of concern - it's the impact on
kernel developers - specifically those who spend time looking at bug
reports :(
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN
2006-10-27 1:28 ` Andrew Morton
@ 2006-10-27 2:11 ` Stephen Hemminger
2006-10-27 17:07 ` Greg KH
0 siblings, 1 reply; 139+ messages in thread
From: Stephen Hemminger @ 2006-10-27 2:11 UTC (permalink / raw)
To: Andrew Morton
Cc: Matthew Wilcox, Adrian Bunk, Linus Torvalds,
Linux Kernel Mailing List, Pavel Machek, Greg KH, linux-pci
On Thu, 26 Oct 2006 18:28:38 -0700
Andrew Morton <akpm@osdl.org> wrote:
> On Thu, 26 Oct 2006 19:20:58 -0600
> Matthew Wilcox <matthew@wil.cx> wrote:
>
> > On Fri, Oct 27, 2006 at 03:02:52AM +0200, Adrian Bunk wrote:
> > > PCI_MULTITHREAD_PROBE is an interesting feature, but in it's current
> > > state it seems to be more of a trap for users who accidentally
> > > enable it.
> > >
> > > This patch lets PCI_MULTITHREAD_PROBE depend on BROKEN for 2.6.19.
> > >
> > > The intention is to get this patch reversed in -mm as soon as it's in
> > > Linus' tree, and reverse it for 2.6.20 or 2.6.21 after the fallout of
> > > in-kernel problems PCI_MULTITHREAD_PROBE causes got fixed.
> >
> > People who enable features clearly marked as EXPERIMENTAL deserve what
> > they get, IMO.
>
> It's not the impact on "people" which is of concern - it's the impact on
> kernel developers - specifically those who spend time looking at bug
> reports :(
Either it is broken and should be removed, or is barely working and
should be fixed. If Greg wants to take bug reports then it can stay.
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN
2006-10-27 1:20 ` Matthew Wilcox
2006-10-27 1:28 ` Andrew Morton
@ 2006-10-27 8:27 ` Pavel Machek
1 sibling, 0 replies; 139+ messages in thread
From: Pavel Machek @ 2006-10-27 8:27 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Adrian Bunk, Linus Torvalds, Andrew Morton,
Linux Kernel Mailing List, Greg KH, linux-pci, Stephen Hemminger
On Thu 2006-10-26 19:20:58, Matthew Wilcox wrote:
> On Fri, Oct 27, 2006 at 03:02:52AM +0200, Adrian Bunk wrote:
> > PCI_MULTITHREAD_PROBE is an interesting feature, but in it's current
> > state it seems to be more of a trap for users who accidentally
> > enable it.
> >
> > This patch lets PCI_MULTITHREAD_PROBE depend on BROKEN for 2.6.19.
> >
> > The intention is to get this patch reversed in -mm as soon as it's in
> > Linus' tree, and reverse it for 2.6.20 or 2.6.21 after the fallout of
> > in-kernel problems PCI_MULTITHREAD_PROBE causes got fixed.
>
> People who enable features clearly marked as EXPERIMENTAL deserve what
> they get, IMO.
Eh? It is no longer "experimental". It went to "known broken in
non-funny ways".
People normally use experimental features... (like cpu hotplug, acpi
hotkeys, intel 830m framebuffer, USB CATC ethernet, SDHCI, kernel
profiling) without expecting breakages. (Hmm, perhaps some of these
should not be marked experimental any more?)
I'd actually vote for removing MULTITHREAD_PROBE from kconfig,
temporarily, but I guess BROKEN is okay, too.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN
2006-10-27 2:11 ` Stephen Hemminger
@ 2006-10-27 17:07 ` Greg KH
2006-10-27 17:22 ` Pavel Machek
` (2 more replies)
0 siblings, 3 replies; 139+ messages in thread
From: Greg KH @ 2006-10-27 17:07 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Andrew Morton, Matthew Wilcox, Adrian Bunk, Linus Torvalds,
Linux Kernel Mailing List, Pavel Machek, linux-pci
On Thu, Oct 26, 2006 at 07:11:31PM -0700, Stephen Hemminger wrote:
> On Thu, 26 Oct 2006 18:28:38 -0700
> Andrew Morton <akpm@osdl.org> wrote:
>
> > On Thu, 26 Oct 2006 19:20:58 -0600
> > Matthew Wilcox <matthew@wil.cx> wrote:
> >
> > > On Fri, Oct 27, 2006 at 03:02:52AM +0200, Adrian Bunk wrote:
> > > > PCI_MULTITHREAD_PROBE is an interesting feature, but in it's current
> > > > state it seems to be more of a trap for users who accidentally
> > > > enable it.
> > > >
> > > > This patch lets PCI_MULTITHREAD_PROBE depend on BROKEN for 2.6.19.
> > > >
> > > > The intention is to get this patch reversed in -mm as soon as it's in
> > > > Linus' tree, and reverse it for 2.6.20 or 2.6.21 after the fallout of
> > > > in-kernel problems PCI_MULTITHREAD_PROBE causes got fixed.
> > >
> > > People who enable features clearly marked as EXPERIMENTAL deserve what
> > > they get, IMO.
> >
> > It's not the impact on "people" which is of concern - it's the impact on
> > kernel developers - specifically those who spend time looking at bug
> > reports :(
>
> Either it is broken and should be removed, or is barely working and
> should be fixed. If Greg wants to take bug reports then it can stay.
I want to keep taking bug reports.
I've found only 1 real bug from all of this. The pci MSI initialization
issue. It's on my queue of things to fix. Andrew has also sent me
another "interesting" patch about making sure devices are found by the
time we hit another init level which I'll see about adding too.
But that MSI bug was a real bug, which is good to have found. It's also
found other real bugs in other subsystems that could easily be hit by
other users.
So no, this should not be marked BROKEN.
It's a very experimental feature, as the help text says. If you can
think of any harsher language to put in that text, please let me know.
And yes, there also has been a proposed change to the driver core to fix
up how the multi-thread stuff works that looks very good, but it's down
in my queue that I'm trying to catch up on right now.
So consider this a NAK for this change.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN
2006-10-27 17:07 ` Greg KH
@ 2006-10-27 17:22 ` Pavel Machek
2006-10-27 18:39 ` Andrew Morton
2006-10-27 22:23 ` [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN Adrian Bunk
2006-10-27 22:57 ` Alan Cox
2 siblings, 1 reply; 139+ messages in thread
From: Pavel Machek @ 2006-10-27 17:22 UTC (permalink / raw)
To: Greg KH
Cc: Stephen Hemminger, Andrew Morton, Matthew Wilcox, Adrian Bunk,
Linus Torvalds, Linux Kernel Mailing List, linux-pci
Hi!
> > > > > PCI_MULTITHREAD_PROBE is an interesting feature, but in it's current
> > > > > state it seems to be more of a trap for users who accidentally
> > > > > enable it.
> > > > >
> > > > > This patch lets PCI_MULTITHREAD_PROBE depend on BROKEN for 2.6.19.
> > > > >
> > > > > The intention is to get this patch reversed in -mm as soon as it's in
> > > > > Linus' tree, and reverse it for 2.6.20 or 2.6.21 after the fallout of
> > > > > in-kernel problems PCI_MULTITHREAD_PROBE causes got fixed.
> > > >
> > > > People who enable features clearly marked as EXPERIMENTAL deserve what
> > > > they get, IMO.
> > >
> > > It's not the impact on "people" which is of concern - it's the impact on
> > > kernel developers - specifically those who spend time looking at bug
> > > reports :(
> >
> > Either it is broken and should be removed, or is barely working and
> > should be fixed. If Greg wants to take bug reports then it can stay.
>
> I want to keep taking bug reports.
>
> I've found only 1 real bug from all of this. The pci MSI initialization
> issue. It's on my queue of things to fix. Andrew has also sent me
> another "interesting" patch about making sure devices are found by the
> time we hit another init level which I'll see about adding too.
And the swsusp vs. SATA issue? Currently, SATA can be initialized
after swsusp, leading to swsusp not finding its image and failing...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN
2006-10-27 17:22 ` Pavel Machek
@ 2006-10-27 18:39 ` Andrew Morton
2006-10-27 18:41 ` vmlinux.lds: consolidate initcall sections Andrew Morton
0 siblings, 1 reply; 139+ messages in thread
From: Andrew Morton @ 2006-10-27 18:39 UTC (permalink / raw)
To: Pavel Machek
Cc: Greg KH, Stephen Hemminger, Matthew Wilcox, Adrian Bunk,
Linus Torvalds, Linux Kernel Mailing List, linux-pci
On Fri, 27 Oct 2006 19:22:19 +0200
Pavel Machek <pavel@ucw.cz> wrote:
> > I've found only 1 real bug from all of this. The pci MSI initialization
> > issue. It's on my queue of things to fix. Andrew has also sent me
> > another "interesting" patch about making sure devices are found by the
> > time we hit another init level which I'll see about adding too.
>
> And the swsusp vs. SATA issue? Currently, SATA can be initialized
> after swsusp, leading to swsusp not finding its image and failing...
How can sata be initialised after swsusp? Are they each using correctly
prioritised initcall levels?
If so then the problem is presumably that sata initialisation is started
before swsusp initialisation, but sata completes _after_ swsusp
initialisation has run. In which case the as-yet-untested
drivers-wait-for-threaded-probes-between-initcall-levels.patch should fix
this.
Greg, I think I'll send vmlinuxlds-consolidate-initcall-sections.patch into
Linus for 2.6.19, make things easier for everyone.
I'll send both patches. Please test ;)
^ permalink raw reply [flat|nested] 139+ messages in thread
* vmlinux.lds: consolidate initcall sections
2006-10-27 18:39 ` Andrew Morton
@ 2006-10-27 18:41 ` Andrew Morton
2006-10-27 18:42 ` [patch] drivers: wait for threaded probes between initcall levels Andrew Morton
` (2 more replies)
0 siblings, 3 replies; 139+ messages in thread
From: Andrew Morton @ 2006-10-27 18:41 UTC (permalink / raw)
To: Pavel Machek, Greg KH, Stephen Hemminger, Matthew Wilcox,
Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List, linux-pci
From: Andrew Morton <akpm@osdl.org>
Add a vmlinux.lds.h helper macro for defining the eight-level initcall table,
teach all the architectures to use it.
This is a prerequisite for a patch which performs initcall synchronisation for
multithreaded-probing.
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
arch/alpha/kernel/vmlinux.lds.S | 8 +-------
arch/arm/kernel/vmlinux.lds.S | 8 +-------
arch/frv/kernel/vmlinux.lds.S | 8 +-------
arch/h8300/kernel/vmlinux.lds.S | 8 +-------
arch/i386/kernel/vmlinux.lds.S | 8 +-------
arch/ia64/kernel/vmlinux.lds.S | 8 +-------
arch/m32r/kernel/vmlinux.lds.S | 8 +-------
arch/m68knommu/kernel/vmlinux.lds.S | 8 +-------
arch/mips/kernel/vmlinux.lds.S | 8 +-------
arch/parisc/kernel/vmlinux.lds.S | 8 +-------
arch/powerpc/kernel/vmlinux.lds.S | 8 +-------
arch/ppc/kernel/vmlinux.lds.S | 8 +-------
arch/s390/kernel/vmlinux.lds.S | 8 +-------
arch/sh/kernel/vmlinux.lds.S | 8 +-------
arch/sh64/kernel/vmlinux.lds.S | 8 +-------
arch/sparc/kernel/vmlinux.lds.S | 8 +-------
arch/sparc64/kernel/vmlinux.lds.S | 8 +-------
arch/v850/kernel/vmlinux.lds.S | 8 +-------
arch/x86_64/kernel/vmlinux.lds.S | 8 +-------
arch/xtensa/kernel/vmlinux.lds.S | 8 +-------
include/asm-generic/vmlinux.lds.h | 10 ++++++++++
21 files changed, 30 insertions(+), 140 deletions(-)
diff -puN arch/alpha/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/alpha/kernel/vmlinux.lds.S
--- a/arch/alpha/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections
+++ a/arch/alpha/kernel/vmlinux.lds.S
@@ -48,13 +48,7 @@ SECTIONS
. = ALIGN(8);
__initcall_start = .;
.initcall.init : {
- *(.initcall1.init)
- *(.initcall2.init)
- *(.initcall3.init)
- *(.initcall4.init)
- *(.initcall5.init)
- *(.initcall6.init)
- *(.initcall7.init)
+ INITCALLS
}
__initcall_end = .;
diff -puN arch/arm/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/arm/kernel/vmlinux.lds.S
--- a/arch/arm/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections
+++ a/arch/arm/kernel/vmlinux.lds.S
@@ -45,13 +45,7 @@ SECTIONS
*(.early_param.init)
__early_end = .;
__initcall_start = .;
- *(.initcall1.init)
- *(.initcall2.init)
- *(.initcall3.init)
- *(.initcall4.init)
- *(.initcall5.init)
- *(.initcall6.init)
- *(.initcall7.init)
+ INITCALLS
__initcall_end = .;
__con_initcall_start = .;
*(.con_initcall.init)
diff -puN arch/arm26/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/arm26/kernel/vmlinux.lds.S
diff -puN arch/frv/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/frv/kernel/vmlinux.lds.S
--- a/arch/frv/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections
+++ a/arch/frv/kernel/vmlinux.lds.S
@@ -44,13 +44,7 @@ SECTIONS
__initcall_start = .;
.initcall.init : {
- *(.initcall1.init)
- *(.initcall2.init)
- *(.initcall3.init)
- *(.initcall4.init)
- *(.initcall5.init)
- *(.initcall6.init)
- *(.initcall7.init)
+ INITCALLS
}
__initcall_end = .;
__con_initcall_start = .;
diff -puN arch/h8300/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/h8300/kernel/vmlinux.lds.S
--- a/arch/h8300/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections
+++ a/arch/h8300/kernel/vmlinux.lds.S
@@ -118,13 +118,7 @@ SECTIONS
. = ALIGN(0x4) ;
___setup_end = .;
___initcall_start = .;
- *(.initcall1.init)
- *(.initcall2.init)
- *(.initcall3.init)
- *(.initcall4.init)
- *(.initcall5.init)
- *(.initcall6.init)
- *(.initcall7.init)
+ INITCALLS
___initcall_end = .;
___con_initcall_start = .;
*(.con_initcall.init)
diff -puN arch/i386/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/i386/kernel/vmlinux.lds.S
--- a/arch/i386/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections
+++ a/arch/i386/kernel/vmlinux.lds.S
@@ -126,13 +126,7 @@ SECTIONS
__setup_end = .;
__initcall_start = .;
.initcall.init : AT(ADDR(.initcall.init) - LOAD_OFFSET) {
- *(.initcall1.init)
- *(.initcall2.init)
- *(.initcall3.init)
- *(.initcall4.init)
- *(.initcall5.init)
- *(.initcall6.init)
- *(.initcall7.init)
+ INITCALLS
}
__initcall_end = .;
__con_initcall_start = .;
diff -puN arch/ia64/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/ia64/kernel/vmlinux.lds.S
--- a/arch/ia64/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections
+++ a/arch/ia64/kernel/vmlinux.lds.S
@@ -128,13 +128,7 @@ SECTIONS
.initcall.init : AT(ADDR(.initcall.init) - LOAD_OFFSET)
{
__initcall_start = .;
- *(.initcall1.init)
- *(.initcall2.init)
- *(.initcall3.init)
- *(.initcall4.init)
- *(.initcall5.init)
- *(.initcall6.init)
- *(.initcall7.init)
+ INITCALLS
__initcall_end = .;
}
diff -puN arch/m32r/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/m32r/kernel/vmlinux.lds.S
--- a/arch/m32r/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections
+++ a/arch/m32r/kernel/vmlinux.lds.S
@@ -83,13 +83,7 @@ SECTIONS
__setup_end = .;
__initcall_start = .;
.initcall.init : {
- *(.initcall1.init)
- *(.initcall2.init)
- *(.initcall3.init)
- *(.initcall4.init)
- *(.initcall5.init)
- *(.initcall6.init)
- *(.initcall7.init)
+ INITCALLS
}
__initcall_end = .;
__con_initcall_start = .;
diff -puN arch/m68k/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/m68k/kernel/vmlinux.lds.S
diff -puN arch/m68knommu/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/m68knommu/kernel/vmlinux.lds.S
--- a/arch/m68knommu/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections
+++ a/arch/m68knommu/kernel/vmlinux.lds.S
@@ -140,13 +140,7 @@ SECTIONS {
*(.init.setup)
__setup_end = .;
__initcall_start = .;
- *(.initcall1.init)
- *(.initcall2.init)
- *(.initcall3.init)
- *(.initcall4.init)
- *(.initcall5.init)
- *(.initcall6.init)
- *(.initcall7.init)
+ INITCALLS
__initcall_end = .;
__con_initcall_start = .;
*(.con_initcall.init)
diff -puN arch/mips/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/mips/kernel/vmlinux.lds.S
--- a/arch/mips/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections
+++ a/arch/mips/kernel/vmlinux.lds.S
@@ -91,13 +91,7 @@ SECTIONS
__initcall_start = .;
.initcall.init : {
- *(.initcall1.init)
- *(.initcall2.init)
- *(.initcall3.init)
- *(.initcall4.init)
- *(.initcall5.init)
- *(.initcall6.init)
- *(.initcall7.init)
+ INITCALLS
}
__initcall_end = .;
diff -puN arch/parisc/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/parisc/kernel/vmlinux.lds.S
--- a/arch/parisc/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections
+++ a/arch/parisc/kernel/vmlinux.lds.S
@@ -153,13 +153,7 @@ SECTIONS
__setup_end = .;
__initcall_start = .;
.initcall.init : {
- *(.initcall1.init)
- *(.initcall2.init)
- *(.initcall3.init)
- *(.initcall4.init)
- *(.initcall5.init)
- *(.initcall6.init)
- *(.initcall7.init)
+ INITCALLS
}
__initcall_end = .;
__con_initcall_start = .;
diff -puN arch/powerpc/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/powerpc/kernel/vmlinux.lds.S
--- a/arch/powerpc/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections
+++ a/arch/powerpc/kernel/vmlinux.lds.S
@@ -108,13 +108,7 @@ SECTIONS
.initcall.init : {
__initcall_start = .;
- *(.initcall1.init)
- *(.initcall2.init)
- *(.initcall3.init)
- *(.initcall4.init)
- *(.initcall5.init)
- *(.initcall6.init)
- *(.initcall7.init)
+ INITCALLS
__initcall_end = .;
}
diff -puN arch/ppc/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/ppc/kernel/vmlinux.lds.S
--- a/arch/ppc/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections
+++ a/arch/ppc/kernel/vmlinux.lds.S
@@ -115,13 +115,7 @@ SECTIONS
__setup_end = .;
__initcall_start = .;
.initcall.init : {
- *(.initcall1.init)
- *(.initcall2.init)
- *(.initcall3.init)
- *(.initcall4.init)
- *(.initcall5.init)
- *(.initcall6.init)
- *(.initcall7.init)
+ INITCALLS
}
__initcall_end = .;
diff -puN arch/s390/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/s390/kernel/vmlinux.lds.S
--- a/arch/s390/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections
+++ a/arch/s390/kernel/vmlinux.lds.S
@@ -83,13 +83,7 @@ SECTIONS
__setup_end = .;
__initcall_start = .;
.initcall.init : {
- *(.initcall1.init)
- *(.initcall2.init)
- *(.initcall3.init)
- *(.initcall4.init)
- *(.initcall5.init)
- *(.initcall6.init)
- *(.initcall7.init)
+ INITCALLS
}
__initcall_end = .;
__con_initcall_start = .;
diff -puN arch/sh/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/sh/kernel/vmlinux.lds.S
--- a/arch/sh/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections
+++ a/arch/sh/kernel/vmlinux.lds.S
@@ -76,13 +76,7 @@ SECTIONS
__setup_end = .;
__initcall_start = .;
.initcall.init : {
- *(.initcall1.init)
- *(.initcall2.init)
- *(.initcall3.init)
- *(.initcall4.init)
- *(.initcall5.init)
- *(.initcall6.init)
- *(.initcall7.init)
+ INITCALLS
}
__initcall_end = .;
__con_initcall_start = .;
diff -puN arch/sh64/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/sh64/kernel/vmlinux.lds.S
--- a/arch/sh64/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections
+++ a/arch/sh64/kernel/vmlinux.lds.S
@@ -108,13 +108,7 @@ SECTIONS
__setup_end = .;
__initcall_start = .;
.initcall.init : C_PHYS(.initcall.init) {
- *(.initcall1.init)
- *(.initcall2.init)
- *(.initcall3.init)
- *(.initcall4.init)
- *(.initcall5.init)
- *(.initcall6.init)
- *(.initcall7.init)
+ INITCALLS
}
__initcall_end = .;
__con_initcall_start = .;
diff -puN arch/sparc/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/sparc/kernel/vmlinux.lds.S
--- a/arch/sparc/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections
+++ a/arch/sparc/kernel/vmlinux.lds.S
@@ -49,13 +49,7 @@ SECTIONS
__setup_end = .;
__initcall_start = .;
.initcall.init : {
- *(.initcall1.init)
- *(.initcall2.init)
- *(.initcall3.init)
- *(.initcall4.init)
- *(.initcall5.init)
- *(.initcall6.init)
- *(.initcall7.init)
+ INITCALLS
}
__initcall_end = .;
__con_initcall_start = .;
diff -puN arch/sparc64/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/sparc64/kernel/vmlinux.lds.S
--- a/arch/sparc64/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections
+++ a/arch/sparc64/kernel/vmlinux.lds.S
@@ -57,13 +57,7 @@ SECTIONS
__setup_end = .;
__initcall_start = .;
.initcall.init : {
- *(.initcall1.init)
- *(.initcall2.init)
- *(.initcall3.init)
- *(.initcall4.init)
- *(.initcall5.init)
- *(.initcall6.init)
- *(.initcall7.init)
+ INITCALLS
}
__initcall_end = .;
__con_initcall_start = .;
diff -puN arch/um/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/um/kernel/vmlinux.lds.S
diff -puN arch/v850/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/v850/kernel/vmlinux.lds.S
--- a/arch/v850/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections
+++ a/arch/v850/kernel/vmlinux.lds.S
@@ -140,13 +140,7 @@
___setup_end = . ; \
___initcall_start = . ; \
*(.initcall.init) \
- *(.initcall1.init) \
- *(.initcall2.init) \
- *(.initcall3.init) \
- *(.initcall4.init) \
- *(.initcall5.init) \
- *(.initcall6.init) \
- *(.initcall7.init) \
+ INITCALLS \
. = ALIGN (4) ; \
___initcall_end = . ; \
___con_initcall_start = .; \
diff -puN arch/x86_64/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/x86_64/kernel/vmlinux.lds.S
--- a/arch/x86_64/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections
+++ a/arch/x86_64/kernel/vmlinux.lds.S
@@ -175,13 +175,7 @@ SECTIONS
__setup_end = .;
__initcall_start = .;
.initcall.init : AT(ADDR(.initcall.init) - LOAD_OFFSET) {
- *(.initcall1.init)
- *(.initcall2.init)
- *(.initcall3.init)
- *(.initcall4.init)
- *(.initcall5.init)
- *(.initcall6.init)
- *(.initcall7.init)
+ INITCALLS
}
__initcall_end = .;
__con_initcall_start = .;
diff -puN arch/xtensa/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/xtensa/kernel/vmlinux.lds.S
--- a/arch/xtensa/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections
+++ a/arch/xtensa/kernel/vmlinux.lds.S
@@ -184,13 +184,7 @@ SECTIONS
__initcall_start = .;
.initcall.init : {
- *(.initcall1.init)
- *(.initcall2.init)
- *(.initcall3.init)
- *(.initcall4.init)
- *(.initcall5.init)
- *(.initcall6.init)
- *(.initcall7.init)
+ INITCALLS
}
__initcall_end = .;
diff -puN include/asm-generic/vmlinux.lds.h~vmlinuxlds-consolidate-initcall-sections include/asm-generic/vmlinux.lds.h
--- a/include/asm-generic/vmlinux.lds.h~vmlinuxlds-consolidate-initcall-sections
+++ a/include/asm-generic/vmlinux.lds.h
@@ -213,3 +213,13 @@
#define NOTES \
.notes : { *(.note.*) } :note
+
+#define INITCALLS \
+ *(.initcall1.init) \
+ *(.initcall2.init) \
+ *(.initcall3.init) \
+ *(.initcall4.init) \
+ *(.initcall5.init) \
+ *(.initcall6.init) \
+ *(.initcall7.init)
+
_
^ permalink raw reply [flat|nested] 139+ messages in thread
* [patch] drivers: wait for threaded probes between initcall levels
2006-10-27 18:41 ` vmlinux.lds: consolidate initcall sections Andrew Morton
@ 2006-10-27 18:42 ` Andrew Morton
2006-10-27 18:47 ` Stephen Hemminger
2006-10-27 22:59 ` Alan Cox
2006-10-27 19:31 ` vmlinux.lds: consolidate initcall sections Haavard Skinnemoen
2006-10-27 19:44 ` Matthew Wilcox
2 siblings, 2 replies; 139+ messages in thread
From: Andrew Morton @ 2006-10-27 18:42 UTC (permalink / raw)
To: Pavel Machek, Greg KH, Stephen Hemminger, Matthew Wilcox,
Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List, linux-pci
From: Andrew Morton <akpm@osdl.org>
The multithreaded-probing code has a problem: after one initcall level (eg,
core_initcall) has been processed, we will then start processing the next
level (postcore_initcall) while the kernel threads which are handling
core_initcall are still executing. This breaks the guarantees which the
layered initcalls previously gave us.
IOW, we want to be multithreaded _within_ an initcall level, but not between
different levels.
Fix that up by causing the probing code to wait for all outstanding probes at
one level to complete before we start processing the next level.
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---
drivers/base/dd.c | 30 ++++++++++++++++++++++++++++
include/asm-generic/vmlinux.lds.h | 9 +++++++-
include/linux/init.h | 28 +++++++++++++++++---------
3 files changed, 57 insertions(+), 10 deletions(-)
diff -puN drivers/base/dd.c~drivers-wait-for-threaded-probes-between-initcall-levels drivers/base/dd.c
--- a/drivers/base/dd.c~drivers-wait-for-threaded-probes-between-initcall-levels
+++ a/drivers/base/dd.c
@@ -18,6 +18,7 @@
#include <linux/device.h>
#include <linux/module.h>
#include <linux/kthread.h>
+#include <linux/wait.h>
#include "base.h"
#include "power/power.h"
@@ -70,6 +71,8 @@ struct stupid_thread_structure {
};
static atomic_t probe_count = ATOMIC_INIT(0);
+static DECLARE_WAIT_QUEUE_HEAD(probe_waitqueue);
+
static int really_probe(void *void_data)
{
struct stupid_thread_structure *data = void_data;
@@ -121,6 +124,7 @@ probe_failed:
done:
kfree(data);
atomic_dec(&probe_count);
+ wake_up(&probe_waitqueue);
return ret;
}
@@ -337,6 +341,32 @@ void driver_detach(struct device_driver
}
}
+#ifdef CONFIG_PCI_MULTITHREAD_PROBE
+static int __init wait_for_probes(void)
+{
+ DEFINE_WAIT(wait);
+
+ printk(KERN_INFO "%s: waiting for %d threads\n", __FUNCTION__,
+ atomic_read(&probe_count));
+ if (!atomic_read(&probe_count))
+ return 0;
+ while (atomic_read(&probe_count)) {
+ prepare_to_wait(&probe_waitqueue, &wait, TASK_UNINTERRUPTIBLE);
+ if (atomic_read(&probe_count))
+ schedule();
+ }
+ finish_wait(&probe_waitqueue, &wait);
+ return 0;
+}
+
+core_initcall_sync(wait_for_probes);
+postcore_initcall_sync(wait_for_probes);
+arch_initcall_sync(wait_for_probes);
+subsys_initcall_sync(wait_for_probes);
+fs_initcall_sync(wait_for_probes);
+device_initcall_sync(wait_for_probes);
+late_initcall_sync(wait_for_probes);
+#endif
EXPORT_SYMBOL_GPL(device_bind_driver);
EXPORT_SYMBOL_GPL(device_release_driver);
diff -puN include/asm-generic/vmlinux.lds.h~drivers-wait-for-threaded-probes-between-initcall-levels include/asm-generic/vmlinux.lds.h
--- a/include/asm-generic/vmlinux.lds.h~drivers-wait-for-threaded-probes-between-initcall-levels
+++ a/include/asm-generic/vmlinux.lds.h
@@ -216,10 +216,17 @@
#define INITCALLS \
*(.initcall1.init) \
+ *(.initcall1s.init) \
*(.initcall2.init) \
+ *(.initcall2s.init) \
*(.initcall3.init) \
+ *(.initcall3s.init) \
*(.initcall4.init) \
+ *(.initcall4s.init) \
*(.initcall5.init) \
+ *(.initcall5s.init) \
*(.initcall6.init) \
- *(.initcall7.init)
+ *(.initcall6s.init) \
+ *(.initcall7.init) \
+ *(.initcall7s.init)
diff -puN include/linux/init.h~drivers-wait-for-threaded-probes-between-initcall-levels include/linux/init.h
--- a/include/linux/init.h~drivers-wait-for-threaded-probes-between-initcall-levels
+++ a/include/linux/init.h
@@ -84,19 +84,29 @@ extern void setup_arch(char **);
* by link order.
* For backwards compatibility, initcall() puts the call in
* the device init subsection.
+ *
+ * The `id' arg to __define_initcall() is needed so that multiple initcalls
+ * can point at the same handler without causing duplicate-symbol build errors.
*/
-#define __define_initcall(level,fn) \
- static initcall_t __initcall_##fn __attribute_used__ \
+#define __define_initcall(level,fn,id) \
+ static initcall_t __initcall_##fn##id __attribute_used__ \
__attribute__((__section__(".initcall" level ".init"))) = fn
-#define core_initcall(fn) __define_initcall("1",fn)
-#define postcore_initcall(fn) __define_initcall("2",fn)
-#define arch_initcall(fn) __define_initcall("3",fn)
-#define subsys_initcall(fn) __define_initcall("4",fn)
-#define fs_initcall(fn) __define_initcall("5",fn)
-#define device_initcall(fn) __define_initcall("6",fn)
-#define late_initcall(fn) __define_initcall("7",fn)
+#define core_initcall(fn) __define_initcall("1",fn,1)
+#define core_initcall_sync(fn) __define_initcall("1s",fn,1s)
+#define postcore_initcall(fn) __define_initcall("2",fn,2)
+#define postcore_initcall_sync(fn) __define_initcall("2s",fn,2s)
+#define arch_initcall(fn) __define_initcall("3",fn,3)
+#define arch_initcall_sync(fn) __define_initcall("3s",fn,3s)
+#define subsys_initcall(fn) __define_initcall("4",fn,4)
+#define subsys_initcall_sync(fn) __define_initcall("4s",fn,4s)
+#define fs_initcall(fn) __define_initcall("5",fn,5)
+#define fs_initcall_sync(fn) __define_initcall("5s",fn,5s)
+#define device_initcall(fn) __define_initcall("6",fn,6)
+#define device_initcall_sync(fn) __define_initcall("6s",fn,6s)
+#define late_initcall(fn) __define_initcall("7",fn,7)
+#define late_initcall_sync(fn) __define_initcall("7s",fn,7s)
#define __initcall(fn) device_initcall(fn)
_
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
2006-10-27 18:42 ` [patch] drivers: wait for threaded probes between initcall levels Andrew Morton
@ 2006-10-27 18:47 ` Stephen Hemminger
2006-10-27 20:15 ` Andrew Morton
2006-10-27 22:59 ` Alan Cox
1 sibling, 1 reply; 139+ messages in thread
From: Stephen Hemminger @ 2006-10-27 18:47 UTC (permalink / raw)
To: Andrew Morton
Cc: Pavel Machek, Greg KH, Matthew Wilcox, Adrian Bunk,
Linus Torvalds, Linux Kernel Mailing List, linux-pci
On Fri, 27 Oct 2006 11:42:37 -0700
Andrew Morton <akpm@osdl.org> wrote:
> From: Andrew Morton <akpm@osdl.org>
>
> The multithreaded-probing code has a problem: after one initcall level (eg,
> core_initcall) has been processed, we will then start processing the next
> level (postcore_initcall) while the kernel threads which are handling
> core_initcall are still executing. This breaks the guarantees which the
> layered initcalls previously gave us.
>
> IOW, we want to be multithreaded _within_ an initcall level, but not between
> different levels.
>
> Fix that up by causing the probing code to wait for all outstanding probes at
> one level to complete before we start processing the next level.
>
> Cc: Greg KH <greg@kroah.com>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
> ---
>
This looks like a good place to use a counting semaphore.
--
Stephen Hemminger <shemminger@osdl.org>
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: vmlinux.lds: consolidate initcall sections
2006-10-27 18:41 ` vmlinux.lds: consolidate initcall sections Andrew Morton
2006-10-27 18:42 ` [patch] drivers: wait for threaded probes between initcall levels Andrew Morton
@ 2006-10-27 19:31 ` Haavard Skinnemoen
2006-10-29 10:21 ` Geert Uytterhoeven
2006-10-27 19:44 ` Matthew Wilcox
2 siblings, 1 reply; 139+ messages in thread
From: Haavard Skinnemoen @ 2006-10-27 19:31 UTC (permalink / raw)
To: Andrew Morton
Cc: Pavel Machek, Greg KH, Stephen Hemminger, Matthew Wilcox,
Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List, linux-pci
On 10/27/06, Andrew Morton <akpm@osdl.org> wrote:
> From: Andrew Morton <akpm@osdl.org>
>
> Add a vmlinux.lds.h helper macro for defining the eight-level initcall table,
> teach all the architectures to use it.
Please include AVR32 as well while you're at it ;)
Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com>
---
arch/avr32/kernel/vmlinux.lds.c | 8 +-------
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/arch/avr32/kernel/vmlinux.lds.c b/arch/avr32/kernel/vmlinux.lds.c
index cdd627c..5c4424e 100644
--- a/arch/avr32/kernel/vmlinux.lds.c
+++ b/arch/avr32/kernel/vmlinux.lds.c
@@ -38,13 +38,7 @@ SECTIONS
__setup_end = .;
. = ALIGN(4);
__initcall_start = .;
- *(.initcall1.init)
- *(.initcall2.init)
- *(.initcall3.init)
- *(.initcall4.init)
- *(.initcall5.init)
- *(.initcall6.init)
- *(.initcall7.init)
+ INITCALLS
__initcall_end = .;
__con_initcall_start = .;
*(.con_initcall.init)
--
1.4.1.1
^ permalink raw reply related [flat|nested] 139+ messages in thread
* Re: vmlinux.lds: consolidate initcall sections
2006-10-27 18:41 ` vmlinux.lds: consolidate initcall sections Andrew Morton
2006-10-27 18:42 ` [patch] drivers: wait for threaded probes between initcall levels Andrew Morton
2006-10-27 19:31 ` vmlinux.lds: consolidate initcall sections Haavard Skinnemoen
@ 2006-10-27 19:44 ` Matthew Wilcox
2006-10-27 20:17 ` Andrew Morton
2 siblings, 1 reply; 139+ messages in thread
From: Matthew Wilcox @ 2006-10-27 19:44 UTC (permalink / raw)
To: Andrew Morton
Cc: Pavel Machek, Greg KH, Stephen Hemminger, Adrian Bunk,
Linus Torvalds, Linux Kernel Mailing List, linux-pci
On Fri, Oct 27, 2006 at 11:41:44AM -0700, Andrew Morton wrote:
> Add a vmlinux.lds.h helper macro for defining the eight-level initcall table,
> teach all the architectures to use it.
> @@ -48,13 +48,7 @@ SECTIONS
> . = ALIGN(8);
> __initcall_start = .;
> .initcall.init : {
> - *(.initcall1.init)
> - *(.initcall2.init)
> - *(.initcall3.init)
> - *(.initcall4.init)
> - *(.initcall5.init)
> - *(.initcall6.init)
> - *(.initcall7.init)
> + INITCALLS
> }
> __initcall_end = .;
Why not make the INITCALLS macro include more:
+#define INITCALLS \
+ __initcall_start = .; \
+ .initcall.init : { \
+ *(.initcall1.init) \
+ *(.initcall2.init) \
+ *(.initcall3.init) \
+ *(.initcall4.init) \
+ *(.initcall5.init) \
+ *(.initcall6.init) \
+ *(.initcall7.init) \
+ } \
+ __initcall_end = .;
Also, you might want to check the spaces at the front of your INITCALLS
macro; I see two spaces before the first tab.
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
2006-10-27 18:47 ` Stephen Hemminger
@ 2006-10-27 20:15 ` Andrew Morton
2006-10-27 20:42 ` Linus Torvalds
0 siblings, 1 reply; 139+ messages in thread
From: Andrew Morton @ 2006-10-27 20:15 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Pavel Machek, Greg KH, Matthew Wilcox, Adrian Bunk,
Linus Torvalds, Linux Kernel Mailing List, linux-pci
On Fri, 27 Oct 2006 11:47:29 -0700
Stephen Hemminger <shemminger@osdl.org> wrote:
> On Fri, 27 Oct 2006 11:42:37 -0700
> Andrew Morton <akpm@osdl.org> wrote:
>
> > From: Andrew Morton <akpm@osdl.org>
> >
> > The multithreaded-probing code has a problem: after one initcall level (eg,
> > core_initcall) has been processed, we will then start processing the next
> > level (postcore_initcall) while the kernel threads which are handling
> > core_initcall are still executing. This breaks the guarantees which the
> > layered initcalls previously gave us.
> >
> > IOW, we want to be multithreaded _within_ an initcall level, but not between
> > different levels.
> >
> > Fix that up by causing the probing code to wait for all outstanding probes at
> > one level to complete before we start processing the next level.
> >
> > Cc: Greg KH <greg@kroah.com>
> > Signed-off-by: Andrew Morton <akpm@osdl.org>
> > ---
> >
>
> This looks like a good place to use a counting semaphore.
>
I couldn't work out a way of doing that. I guess one could a) count the
number of threads which are going to be started, b) start them all, c) do
an up() when each thread ends and d) handle errors somehow.
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: vmlinux.lds: consolidate initcall sections
2006-10-27 19:44 ` Matthew Wilcox
@ 2006-10-27 20:17 ` Andrew Morton
2006-10-27 20:27 ` Matthew Wilcox
0 siblings, 1 reply; 139+ messages in thread
From: Andrew Morton @ 2006-10-27 20:17 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Pavel Machek, Greg KH, Stephen Hemminger, Adrian Bunk,
Linus Torvalds, Linux Kernel Mailing List, linux-pci
On Fri, 27 Oct 2006 13:44:13 -0600
Matthew Wilcox <matthew@wil.cx> wrote:
> On Fri, Oct 27, 2006 at 11:41:44AM -0700, Andrew Morton wrote:
> > Add a vmlinux.lds.h helper macro for defining the eight-level initcall table,
> > teach all the architectures to use it.
>
> > @@ -48,13 +48,7 @@ SECTIONS
> > . = ALIGN(8);
> > __initcall_start = .;
> > .initcall.init : {
> > - *(.initcall1.init)
> > - *(.initcall2.init)
> > - *(.initcall3.init)
> > - *(.initcall4.init)
> > - *(.initcall5.init)
> > - *(.initcall6.init)
> > - *(.initcall7.init)
> > + INITCALLS
> > }
> > __initcall_end = .;
>
> Why not make the INITCALLS macro include more:
>
> +#define INITCALLS \
> + __initcall_start = .; \
> + .initcall.init : { \
> + *(.initcall1.init) \
> + *(.initcall2.init) \
> + *(.initcall3.init) \
> + *(.initcall4.init) \
> + *(.initcall5.init) \
> + *(.initcall6.init) \
> + *(.initcall7.init) \
> + } \
> + __initcall_end = .;
Would be nice, but i386 does:
__initcall_start = .;
.initcall.init : AT(ADDR(.initcall.init) - 0xC0000000) {
*(.initcall1.init)
*(.initcall2.init)
...
> Also, you might want to check the spaces at the front of your INITCALLS
> macro; I see two spaces before the first tab.
thanks.
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: vmlinux.lds: consolidate initcall sections
2006-10-27 20:17 ` Andrew Morton
@ 2006-10-27 20:27 ` Matthew Wilcox
0 siblings, 0 replies; 139+ messages in thread
From: Matthew Wilcox @ 2006-10-27 20:27 UTC (permalink / raw)
To: Andrew Morton
Cc: Pavel Machek, Greg KH, Stephen Hemminger, Adrian Bunk,
Linus Torvalds, Linux Kernel Mailing List, linux-pci
On Fri, Oct 27, 2006 at 01:17:30PM -0700, Andrew Morton wrote:
> Would be nice, but i386 does:
>
> __initcall_start = .;
> .initcall.init : AT(ADDR(.initcall.init) - 0xC0000000) {
> *(.initcall1.init)
Interesting ... but by the looks of SECURITY_INIT, we can support that
by using LOAD_OFFSET ...
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
2006-10-27 20:15 ` Andrew Morton
@ 2006-10-27 20:42 ` Linus Torvalds
2006-10-27 20:48 ` Linus Torvalds
0 siblings, 1 reply; 139+ messages in thread
From: Linus Torvalds @ 2006-10-27 20:42 UTC (permalink / raw)
To: Andrew Morton
Cc: Stephen Hemminger, Pavel Machek, Greg KH, Matthew Wilcox,
Adrian Bunk, Linux Kernel Mailing List, linux-pci
On Fri, 27 Oct 2006, Andrew Morton wrote:
>
> I couldn't work out a way of doing that. I guess one could a) count the
> number of threads which are going to be started, b) start them all, c) do
> an up() when each thread ends and d) handle errors somehow.
No. First off, you want to _limit_ the maximum number of parallelism
anyway (memory pressure and sanity), so you want to use the counting
semaphore for that too.
The easiest way to do it would probably be something like this:
#define PARALLELISM (10)
static struct semaphore outstanding;
struct thread_exec {
int (*fn)(void *);
void *arg;
struct completion completion;
};
static void allow_parallel(int n)
{
while (--n >= 0)
up(&outstanding);
}
static void wait_for_parallel(int n)
{
while (--n >= 0)
down(&outstanding);
}
static int do_in_parallel(void *arg)
{
struct thread_exec *p = arg;
int (*fn)(void *) = p->fn;
void *arg = p->arg;
int retval;
/* Tell the caller we are done with the arguments */
complete(&p->completion);
/* Do the actual work in parallel */
retval = p->fn(p->arg);
/*
* And then tell the rest of the world that we've
* got one less parallel thing outstanding..
*/
up(&outstanding);
return retval;
}
static void execute_in_parallel(int (*fn)(void *), void *arg)
{
struct thread_exec arg = { .fn = fn, .arg = arg };
/* Make sure we can have more outstanding parallel work */
down(&outstanding);
arg.fn = fn;
arg.arg = arg;
init_completion(&arg.completion);
kernel_thread(do_in_parallel, &arg);
/* We need to wait until our "arg" is safe */
wait_for_completion(&arg.completion)
}
The above is ENTIRELY UNTESTED, but the point of it is that it should now
allow you to do something like this:
/* Set up how many parallel threads we can run */
allow_parallel(PARALLELISM);
...
/*
* Run an arbitrary number of threads with that
* parallelism.
*/
for (i = 0; i < ... ; i++)
execute_in_parallel(fnarray[i].function,
fnarray[i].argument);
...
/* And wait for all of them to complete */
wait_for_parallel(PARALLELISM);
and this is totally generic (ie this is useful for initcalls or anything
else). Note also how you can set up the parallelism (and wait for it)
totally independently (ie that can be done at some earlier stage, and the
"execute_in_parallel()" can just be executed in any random situation in
between - as many times as you like. It will always honor the parallelism.
By setting PARALLELISM to 1, you basically only ever allow one outstanding
call at any time (ie it becomes serial), so you don't even have to make
this a config option, you could do it as a runtime setup thing.
Hmm?
(And I repeat: the above code is untested, and was written in the email
client. It has never seen a compiler, and not gotten a _whole_ lot of
thinking).
Linus
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
2006-10-27 20:42 ` Linus Torvalds
@ 2006-10-27 20:48 ` Linus Torvalds
2006-10-28 1:11 ` Greg KH
0 siblings, 1 reply; 139+ messages in thread
From: Linus Torvalds @ 2006-10-27 20:48 UTC (permalink / raw)
To: Andrew Morton
Cc: Stephen Hemminger, Pavel Machek, Greg KH, Matthew Wilcox,
Adrian Bunk, Linux Kernel Mailing List, linux-pci
On Fri, 27 Oct 2006, Linus Torvalds wrote:
>
> static int do_in_parallel(void *arg)
> {
> struct thread_exec *p = arg;
> int (*fn)(void *) = p->fn;
> void *arg = p->arg;
> int retval;
>
> /* Tell the caller we are done with the arguments */
> complete(&p->completion);
>
> /* Do the actual work in parallel */
> retval = p->fn(p->arg);
Duh. The whole reason I copied them was to _not_ do that. That last line
should obviously be
retval = fn(arg);
because "p" may gone after we've done the "complete()".
> (And I repeat: the above code is untested, and was written in the email
> client. It has never seen a compiler, and not gotten a _whole_ lot of
> thinking).
.. This hasn't changed, I just looked through the code once and found that
obvious bug.
Linus
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN
2006-10-27 17:07 ` Greg KH
2006-10-27 17:22 ` Pavel Machek
@ 2006-10-27 22:23 ` Adrian Bunk
2006-10-27 22:38 ` Andrew Morton
2006-10-27 23:03 ` Alan Cox
2006-10-27 22:57 ` Alan Cox
2 siblings, 2 replies; 139+ messages in thread
From: Adrian Bunk @ 2006-10-27 22:23 UTC (permalink / raw)
To: Greg KH
Cc: Stephen Hemminger, Andrew Morton, Matthew Wilcox, Linus Torvalds,
Linux Kernel Mailing List, Pavel Machek, linux-pci
On Fri, Oct 27, 2006 at 10:07:48AM -0700, Greg KH wrote:
> On Thu, Oct 26, 2006 at 07:11:31PM -0700, Stephen Hemminger wrote:
> > On Thu, 26 Oct 2006 18:28:38 -0700
> > Andrew Morton <akpm@osdl.org> wrote:
> >
> > > On Thu, 26 Oct 2006 19:20:58 -0600
> > > Matthew Wilcox <matthew@wil.cx> wrote:
> > >
> > > > On Fri, Oct 27, 2006 at 03:02:52AM +0200, Adrian Bunk wrote:
> > > > > PCI_MULTITHREAD_PROBE is an interesting feature, but in it's current
> > > > > state it seems to be more of a trap for users who accidentally
> > > > > enable it.
> > > > >
> > > > > This patch lets PCI_MULTITHREAD_PROBE depend on BROKEN for 2.6.19.
> > > > >
> > > > > The intention is to get this patch reversed in -mm as soon as it's in
> > > > > Linus' tree, and reverse it for 2.6.20 or 2.6.21 after the fallout of
> > > > > in-kernel problems PCI_MULTITHREAD_PROBE causes got fixed.
> > > >
> > > > People who enable features clearly marked as EXPERIMENTAL deserve what
> > > > they get, IMO.
> > >
> > > It's not the impact on "people" which is of concern - it's the impact on
> > > kernel developers - specifically those who spend time looking at bug
> > > reports :(
> >
> > Either it is broken and should be removed, or is barely working and
> > should be fixed. If Greg wants to take bug reports then it can stay.
>
> I want to keep taking bug reports.
>
> I've found only 1 real bug from all of this. The pci MSI initialization
> issue. It's on my queue of things to fix. Andrew has also sent me
> another "interesting" patch about making sure devices are found by the
> time we hit another init level which I'll see about adding too.
>
> But that MSI bug was a real bug, which is good to have found. It's also
> found other real bugs in other subsystems that could easily be hit by
> other users.
>
> So no, this should not be marked BROKEN.
>
> It's a very experimental feature, as the help text says. If you can
> think of any harsher language to put in that text, please let me know.
The problem is that if only 1 out of 100 people who are compiling a
kernel accidentally enable this option, linux-kernel will be swamped
with bug reports...
If it shouldn't be enabled by users, the only correct language is a
dependency on BROKEN.
And it doesn't matter whether PCI_MULTITHREAD_PROBE itself is buggy or
whether it only exposes latent bugs in other subsystems - the effect is
the same.
> And yes, there also has been a proposed change to the driver core to fix
> up how the multi-thread stuff works that looks very good, but it's down
> in my queue that I'm trying to catch up on right now.
>
> So consider this a NAK for this change.
>
> thanks,
>
> greg k-h
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN
2006-10-27 22:23 ` [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN Adrian Bunk
@ 2006-10-27 22:38 ` Andrew Morton
2006-10-28 1:08 ` Greg KH
2006-10-27 23:03 ` Alan Cox
1 sibling, 1 reply; 139+ messages in thread
From: Andrew Morton @ 2006-10-27 22:38 UTC (permalink / raw)
To: Adrian Bunk
Cc: Greg KH, Stephen Hemminger, Matthew Wilcox, Linus Torvalds,
Linux Kernel Mailing List, Pavel Machek, linux-pci
On Sat, 28 Oct 2006 00:23:26 +0200
Adrian Bunk <bunk@stusta.de> wrote:
> ...
> > So no, this should not be marked BROKEN.
> >
> > It's a very experimental feature, as the help text says. If you can
> > think of any harsher language to put in that text, please let me know.
>
> The problem is that if only 1 out of 100 people who are compiling a
> kernel accidentally enable this option, linux-kernel will be swamped
> with bug reports...
>
Yes, that's a legitimate practical concern, IMO.
I guess many of the people who test -rc kernels have sufficient familarity
to know to disable this option, but a lot of the people who test major
releases do not. So how about we mark PCI_MULTITHREAD_PROBE as broken in
2.6.19-rc6, then revert that change in 2.6.20-rc1, and keep doing that
until the feature is ready?
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN
2006-10-27 17:07 ` Greg KH
2006-10-27 17:22 ` Pavel Machek
2006-10-27 22:23 ` [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN Adrian Bunk
@ 2006-10-27 22:57 ` Alan Cox
2 siblings, 0 replies; 139+ messages in thread
From: Alan Cox @ 2006-10-27 22:57 UTC (permalink / raw)
To: Greg KH
Cc: Stephen Hemminger, Andrew Morton, Matthew Wilcox, Adrian Bunk,
Linus Torvalds, Linux Kernel Mailing List, Pavel Machek,
linux-pci
Ar Gwe, 2006-10-27 am 10:07 -0700, ysgrifennodd Greg KH:
> It's a very experimental feature, as the help text says. If you can
> think of any harsher language to put in that text, please let me know.
The ATA drivers use text like (RAVING LUNATIC) for such things.
Realistically right now the multithread_probe stuff is useless because
your hardware ends up randomly re-ordered and everything breaks.
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
2006-10-27 18:42 ` [patch] drivers: wait for threaded probes between initcall levels Andrew Morton
2006-10-27 18:47 ` Stephen Hemminger
@ 2006-10-27 22:59 ` Alan Cox
2006-10-27 23:06 ` Andrew Morton
2006-10-27 23:12 ` Olaf Hering
1 sibling, 2 replies; 139+ messages in thread
From: Alan Cox @ 2006-10-27 22:59 UTC (permalink / raw)
To: Andrew Morton
Cc: Pavel Machek, Greg KH, Stephen Hemminger, Matthew Wilcox,
Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List, linux-pci
Ar Gwe, 2006-10-27 am 11:42 -0700, ysgrifennodd Andrew Morton:
> IOW, we want to be multithreaded _within_ an initcall level, but not between
> different levels.
Thats actually insufficient. We have link ordered init sequences in
large numbers of driver subtrees (ATA, watchdog, etc). We'll need
several more initcall layers to fix that.
Alan
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN
2006-10-27 22:23 ` [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN Adrian Bunk
2006-10-27 22:38 ` Andrew Morton
@ 2006-10-27 23:03 ` Alan Cox
1 sibling, 0 replies; 139+ messages in thread
From: Alan Cox @ 2006-10-27 23:03 UTC (permalink / raw)
To: Adrian Bunk
Cc: Greg KH, Stephen Hemminger, Andrew Morton, Matthew Wilcox,
Linus Torvalds, Linux Kernel Mailing List, Pavel Machek,
linux-pci
Ar Sad, 2006-10-28 am 00:23 +0200, ysgrifennodd Adrian Bunk:
> The problem is that if only 1 out of 100 people who are compiling a
> kernel accidentally enable this option, linux-kernel will be swamped
> with bug reports...
>
> If it shouldn't be enabled by users, the only correct language is a
> dependency on BROKEN.
If Greg insists of NAKking this then will you please make IDE and ATA at
least dependant on !MULTITHREADED_PROBE, as neither are safe with it
selected.
No I've no idea how you will boot a box with Greg's stuff after that
either, but I'm just pointing out the correct dependancies as the code
stands today.
Alan
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
2006-10-27 22:59 ` Alan Cox
@ 2006-10-27 23:06 ` Andrew Morton
2006-10-28 5:09 ` Grant Grundler
2006-10-30 9:44 ` Cornelia Huck
2006-10-27 23:12 ` Olaf Hering
1 sibling, 2 replies; 139+ messages in thread
From: Andrew Morton @ 2006-10-27 23:06 UTC (permalink / raw)
To: Alan Cox
Cc: Pavel Machek, Greg KH, Stephen Hemminger, Matthew Wilcox,
Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List, linux-pci
On Fri, 27 Oct 2006 23:59:30 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> Ar Gwe, 2006-10-27 am 11:42 -0700, ysgrifennodd Andrew Morton:
> > IOW, we want to be multithreaded _within_ an initcall level, but not between
> > different levels.
>
> Thats actually insufficient. We have link ordered init sequences in
> large numbers of driver subtrees (ATA, watchdog, etc). We'll need
> several more initcall layers to fix that.
>
It would be nice to express those dependencies in some clearer and less
fragile manner than link order. I guess finer-grained initcall levels
would do that, but it doesn't scale very well.
But whatever. I think multithreaded probing just doesn't pass the
benefit-versus-hassle test, sorry. Make it dependent on CONFIG_GREGKH ;)
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
2006-10-27 22:59 ` Alan Cox
2006-10-27 23:06 ` Andrew Morton
@ 2006-10-27 23:12 ` Olaf Hering
1 sibling, 0 replies; 139+ messages in thread
From: Olaf Hering @ 2006-10-27 23:12 UTC (permalink / raw)
To: Alan Cox
Cc: Andrew Morton, Pavel Machek, Greg KH, Stephen Hemminger,
Matthew Wilcox, Adrian Bunk, Linus Torvalds,
Linux Kernel Mailing List, linux-pci
On Fri, Oct 27, Alan Cox wrote:
> Ar Gwe, 2006-10-27 am 11:42 -0700, ysgrifennodd Andrew Morton:
> > IOW, we want to be multithreaded _within_ an initcall level, but not between
> > different levels.
>
> Thats actually insufficient. We have link ordered init sequences in
> large numbers of driver subtrees (ATA, watchdog, etc). We'll need
> several more initcall layers to fix that.
Is it time for something better?
True dependencies, an addition to or as replacement for module_init()?
random example: hfs/super.c:
depends_on_initialized(init_hfs_fs: init_hfsplus_fs,kmem_cache_thingie,core_filesystem_thingie,foo,bar,worldpeace);
If init_hfsplus_fs() does not exist it should be no error.
Whatever the sytax will be and however its parsed during build, that link order
requirement bites every other month.
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN
2006-10-27 22:38 ` Andrew Morton
@ 2006-10-28 1:08 ` Greg KH
0 siblings, 0 replies; 139+ messages in thread
From: Greg KH @ 2006-10-28 1:08 UTC (permalink / raw)
To: Andrew Morton
Cc: Adrian Bunk, Stephen Hemminger, Matthew Wilcox, Linus Torvalds,
Linux Kernel Mailing List, Pavel Machek, linux-pci
On Fri, Oct 27, 2006 at 03:38:54PM -0700, Andrew Morton wrote:
> On Sat, 28 Oct 2006 00:23:26 +0200
> Adrian Bunk <bunk@stusta.de> wrote:
>
> > ...
> > > So no, this should not be marked BROKEN.
> > >
> > > It's a very experimental feature, as the help text says. If you can
> > > think of any harsher language to put in that text, please let me know.
> >
> > The problem is that if only 1 out of 100 people who are compiling a
> > kernel accidentally enable this option, linux-kernel will be swamped
> > with bug reports...
> >
>
> Yes, that's a legitimate practical concern, IMO.
>
> I guess many of the people who test -rc kernels have sufficient familarity
> to know to disable this option, but a lot of the people who test major
> releases do not. So how about we mark PCI_MULTITHREAD_PROBE as broken in
> 2.6.19-rc6, then revert that change in 2.6.20-rc1, and keep doing that
> until the feature is ready?
Ok, I can live with that. I'll send in a change for this with the next
round of driver core fixes.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
2006-10-27 20:48 ` Linus Torvalds
@ 2006-10-28 1:11 ` Greg KH
2006-10-28 1:50 ` Linus Torvalds
0 siblings, 1 reply; 139+ messages in thread
From: Greg KH @ 2006-10-28 1:11 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andrew Morton, Stephen Hemminger, Pavel Machek, Matthew Wilcox,
Adrian Bunk, Linux Kernel Mailing List, linux-pci
On Fri, Oct 27, 2006 at 01:48:54PM -0700, Linus Torvalds wrote:
>
>
> On Fri, 27 Oct 2006, Linus Torvalds wrote:
>
> >
> > static int do_in_parallel(void *arg)
> > {
> > struct thread_exec *p = arg;
> > int (*fn)(void *) = p->fn;
> > void *arg = p->arg;
> > int retval;
> >
> > /* Tell the caller we are done with the arguments */
> > complete(&p->completion);
> >
> > /* Do the actual work in parallel */
> > retval = p->fn(p->arg);
>
> Duh. The whole reason I copied them was to _not_ do that. That last line
> should obviously be
>
> retval = fn(arg);
>
> because "p" may gone after we've done the "complete()".
>
> > (And I repeat: the above code is untested, and was written in the email
> > client. It has never seen a compiler, and not gotten a _whole_ lot of
> > thinking).
>
> .. This hasn't changed, I just looked through the code once and found that
> obvious bug.
Heh, ok, I'll take this idea, and Andrew's patch, and rework things for
the next round of 2.6.20-rc kernels, and mark the current stuff as
BROKEN for now.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
2006-10-28 1:11 ` Greg KH
@ 2006-10-28 1:50 ` Linus Torvalds
0 siblings, 0 replies; 139+ messages in thread
From: Linus Torvalds @ 2006-10-28 1:50 UTC (permalink / raw)
To: Greg KH
Cc: Andrew Morton, Stephen Hemminger, Pavel Machek, Matthew Wilcox,
Adrian Bunk, Linux Kernel Mailing List, linux-pci
On Fri, 27 Oct 2006, Greg KH wrote:
>
> Heh, ok, I'll take this idea, and Andrew's patch, and rework things for
> the next round of 2.6.20-rc kernels, and mark the current stuff as
> BROKEN for now.
My interface stuff is kind of designed for:
- keep the current "init" sequence as-is for now
- keep the _actual_ PCI probing non-parallel, so that we actually do all
the bus _discovery_ in a repeatable and sane order.
- use the new "execute_in_parallel()" interface for things that actually
_sleep_. For example, all the PCI IDE _driver_ attachement should be
done synchronously, but perhaps the code that tries to see if there are
actual disks (ie the stuff that has timeouts etc) can use the parallel
execution.
- module loading would do a "allow_parallel(1)" and
"wait_for_parallel(1)" thing when calling the module init function (so
that a module could use "execute_in_parallel()" whether compiled in or
not, and each "init level" at boot would also do this (with some bigger
number, like 10), so that for drivers etc that want to do async stuff,
they can do so in parallel (but they'd still have done the actual hard
device find/init serially - keeping the link order relevant for things
like IDE controller discovery)
How does this sound?
There's really no reason to parallelise the actual PCI config cycles and
probing and stuff. It's only when some driver knows that it might have to
do some longer-running thing that it might want to execute a thread in
parallel with other things - but it still needs to be done in a controlled
situation, so that when "driver_init()" stops and "filesystem_init()"
starts, we must wait for all the driver-init parallel tasks to finish
(since "filesystem_init()" is allowed to depend on them).
Hmm?
Linus
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
2006-10-27 23:06 ` Andrew Morton
@ 2006-10-28 5:09 ` Grant Grundler
2006-10-28 5:19 ` Andrew Morton
2006-10-30 9:44 ` Cornelia Huck
1 sibling, 1 reply; 139+ messages in thread
From: Grant Grundler @ 2006-10-28 5:09 UTC (permalink / raw)
To: Andrew Morton
Cc: Alan Cox, Pavel Machek, Greg KH, Stephen Hemminger,
Matthew Wilcox, Adrian Bunk, Linus Torvalds,
Linux Kernel Mailing List, linux-pci
On Fri, Oct 27, 2006 at 04:06:26PM -0700, Andrew Morton wrote:
> On Fri, 27 Oct 2006 23:59:30 +0100
> Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> > Ar Gwe, 2006-10-27 am 11:42 -0700, ysgrifennodd Andrew Morton:
> > > IOW, we want to be multithreaded _within_ an initcall level, but not between
> > > different levels.
> >
> > Thats actually insufficient. We have link ordered init sequences in
> > large numbers of driver subtrees (ATA, watchdog, etc). We'll need
> > several more initcall layers to fix that.
> >
>
> It would be nice to express those dependencies in some clearer and less
> fragile manner than link order. I guess finer-grained initcall levels
> would do that, but it doesn't scale very well.
Would making use of depmod data be a step in the right direction?
ie nic driver calls extern function (e.g. pci_enable_device())
and therefore must depend on module which provides that function.
My guess is this probably isn't 100% sufficient to replace all initcall
levels. But likely sufficient within a given initcall level.
My main concern are circular dependencies (which are rare).
> But whatever. I think multithreaded probing just doesn't pass the
> benefit-versus-hassle test, sorry. Make it dependent on CONFIG_GREGKH ;)
Isn't already? :)
I thought parallel PCI and SCSI probing on system with multiple NICs and
"SCSI" storage requires udev to create devices with consistent naming.
thanks,
grant
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
2006-10-28 5:09 ` Grant Grundler
@ 2006-10-28 5:19 ` Andrew Morton
2006-10-28 5:32 ` Andrew Morton
2006-10-28 6:08 ` Grant Grundler
0 siblings, 2 replies; 139+ messages in thread
From: Andrew Morton @ 2006-10-28 5:19 UTC (permalink / raw)
To: Grant Grundler
Cc: Alan Cox, Pavel Machek, Greg KH, Stephen Hemminger,
Matthew Wilcox, Adrian Bunk, Linus Torvalds,
Linux Kernel Mailing List, linux-pci
On Fri, 27 Oct 2006 23:09:05 -0600
Grant Grundler <grundler@parisc-linux.org> wrote:
> On Fri, Oct 27, 2006 at 04:06:26PM -0700, Andrew Morton wrote:
> > On Fri, 27 Oct 2006 23:59:30 +0100
> > Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> >
> > > Ar Gwe, 2006-10-27 am 11:42 -0700, ysgrifennodd Andrew Morton:
> > > > IOW, we want to be multithreaded _within_ an initcall level, but not between
> > > > different levels.
> > >
> > > Thats actually insufficient. We have link ordered init sequences in
> > > large numbers of driver subtrees (ATA, watchdog, etc). We'll need
> > > several more initcall layers to fix that.
> > >
> >
> > It would be nice to express those dependencies in some clearer and less
> > fragile manner than link order. I guess finer-grained initcall levels
> > would do that, but it doesn't scale very well.
>
> Would making use of depmod data be a step in the right direction?
Nope. The linkage-order problem is by definition applicable to
linked-into-vmlinux code, not to modules.
> ie nic driver calls extern function (e.g. pci_enable_device())
> and therefore must depend on module which provides that function.
>
> My guess is this probably isn't 100% sufficient to replace all initcall
> levels. But likely sufficient within a given initcall level.
> My main concern are circular dependencies (which are rare).
The simplest implementation of "A needs B to have run" is for A to simply
call B, and B arranges to not allow itself to be run more than once.
But that doesn't work in the case "A needs B to be run, but only if B is
present". Resolving this one would require something like a fancy
"synchronisation object" against which dependers and dependees can register
interest, and a core engine which takes care of the case where a depender
registers against something which no dependees have registered.
The mind boggles.
> > But whatever. I think multithreaded probing just doesn't pass the
> > benefit-versus-hassle test, sorry. Make it dependent on CONFIG_GREGKH ;)
>
> Isn't already? :)
>
> I thought parallel PCI and SCSI probing on system with multiple NICs and
> "SCSI" storage requires udev to create devices with consistent naming.
For some reason people get upset when we rename all their devices. They're
a humourless lot.
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
2006-10-28 5:19 ` Andrew Morton
@ 2006-10-28 5:32 ` Andrew Morton
2006-10-28 6:08 ` Grant Grundler
1 sibling, 0 replies; 139+ messages in thread
From: Andrew Morton @ 2006-10-28 5:32 UTC (permalink / raw)
To: Grant Grundler, Alan Cox, Pavel Machek, Greg KH,
Stephen Hemminger, Matthew Wilcox, Adrian Bunk, Linus Torvalds,
Linux Kernel Mailing List, linux-pci
On Fri, 27 Oct 2006 22:19:25 -0700
Andrew Morton <akpm@osdl.org> wrote:
> The simplest implementation of "A needs B to have run" is for A to simply
> call B, and B arranges to not allow itself to be run more than once.
>
> But that doesn't work in the case "A needs B to be run, but only if B is
> present". Resolving this one would require something like a fancy
> "synchronisation object" against which dependers and dependees can register
> interest, and a core engine which takes care of the case where a depender
> registers against something which no dependees have registered.
otoh, we could stick with the simple "A calls B" solution, and A also
provides an attribute-weak implementation of B to cover the "A needs B but
only if B is present" problems.
Had to say, really - one would need to study some specific problem cases.
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
2006-10-28 5:19 ` Andrew Morton
2006-10-28 5:32 ` Andrew Morton
@ 2006-10-28 6:08 ` Grant Grundler
2006-10-28 20:48 ` Stefan Richter
1 sibling, 1 reply; 139+ messages in thread
From: Grant Grundler @ 2006-10-28 6:08 UTC (permalink / raw)
To: Andrew Morton
Cc: Grant Grundler, Alan Cox, Pavel Machek, Greg KH,
Stephen Hemminger, Matthew Wilcox, Adrian Bunk, Linus Torvalds,
Linux Kernel Mailing List, linux-pci
On Fri, Oct 27, 2006 at 10:19:25PM -0700, Andrew Morton wrote:
> > > It would be nice to express those dependencies in some clearer and less
> > > fragile manner than link order. I guess finer-grained initcall levels
> > > would do that, but it doesn't scale very well.
> >
> > Would making use of depmod data be a step in the right direction?
>
> Nope. The linkage-order problem is by definition applicable to
> linked-into-vmlinux code, not to modules.
But wouldn't the same concept apply to non-module symbols that
are tagged with EXPORT_SYMBOL()?
Maybe I'm just showing my ignorance about kernel linking here...
> > ie nic driver calls extern function (e.g. pci_enable_device())
> > and therefore must depend on module which provides that function.
> >
> > My guess is this probably isn't 100% sufficient to replace all initcall
> > levels. But likely sufficient within a given initcall level.
> > My main concern are circular dependencies (which are rare).
>
> The simplest implementation of "A needs B to have run" is for A to simply
> call B, and B arranges to not allow itself to be run more than once.
Yes. we already have code like this in the kernel.
e.g. superio support in drivers/parisc.
> But that doesn't work in the case "A needs B to be run, but only if B is
> present".
I was thinking of "A is present and calls into module B, therefore B needs
to init first". In this case, A won't care if B is really present or not.
A depends on B to figure that out at runtime. If B is not configured into
the kernel, A won't ever call B since the "function" will be a NOP.
(e.g. #ifndef CONFIG_B/#define b_service() /* NOP */ /#endif)
> Resolving this one would require something like a fancy
> "synchronisation object" against which dependers and dependees can register
> interest, and a core engine which takes care of the case where a depender
> registers against something which no dependees have registered.
I guess I was wondering if the kernel link step could use symbol information
in a similar way the kernel module autoloader uses depmod info. But other
parts of the kernel might not be as modular as most of the IO subsystems
are.
I'm not looking for ways to make the process more complicated for
the people maintaining code. Keeping the registrations of dependencies
up-to-date manually would just be another PITA.
...
> > I thought parallel PCI and SCSI probing on system with multiple NICs and
> > "SCSI" storage requires udev to create devices with consistent naming.
>
> For some reason people get upset when we rename all their devices. They're
> a humourless lot.
Hey! I resemble that remark! ;)
(yeah, I've been a victim of that problem way too many times.)
thanks,
grant
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
@ 2006-10-28 8:23 Adam J. Richter
2006-10-28 9:22 ` Russell King
2006-10-28 19:41 ` Linus Torvalds
0 siblings, 2 replies; 139+ messages in thread
From: Adam J. Richter @ 2006-10-28 8:23 UTC (permalink / raw)
To: torvalds
Cc: akpm, bunk, greg, linux-kernel, linux-pci, matthew, pavel,
shemminger
On Fri, 27 Oct 2006 13:42:44 -0700 (PDT), Linus Torvals wrote:
> static struct semaphore outstanding;
[...]
> static void allow_parallel(int n)
[...]
> static void wait_for_parallel(int n)
[...]
> static void execute_in_parallel(int (*fn)(void *), void *arg)
This interface would have problems with nesting.
As a realistic example of nesting, imagine if this facility were
used for initcalls, and one of those initcalls also used this facility to
attempt parallel initialization of several hardware devices attached
to some bus. In this scenario, do_initcalls would call allow_parallelism(10),
and then one of the initcalls that wanted to spawn its own set of
parallel processes would also call allow_parallel(10) (unintentionally
making the number of allowed processes 20), kick off its parallel
processes, and then call wait_for_parallel(), which could return
prematurely, which could easily lead to one of the child threads that
was incorrectly assumed to have finished to then corrupt memory or do any
number of other things that leads to a crash that is not reliably
reproducible.
Here are some possible ways to address this problem, and
their drawbacks.
1. Just document that nesting is prohibited, adding some BUG()
test to prevent such use. This would limit the usefulness of this
facility, and create some unnecessary coordination issues among
kernel developers in arguing policy over who gets to use this facility.
2. Turn the "outstanding" counting semaphore into a parameter.
Each group of related threads would share this parameter. For example,
do_initcalls might look something like this:
struct semaphore initcalls_sem = SEMAPHORE_INITIALIZER(...);
allow_parallel(PARALLELISM, &initcalls_sem);
for (call = __initcall_start; call < __initcall_end; call++)
execute_in_parallel(call, NULL, &initcalls_sem);
wait_for_parallel(PARALLEISM, &initcalls_sem);
The drawback of this solution is that the limitation on the total
number of parallel processes is not global. So, the number of
parallel processes in a nesting situation could get quite high.
For example, if 10 top level threads each initiated another 10
secondary threads, that's up to 111 threads with just a nesting
depth of 2.
3. Add an rw_semaphore passed as a parameter for
wait_for_parallelism, but keep original static semaphore for limiting
the parallelism. wait_for_parallel would be the only function ever
to block on the rw_semaphore, so that should avoid any problem with
ordering of taking the two semaphores--I think.
This solution deadlocks if the nesting depth exceeds the maximum
number of threads allowed, which could realistically occur when the maximum
parallelism allowed is 1.
4. Same as #3, but also increase the global thread count by 1 on
every call to allow_parallel, and decrease it by one in the matching
wait_for_parallel. The drawback here is that setting the global
number of threads to one at the outset would no longer guarantee
strict serial execution, which is minor compared to the other
problems listed above. If we want to guarantee serial execution
when PARALLELISM=1, I think that can be arranged with a little more
complexity, but I'd like to know if that is actually important.
I have attached an example of approach #4 below, also completely
untested, with no attempt made to try to compile it.
Adam Richter
#define PARALLELISM (10)
static struct semaphore outstanding;
struct thread_exec {
int (*fn)(void *);
void *arg;
struct completion args_copied;
struct rw_semaphore *fn_done;
};
/* In some .h file: */
static inline void start_parallel(void)
{
up(&outstanding);
}
/* In some .h file: */
static inline void wait_for_parallel(struct rw_semaphore *fn_done)
{
down_write(fn_done);
down(&outstanding);
}
void allow_parallel(int n) /* called once, at boot time */
{
while (--n >= 0)
up(&outstanding);
}
static int do_in_parallel(void *arg)
{
struct thread_exec *p = arg;
int (*fn)(void *) = p->fn;
void *arg = p->arg;
struct rw_semaphore *fn_done = p->fn_done;
int retval;
/* Tell the caller we are done with the arguments */
complete(&p->args_copied);
/* Do the actual work in parallel */
retval = p->fn(p->arg);
/*
* And then tell the rest of the world that we've
* got one less parallel thing outstanding..
*/
up_read(fn_done);
up(&outstanding);
return retval;
}
void execute_in_parallel(int (*fn)(void *),
void *arg,
struct semaphore *fn_done)
{
struct thread_exec arg = { .fn = fn, .arg = arg };
/* Make sure we can have more outstanding parallel work */
down(&outstanding);
arg.fn = fn;
arg.arg = arg;
arg.fn_done = fn_done;
down_read(fn_done);
init_completion(&arg.args_copied);
kernel_thread(do_in_parallel, &arg);
wait_for_completion(&arg.args_copied)
}
Example of usage:
/* Earlier in the boot process... */
allow_parallel(PARALLELISM);
static void __init do_initcalls(void)
{
DECLARE_RWSEM(initcalls_done);
start_parallel();
for (call = __initcall_start; call < __initcall_end; call++)
execute_in_parallel(call, NULL, &initcalls_done);
wait_for_parallel(&initcalls_done);
}
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
2006-10-28 8:23 [patch] drivers: wait for threaded probes between initcall levels Adam J. Richter
@ 2006-10-28 9:22 ` Russell King
2006-10-28 12:10 ` Russell King
2006-10-28 19:41 ` Linus Torvalds
1 sibling, 1 reply; 139+ messages in thread
From: Russell King @ 2006-10-28 9:22 UTC (permalink / raw)
To: Adam J. Richter
Cc: torvalds, akpm, bunk, greg, linux-kernel, linux-pci, matthew,
pavel, shemminger
On Sat, Oct 28, 2006 at 04:23:35PM +0800, Adam J. Richter wrote:
> This interface would have problems with nesting.
Adam (and the rest of the parallel crowd),
Just a passing thought (and nothing more)...
How does this behave with PCMCIA initialisation with a Cardbus card
inserted?
This is one scenario which needs checking before any of this parallel
probe code goes anywhere near mainline, since it's possible for the
Cardbus (PCI) device to be added and therefore probed while the Yenta
probe (PCI) is still running.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled
2006-10-25 23:58 ` [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled Randy Dunlap
2006-10-26 2:22 ` David Brownell
2006-10-26 15:46 ` [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled Adrian Bunk
@ 2006-10-28 11:21 ` Christoph Hellwig
2006-10-28 21:10 ` David Brownell
2 siblings, 1 reply; 139+ messages in thread
From: Christoph Hellwig @ 2006-10-28 11:21 UTC (permalink / raw)
To: Randy Dunlap
Cc: David Brownell, toralf.foerster, netdev, linux-usb-devel, link,
greg, akpm, zippel, torvalds, linux-kernel, dbrownell
On Wed, Oct 25, 2006 at 04:58:58PM -0700, Randy Dunlap wrote:
> On Wed, 25 Oct 2006 15:27:09 -0700 David Brownell wrote:
>
> > Instead, "usbnet.c" should #ifdef the relevant ethtool hooks
> > according to CONFIG_MII ... since it's completely legit to
> > use usbnet with peripherals that don't need MII.
>
> ---
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> usbnet driver should use mii_*() interfaces if they are available
> in the kernel (config enabled) but usbnet does not require or depend
> on these interfaces.
>
> Build tested with CONFIG_MII=y, m, n.
This is really awkward and against what we do in any other driver.
Lots of PCI ethernet drivers use the MII code but have non-MII variants,
and I'd expect usb code to do the same. If you really need to squeeze
the last bytes out of usbnet for some embedded thing add a CONFIG_USB_NET_MII
opention and explain in the help text which devices require it. Otherwise
a normal user has no way to find out why his mii-requiring usb device
randomly stopped working.
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> ---
> drivers/usb/net/usbnet.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> --- linux-2619-rc3-pv.orig/drivers/usb/net/usbnet.c
> +++ linux-2619-rc3-pv/drivers/usb/net/usbnet.c
> @@ -47,6 +47,12 @@
>
> #define DRIVER_VERSION "22-Aug-2005"
>
> +#if defined(CONFIG_MII) || defined(CONFIG_MII_MODULE)
> +#define HAVE_MII 1
> +#else
> +#define HAVE_MII 0
> +#endif
> +
>
> /*-------------------------------------------------------------------------*/
>
> @@ -676,7 +682,10 @@ int usbnet_get_settings (struct net_devi
> if (!dev->mii.mdio_read)
> return -EOPNOTSUPP;
>
> +#if HAVE_MII
> return mii_ethtool_gset(&dev->mii, cmd);
> +#endif
> + return -EOPNOTSUPP;
> }
> EXPORT_SYMBOL_GPL(usbnet_get_settings);
>
> @@ -688,7 +697,11 @@ int usbnet_set_settings (struct net_devi
> if (!dev->mii.mdio_write)
> return -EOPNOTSUPP;
>
> +#if HAVE_MII
> retval = mii_ethtool_sset(&dev->mii, cmd);
> +#else
> + retval = -EOPNOTSUPP;
> +#endif
>
> /* link speed/duplex might have changed */
> if (dev->driver_info->link_reset)
> @@ -721,9 +734,11 @@ u32 usbnet_get_link (struct net_device *
> if (dev->driver_info->check_connect)
> return dev->driver_info->check_connect (dev) == 0;
>
> +#if HAVE_MII
> /* if the device has mii operations, use those */
> if (dev->mii.mdio_read)
> return mii_link_ok(&dev->mii);
> +#endif
>
> /* Otherwise, say we're up (to avoid breaking scripts) */
> return 1;
> @@ -753,7 +768,10 @@ int usbnet_nway_reset(struct net_device
> if (!dev->mii.mdio_write)
> return -EOPNOTSUPP;
>
> +#if HAVE_MII
> return mii_nway_restart(&dev->mii);
> +#endif
> + return -EOPNOTSUPP;
> }
> EXPORT_SYMBOL_GPL(usbnet_nway_reset);
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
---end quoted text---
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
2006-10-28 9:22 ` Russell King
@ 2006-10-28 12:10 ` Russell King
0 siblings, 0 replies; 139+ messages in thread
From: Russell King @ 2006-10-28 12:10 UTC (permalink / raw)
To: Adam J. Richter
Cc: torvalds, akpm, bunk, greg, linux-kernel, linux-pci, matthew,
pavel, shemminger
On Sat, Oct 28, 2006 at 10:22:54AM +0100, Russell King wrote:
> On Sat, Oct 28, 2006 at 04:23:35PM +0800, Adam J. Richter wrote:
> > This interface would have problems with nesting.
>
> Adam (and the rest of the parallel crowd),
>
> Just a passing thought (and nothing more)...
>
> How does this behave with PCMCIA initialisation with a Cardbus card
> inserted?
>
> This is one scenario which needs checking before any of this parallel
> probe code goes anywhere near mainline, since it's possible for the
> Cardbus (PCI) device to be added and therefore probed while the Yenta
> probe (PCI) is still running.
Can someone make sure Adam gets my email please? His server rejects
messages from my domain:
adam@yggdrasil.com
SMTP error from remote mail server after MAIL FROM:<rmk+adam=yggdrasil.com@arm.linux.org.uk> SIZE=3022:
host yggdrasil.com [61.49.148.168]: 553 5.1.8 <rmk+adam=yggdrasil.com@arm.linux.org.uk>... Domain of sender address rmk+adam=yggdrasil.com@arm.linux.org.uk does not exist
(the error is obviously utter rubbish.)
Thanks.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
2006-10-28 8:23 [patch] drivers: wait for threaded probes between initcall levels Adam J. Richter
2006-10-28 9:22 ` Russell King
@ 2006-10-28 19:41 ` Linus Torvalds
1 sibling, 0 replies; 139+ messages in thread
From: Linus Torvalds @ 2006-10-28 19:41 UTC (permalink / raw)
To: Adam J. Richter
Cc: akpm, bunk, greg, linux-kernel, linux-pci, matthew, pavel,
shemminger
On Sat, 28 Oct 2006, Adam J. Richter wrote:
> On Fri, 27 Oct 2006 13:42:44 -0700 (PDT), Linus Torvals wrote:
> > static struct semaphore outstanding;
> [...]
> > static void allow_parallel(int n)
> [...]
> > static void wait_for_parallel(int n)
> [...]
> > static void execute_in_parallel(int (*fn)(void *), void *arg)
>
> This interface would have problems with nesting.
You miss the point.
They _wouldn't_ be nested.
The "allow_parallel()" and "wait_for_parallel()" calls would be at some
top-level situation (ie initcalls looping).
Nobody else than the top level would _ever_ use them. Anything under that
level would just say "I want to do this in parallel" - which is just a
statement, and has no nesting issues in itself.
The whole notion of "I want to do this in parallel" is basically
non-nesting. If something is parallel, it's by definition not ordered, and
thus nesting cannot make sense. All the "ordered" stuff would be either
done without using "execute_in_parallel()" at all, or it would be ordered
_within_ one thread that is executed in parallel.
Linus
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
2006-10-28 6:08 ` Grant Grundler
@ 2006-10-28 20:48 ` Stefan Richter
2006-10-28 23:34 ` Alan Cox
0 siblings, 1 reply; 139+ messages in thread
From: Stefan Richter @ 2006-10-28 20:48 UTC (permalink / raw)
To: Grant Grundler
Cc: Andrew Morton, Alan Cox, Pavel Machek, Greg KH, Stephen Hemminger,
Matthew Wilcox, Adrian Bunk, Linus Torvalds,
Linux Kernel Mailing List, linux-pci
Grant Grundler wrote:
> On Fri, Oct 27, 2006 at 10:19:25PM -0700, Andrew Morton wrote:
>>> I thought parallel PCI and SCSI probing on system with multiple NICs and
>>> "SCSI" storage requires udev to create devices with consistent naming.
>> For some reason people get upset when we rename all their devices. They're
>> a humourless lot.
>
> Hey! I resemble that remark! ;)
>
> (yeah, I've been a victim of that problem way too many times.)
I hear network interfaces can be selected by their MACs, which are
globally unique and persistent. Most SCSI hardware has globally unique
and persistent unit properties too, and udev indeed uses them these days.
--
Stefan Richter
-=====-=-==- =-=- ===--
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled
2006-10-28 11:21 ` Christoph Hellwig
@ 2006-10-28 21:10 ` David Brownell
2006-10-28 21:13 ` Christoph Hellwig
2006-10-28 21:39 ` Adrian Bunk
0 siblings, 2 replies; 139+ messages in thread
From: David Brownell @ 2006-10-28 21:10 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Randy Dunlap, toralf.foerster, netdev, linux-usb-devel, link,
greg, akpm, zippel, torvalds, linux-kernel
On Saturday 28 October 2006 4:21 am, Christoph Hellwig wrote:
> This is really awkward and against what we do in any other driver.
Awkward, yes -- which is why I posted the non-awkward version,
which is repeated below. (No thanks to "diff" for making the
patch ugly though; the resulting code is clean and non-awkward,
moving that function helped.)
Against what other drivers do? Since "usbnet.c" is infrastructure
code, not a driver, your comment can't apply. Infrastructure uses
conditional compilation routinely in such cases.
But remember that the actual drivers follow the standard convention
("select MII") given Randy's patch #1 of 2.
- Dave
-------------------------
The usbnet infrastructure must not reference MII symbols unless they're
provided in the kernel being built. This extends also to the ethtool
hooks that reference those symbols.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Index: g26/drivers/usb/net/usbnet.c
===================================================================
--- g26.orig/drivers/usb/net/usbnet.c 2006-10-24 18:29:28.000000000 -0700
+++ g26/drivers/usb/net/usbnet.c 2006-10-25 19:07:16.000000000 -0700
@@ -669,6 +669,9 @@ done:
* they'll probably want to use this base set.
*/
+#if defined(CONFIG_MII) || defined(CONFIG_MII_MODULE)
+#define HAVE_MII
+
int usbnet_get_settings (struct net_device *net, struct ethtool_cmd *cmd)
{
struct usbnet *dev = netdev_priv(net);
@@ -699,20 +702,6 @@ int usbnet_set_settings (struct net_devi
}
EXPORT_SYMBOL_GPL(usbnet_set_settings);
-
-void usbnet_get_drvinfo (struct net_device *net, struct ethtool_drvinfo *info)
-{
- struct usbnet *dev = netdev_priv(net);
-
- /* REVISIT don't always return "usbnet" */
- strncpy (info->driver, driver_name, sizeof info->driver);
- strncpy (info->version, DRIVER_VERSION, sizeof info->version);
- strncpy (info->fw_version, dev->driver_info->description,
- sizeof info->fw_version);
- usb_make_path (dev->udev, info->bus_info, sizeof info->bus_info);
-}
-EXPORT_SYMBOL_GPL(usbnet_get_drvinfo);
-
u32 usbnet_get_link (struct net_device *net)
{
struct usbnet *dev = netdev_priv(net);
@@ -730,40 +719,57 @@ u32 usbnet_get_link (struct net_device *
}
EXPORT_SYMBOL_GPL(usbnet_get_link);
-u32 usbnet_get_msglevel (struct net_device *net)
+int usbnet_nway_reset(struct net_device *net)
{
struct usbnet *dev = netdev_priv(net);
- return dev->msg_enable;
+ if (!dev->mii.mdio_write)
+ return -EOPNOTSUPP;
+
+ return mii_nway_restart(&dev->mii);
}
-EXPORT_SYMBOL_GPL(usbnet_get_msglevel);
+EXPORT_SYMBOL_GPL(usbnet_nway_reset);
-void usbnet_set_msglevel (struct net_device *net, u32 level)
+#endif /* HAVE_MII */
+
+void usbnet_get_drvinfo (struct net_device *net, struct ethtool_drvinfo *info)
{
struct usbnet *dev = netdev_priv(net);
- dev->msg_enable = level;
+ /* REVISIT don't always return "usbnet" */
+ strncpy (info->driver, driver_name, sizeof info->driver);
+ strncpy (info->version, DRIVER_VERSION, sizeof info->version);
+ strncpy (info->fw_version, dev->driver_info->description,
+ sizeof info->fw_version);
+ usb_make_path (dev->udev, info->bus_info, sizeof info->bus_info);
}
-EXPORT_SYMBOL_GPL(usbnet_set_msglevel);
+EXPORT_SYMBOL_GPL(usbnet_get_drvinfo);
-int usbnet_nway_reset(struct net_device *net)
+u32 usbnet_get_msglevel (struct net_device *net)
{
struct usbnet *dev = netdev_priv(net);
- if (!dev->mii.mdio_write)
- return -EOPNOTSUPP;
+ return dev->msg_enable;
+}
+EXPORT_SYMBOL_GPL(usbnet_get_msglevel);
- return mii_nway_restart(&dev->mii);
+void usbnet_set_msglevel (struct net_device *net, u32 level)
+{
+ struct usbnet *dev = netdev_priv(net);
+
+ dev->msg_enable = level;
}
-EXPORT_SYMBOL_GPL(usbnet_nway_reset);
+EXPORT_SYMBOL_GPL(usbnet_set_msglevel);
/* drivers may override default ethtool_ops in their bind() routine */
static struct ethtool_ops usbnet_ethtool_ops = {
+#ifdef HAVE_MII
.get_settings = usbnet_get_settings,
.set_settings = usbnet_set_settings,
- .get_drvinfo = usbnet_get_drvinfo,
.get_link = usbnet_get_link,
.nway_reset = usbnet_nway_reset,
+#endif
+ .get_drvinfo = usbnet_get_drvinfo,
.get_msglevel = usbnet_get_msglevel,
.set_msglevel = usbnet_set_msglevel,
};
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled
2006-10-28 21:10 ` David Brownell
@ 2006-10-28 21:13 ` Christoph Hellwig
2006-10-28 22:30 ` David Brownell
2006-10-28 21:39 ` Adrian Bunk
1 sibling, 1 reply; 139+ messages in thread
From: Christoph Hellwig @ 2006-10-28 21:13 UTC (permalink / raw)
To: David Brownell
Cc: Christoph Hellwig, Randy Dunlap, toralf.foerster, netdev,
linux-usb-devel, link, greg, akpm, zippel, torvalds, linux-kernel
On Sat, Oct 28, 2006 at 02:10:09PM -0700, David Brownell wrote:
> On Saturday 28 October 2006 4:21 am, Christoph Hellwig wrote:
>
> > This is really awkward and against what we do in any other driver.
>
> Awkward, yes -- which is why I posted the non-awkward version,
> which is repeated below. (No thanks to "diff" for making the
> patch ugly though; the resulting code is clean and non-awkward,
> moving that function helped.)
>
> Against what other drivers do? Since "usbnet.c" is infrastructure
> code, not a driver, your comment can't apply. Infrastructure uses
> conditional compilation routinely in such cases.
>
> But remember that the actual drivers follow the standard convention
> ("select MII") given Randy's patch #1 of 2.
Ah sorry - I missed that.
I still don't quite like the approach. What about simply putting
the mii using functions into usbnet-mii.c and let makefile doing
all the work? This would require a second set of ethtool ops,
but I'd actually consider that a cleanup, as it makes clear which
one we're using and allows to kill all the checks for non-mii
hardware in the methods.
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled
2006-10-28 21:10 ` David Brownell
2006-10-28 21:13 ` Christoph Hellwig
@ 2006-10-28 21:39 ` Adrian Bunk
2006-10-31 17:40 ` [linux-usb-devel] " David Brownell
1 sibling, 1 reply; 139+ messages in thread
From: Adrian Bunk @ 2006-10-28 21:39 UTC (permalink / raw)
To: David Brownell
Cc: Christoph Hellwig, Randy Dunlap, toralf.foerster, netdev,
linux-usb-devel, link, greg, akpm, zippel, torvalds, linux-kernel
On Sat, Oct 28, 2006 at 02:10:09PM -0700, David Brownell wrote:
> On Saturday 28 October 2006 4:21 am, Christoph Hellwig wrote:
>
> > This is really awkward and against what we do in any other driver.
>
> Awkward, yes -- which is why I posted the non-awkward version,
> which is repeated below. (No thanks to "diff" for making the
> patch ugly though; the resulting code is clean and non-awkward,
> moving that function helped.)
>...
> --- g26.orig/drivers/usb/net/usbnet.c 2006-10-24 18:29:28.000000000 -0700
> +++ g26/drivers/usb/net/usbnet.c 2006-10-25 19:07:16.000000000 -0700
> @@ -669,6 +669,9 @@ done:
> * they'll probably want to use this base set.
> */
>
> +#if defined(CONFIG_MII) || defined(CONFIG_MII_MODULE)
> +#define HAVE_MII
>...
This seems to cause a CONFIG_USB_USBNET=y, CONFIG_MII=m breakage
(as already described earlier in this thread)?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled
2006-10-28 21:13 ` Christoph Hellwig
@ 2006-10-28 22:30 ` David Brownell
0 siblings, 0 replies; 139+ messages in thread
From: David Brownell @ 2006-10-28 22:30 UTC (permalink / raw)
To: Christoph Hellwig
Cc: akpm, greg, link, linux-kernel, netdev, Randy Dunlap,
toralf.foerster, torvalds, zippel
On Saturday 28 October 2006 2:13 pm, Christoph Hellwig wrote:
>
> I still don't quite like the approach. What about simply putting
> the mii using functions into usbnet-mii.c and let makefile doing
> all the work? This would require a second set of ethtool ops,
> but I'd actually consider that a cleanup, as it makes clear which
> one we're using and allows to kill all the checks for non-mii
> hardware in the methods.
Feel free to do such a patch yourself, so long as the MII doesn't
go into a separate module. You'll have to also modify the two
Ethernet adapters currently using that usbnet core code (and MII).
That'd still feel like needless complexity to me, though. So
unless you're keen on doing that quickly, I'd say to just merge
the two existing patches and be done with it.
- Dave
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
2006-10-28 20:48 ` Stefan Richter
@ 2006-10-28 23:34 ` Alan Cox
2006-10-29 2:01 ` Randy Dunlap
0 siblings, 1 reply; 139+ messages in thread
From: Alan Cox @ 2006-10-28 23:34 UTC (permalink / raw)
To: Stefan Richter
Cc: Grant Grundler, Andrew Morton, Pavel Machek, Greg KH,
Stephen Hemminger, Matthew Wilcox, Adrian Bunk, Linus Torvalds,
Linux Kernel Mailing List, linux-pci
Ar Sad, 2006-10-28 am 22:48 +0200, ysgrifennodd Stefan Richter:
> I hear network interfaces can be selected by their MACs, which are
> globally unique and persistent. Most SCSI hardware has globally unique
> and persistent unit properties too, and udev indeed uses them these days.
You hear incorrectly. The MAC address is only required to be *machine
unique*, please see the 802.1/2 specification documents for more detail.
Distinguishing by card MAC is a hack that works on some systems only.
SCSI is also unreliable for serial numbers because of USB, brain-dead
raid controllers and other devices that fake the same ident for many
devices.
There is another ugly too - many driver/library layers "know" that
during boot the code is not re-entered so has no locking. Before you can
go multi-probe you also have to fix all the locking in the drivers that
have boot time specific functionality (eg IDE).
Alan
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
@ 2006-10-28 23:50 Adam J. Richter
2006-10-28 23:55 ` Linus Torvalds
0 siblings, 1 reply; 139+ messages in thread
From: Adam J. Richter @ 2006-10-28 23:50 UTC (permalink / raw)
To: torvalds
Cc: akpm, bunk, greg, linux-kernel, linux-pci, matthew, pavel,
shemminger
On 2006-10-28 19:41:50, Linus Torvalds wrote:
>On Sat, 28 Oct 2006, Adam J. Richter wrote:
>
>> On Fri, 27 Oct 2006 13:42:44 -0700 (PDT), Linus Torvals wrote:
>> > static struct semaphore outstanding;
>> [...]
>> > static void allow_parallel(int n)
>> [...]
>> > static void wait_for_parallel(int n)
>> [...]
>> > static void execute_in_parallel(int (*fn)(void *), void *arg)
>>
>> This interface would have problems with nesting.
>
>You miss the point.
>
>They _wouldn't_ be nested.
>
>The "allow_parallel()" and "wait_for_parallel()" calls would be at some
>top-level situation (ie initcalls looping).
>
>Nobody else than the top level would _ever_ use them. Anything under that
>level would just say "I want to do this in parallel" - which is just a
>statement, and has no nesting issues in itself.
If only calls to execute_in_parallel nest, your original
implementation would always deadlock when the nesting depth exceeds
the allowed number of threads, and also potentially in some shallower
nesting depths given a very unlucky order of execution. In your
original message, you mentioned allowing the parallelism limit to be
set as low as 1.
One solution to this problem would be to have
execute_in_parallel execute the function directly when no threads are
available to do it, rather than blocking. The disadvantage is that,
if no thread is immediately available, the call to
execute_in_parallel would not return until the function that was
passed in finishes, even if more threads become available much sooner.
Here is what I am referring to, again completely untested:
static void execute_in_parallel(int (*fn)(void *), void *arg)
{
struct thread_exec arg = { .fn = fn, .arg = arg };
/* If no threads are available, call the function directly. */
if (down_trylock(&outstanding) != 0) {
fn(arg);
return;
}
arg.fn = fn;
arg.arg = arg;
init_completion(&arg.args_copied);
kernel_thread(do_in_parallel, &arg);
/* We need to wait until our "arg" is safe */
wait_for_completion(&arg.args_copied)
}
Adam Richter
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
2006-10-28 23:50 Adam J. Richter
@ 2006-10-28 23:55 ` Linus Torvalds
2006-10-30 14:23 ` Kyle Moffett
0 siblings, 1 reply; 139+ messages in thread
From: Linus Torvalds @ 2006-10-28 23:55 UTC (permalink / raw)
To: Adam J. Richter
Cc: akpm, bunk, greg, linux-kernel, linux-pci, matthew, pavel,
shemminger
On Sun, 29 Oct 2006, Adam J. Richter wrote:
>
> If only calls to execute_in_parallel nest, your original
> implementation would always deadlock when the nesting depth exceeds
> the allowed number of threads, and also potentially in some shallower
> nesting depths given a very unlucky order of execution. In your
> original message, you mentioned allowing the parallelism limit to be
> set as low as 1.
No, I'm saying that nesting simply shouldn't be _done_. There's no real
reason. Any user would be already either parallel or doesn't need to be
parallel at all. Why would something that already _is_ parallel start
another parallel task?
IOW, what I was trying to say (perhaps badly) is that "nesting" really
isn't a sensible operation - you'd never do it. You'd do the "startup" and
"shutdown" things at the very highest level, and then in between those
calls you can start a parallel activity at any depth of the call stack,
but at no point does it really make sense to start it from within
something that is already parallel.
Hmm?
(Btw, you do seem to have some strange email setup that doesn't allow me
to email you directly, I just get a bounce. I'll try again, but you'll
probably pick this up on linux-kernel rather than in your private
mailbox).
Linus
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
2006-10-28 23:34 ` Alan Cox
@ 2006-10-29 2:01 ` Randy Dunlap
0 siblings, 0 replies; 139+ messages in thread
From: Randy Dunlap @ 2006-10-29 2:01 UTC (permalink / raw)
To: Alan Cox
Cc: Stefan Richter, Grant Grundler, Andrew Morton, Pavel Machek,
Greg KH, Stephen Hemminger, Matthew Wilcox, Adrian Bunk,
Linus Torvalds, Linux Kernel Mailing List, linux-pci
On Sun, 29 Oct 2006 00:34:57 +0100 Alan Cox wrote:
> Ar Sad, 2006-10-28 am 22:48 +0200, ysgrifennodd Stefan Richter:
> > I hear network interfaces can be selected by their MACs, which are
> > globally unique and persistent. Most SCSI hardware has globally unique
> > and persistent unit properties too, and udev indeed uses them these days.
>
> You hear incorrectly. The MAC address is only required to be *machine
> unique*, please see the 802.1/2 specification documents for more detail.
> Distinguishing by card MAC is a hack that works on some systems only.
I would have expected "most" instead of "some", but you have
different experiences than I do. What spec requires a MAC address
to be machine-unique?
IEEE "makes it possible for organizations to employ unique individual
LAN MAC addresses, group addresses, and protocol identifiers."
IEEE 802 goes on to say:
"The concept of universal addressing is based on the
idea that all potential members of a network need to
have a unique identifier (if they are going to coexist
in the network). The advantage of a universal address is
that a station with such an address can be attached to any
LAN in the world with an assurance that the address is unique."
and then "recommended" (but not required):
"The recommended approach is for each device associated
with a distinct point of attachment to a LAN to
have its own unique MAC address. Typically, therefore,
a LAN adapter card (or, e.g., an equivalent chip or
set of chips on a motherboard) should have one unique
MAC address for each LAN attachment that it can
support at a given time.
and then this part seems contrary to the machine-unique quality
that you mentioned (I guess--don't know--that this is what
Sun used to do ?):
"NOTE—It is recognized that an alternative approach has
gained currency in some LAN implementations, in which the
device is interpreted as a complete computer system,
which can have multiple attachments to different LANs. Under this
interpretation, a single LAN MAC address is used to
identify all of the system’s points of attachment to the LANs in
question. This approach, unlike the recommended one, does
not automatically meet the requirements of
IEEE Std 802.1D-1998 MAC bridging."
> SCSI is also unreliable for serial numbers because of USB, brain-dead
> raid controllers and other devices that fake the same ident for many
> devices.
>
> There is another ugly too - many driver/library layers "know" that
> during boot the code is not re-entered so has no locking. Before you can
> go multi-probe you also have to fix all the locking in the drivers that
> have boot time specific functionality (eg IDE).
---
~Randy
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: vmlinux.lds: consolidate initcall sections
2006-10-27 19:31 ` vmlinux.lds: consolidate initcall sections Haavard Skinnemoen
@ 2006-10-29 10:21 ` Geert Uytterhoeven
0 siblings, 0 replies; 139+ messages in thread
From: Geert Uytterhoeven @ 2006-10-29 10:21 UTC (permalink / raw)
To: Andrew Morton
Cc: Haavard Skinnemoen, Pavel Machek, Greg KH, Stephen Hemminger,
Matthew Wilcox, Adrian Bunk, Linus Torvalds,
Linux Kernel Mailing List, linux-pci, Geert Uytterhoeven
On Fri, 27 Oct 2006, Haavard Skinnemoen wrote:
> On 10/27/06, Andrew Morton <akpm@osdl.org> wrote:
> > From: Andrew Morton <akpm@osdl.org>
> >
> > Add a vmlinux.lds.h helper macro for defining the eight-level initcall
> > table,
> > teach all the architectures to use it.
>
> Please include AVR32 as well while you're at it ;)
And m68k :-)
Signed-Off-By: Geert Uytterhoeven <geert@linux-m68k.org>
--- linux/arch/m68k/kernel/vmlinux-std.lds 2006-09-25 22:34:27.000000000 +0200
+++ linux-m68k/arch/m68k/kernel/vmlinux-std.lds 2006-10-29 11:15:18.000000000 +0100
@@ -54,13 +54,7 @@ SECTIONS
__setup_end = .;
__initcall_start = .;
.initcall.init : {
- *(.initcall1.init)
- *(.initcall2.init)
- *(.initcall3.init)
- *(.initcall4.init)
- *(.initcall5.init)
- *(.initcall6.init)
- *(.initcall7.init)
+ INITCALLS
}
__initcall_end = .;
__con_initcall_start = .;
--- linux/arch/m68k/kernel/vmlinux-sun3.lds 2006-09-25 22:34:27.000000000 +0200
+++ linux-m68k/arch/m68k/kernel/vmlinux-sun3.lds 2006-10-29 11:14:50.000000000 +0100
@@ -48,13 +48,7 @@ __init_begin = .;
__setup_end = .;
__initcall_start = .;
.initcall.init : {
- *(.initcall1.init)
- *(.initcall2.init)
- *(.initcall3.init)
- *(.initcall4.init)
- *(.initcall5.init)
- *(.initcall6.init)
- *(.initcall7.init)
+ INITCALLS
}
__initcall_end = .;
__con_initcall_start = .;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
@ 2006-10-29 20:38 Adam J. Richter
0 siblings, 0 replies; 139+ messages in thread
From: Adam J. Richter @ 2006-10-29 20:38 UTC (permalink / raw)
To: torvalds
Cc: akpm, bunk, greg, linux-kernel, linux-pci, matthew, pavel,
shemminger
On 2006-10-28 23:55:42, Linus Torvalds wrote:
>On Sun, 29 Oct 2006, Adam J. Richter wrote:
>>
>> If only calls to execute_in_parallel nest, your original
>> implementation would always deadlock when the nesting depth exceeds
>> the allowed number of threads, and [...]
>
>No, I'm saying that nesting simply shouldn't be _done_. There's no real
>reason. Any user would be already either parallel or doesn't need to be
>parallel at all. Why would something that already _is_ parallel start
>another parallel task?
Suppose the system is initializing PCI cards in parallel. The
thread that is initializing one particular PCI card discovers that it
is initializing a firewire controller. After the already "parallel"
PCI firewire probe function initializes the card, it is going to
enumerate the devices attached to the firewire cable and spawn
separate threads to initialize drivers for each of these several
firewire devices.
One way avoid this depth-first descent would be to change
device_attach() in drivers/base/dd.c to queue its work to helper daemon.
Either way, we're talking about a few lines of code in
execute_in_parallel that can easily be added later if needed. If you
really think all calls to execute_parallel will be done by the main
kernel thread, I suggest someone add a BUG_ON() statement to that
effect to execute_parallel to see.
I would also like to suggest a very different approach, which
would not be quite as fast, but which I think would be more flexible
and would work partly by making the kernel do _less_.
Perhaps we could offer a boot option to limit device_attach to
consider only drivers named by that option, such as
"limit_drivers=vc,ramdisk". (If a user screwed his boot process with
the wrong limit_drivers= options, fixing the problem would be just a
matter of just eliminating the option.) All other driver-device
bindings would be done explicitly by a user level mechanism, which
would implicitly provide the process context for blocking. That is,
the parallelization would occur by a sysfs watcher like udev spawning
separate threads to call the user level sysfs interface for attaching
devices to drivers. User level would also handle matching driver and
device ID information, determining parallelization limits, probe
order, choosing between multiple drivers available for devices or
deliberately not binding a driver to a device, and perhaps executing
other custom user level code along the way.
Because the threads involved would come from clone() executed
by a user level daemon sysfs watcher like udev, execute_in_parallel()
would be less used, perhaps not used at all, depending on whether
parts the boot process besides walking the device tree would benefit
much from parallelization.
Adam Richter
^ permalink raw reply [flat|nested] 139+ messages in thread
* 2.6.19-rc3: known unfixed regressions (v3)
2006-10-23 23:22 Linux 2.6.19-rc3 Linus Torvalds
` (6 preceding siblings ...)
2006-10-26 22:45 ` 2.6.19-rc3: known unfixed regressions (v2) Adrian Bunk
@ 2006-10-29 23:13 ` Adrian Bunk
2006-10-30 13:56 ` Michael S. Tsirkin
7 siblings, 1 reply; 139+ messages in thread
From: Adrian Bunk @ 2006-10-29 23:13 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: Linux Kernel Mailing List, Jeff Chua, gregkh, linux-pci,
Prakash Punnoor, phil.el, oprofile-list, Martin Lorenz, len.brown,
linux-acpi, Michael S. Tsirkin, Thierry Vignaud, jgarzik,
linux-ide, Alex Romosan, Jens Axboe, Komuro, Thomas Gleixner,
Christian, Mark Langsdorf, davej, cpufreq
This email lists some known regressions in 2.6.19-rc3 compared to 2.6.18
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.
Due to the huge amount of recipients, please trim the Cc when answering.
Subject : PCI: MMCONFIG breakage
References : http://lkml.org/lkml/2006/10/23/182
Submitter : Jeff Chua <jeff.chua.linux@gmail.com>
Status : unknown, both BIOS and Direct work
Subject : x86_64: oprofile doesn't work
References : http://lkml.org/lkml/2006/10/27/3
Submitter : Prakash Punnoor <prakash@punnoor.de>
Status : unknown
Subject : X60s: BUG()s, lose ACPI events after suspend/resume
References : http://lkml.org/lkml/2006/10/10/39
Submitter : Martin Lorenz <martin@lorenz.eu.org>
Status : unknown
Subject : T60 stops triggering any ACPI events
References : http://lkml.org/lkml/2006/10/4/425
http://lkml.org/lkml/2006/10/16/262
http://bugzilla.kernel.org/show_bug.cgi?id=7408
Submitter : "Michael S. Tsirkin" <mst@mellanox.co.il>
Status : unknown
Subject : sata-via doesn't detect anymore disks attached to VIA vt6421
References : http://bugzilla.kernel.org/show_bug.cgi?id=7255
Submitter : Thierry Vignaud <tvignaud@mandriva.com>
Status : unknown
Subject : unable to rip cd
References : http://lkml.org/lkml/2006/10/13/100
Submitter : Alex Romosan <romosan@sycorax.lbl.gov>
Status : unknown
Subject : SMP kernel can not generate ISA irq properly
References : http://lkml.org/lkml/2006/10/22/15
Submitter : Komuro <komurojun-mbn@nifty.com>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Status : Thomas will investigate
Subject : cpufreq not working on AMD K8
References : http://lkml.org/lkml/2006/10/10/114
Submitter : Christian <christiand59@web.de>
Handled-By : Mark Langsdorf <mark.langsdorf@amd.com>
Status : Mark is investigating
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
2006-10-27 23:06 ` Andrew Morton
2006-10-28 5:09 ` Grant Grundler
@ 2006-10-30 9:44 ` Cornelia Huck
2006-10-30 10:48 ` Alan Cox
1 sibling, 1 reply; 139+ messages in thread
From: Cornelia Huck @ 2006-10-30 9:44 UTC (permalink / raw)
To: Andrew Morton
Cc: Alan Cox, Pavel Machek, Greg KH, Stephen Hemminger,
Matthew Wilcox, Adrian Bunk, Linus Torvalds,
Linux Kernel Mailing List, linux-pci
On Fri, 27 Oct 2006 16:06:26 -0700,
Andrew Morton <akpm@osdl.org> wrote:
> On Fri, 27 Oct 2006 23:59:30 +0100
> Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> > Ar Gwe, 2006-10-27 am 11:42 -0700, ysgrifennodd Andrew Morton:
> > > IOW, we want to be multithreaded _within_ an initcall level, but not between
> > > different levels.
> >
> > Thats actually insufficient. We have link ordered init sequences in
> > large numbers of driver subtrees (ATA, watchdog, etc). We'll need
> > several more initcall layers to fix that.
> >
>
> It would be nice to express those dependencies in some clearer and less
> fragile manner than link order. I guess finer-grained initcall levels
> would do that, but it doesn't scale very well.
Would it be sufficient just to make the busses wait until all their
devices are through with their setup? This is what the ccw bus on s390
does:
- Increase counter for device and start device recognition for it
- Continue for next device
- When async device recognition (and probable enablement) is finished,
register device and decrease counter
- ccw bus init function waits till counter has dropped to 0
This has worked fine for us since 2.5. OTOH, s390 doesn't have such a
diverse set as hardware as a PC :)
--
Cornelia Huck
Linux for zSeries Developer
Tel.: +49-7031-16-4837, Mail: cornelia.huck@de.ibm.com
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
2006-10-30 9:44 ` Cornelia Huck
@ 2006-10-30 10:48 ` Alan Cox
2006-10-30 12:29 ` Matthew Wilcox
0 siblings, 1 reply; 139+ messages in thread
From: Alan Cox @ 2006-10-30 10:48 UTC (permalink / raw)
To: Cornelia Huck
Cc: Andrew Morton, Pavel Machek, Greg KH, Stephen Hemminger,
Matthew Wilcox, Adrian Bunk, Linus Torvalds,
Linux Kernel Mailing List, linux-pci
Ar Llu, 2006-10-30 am 10:44 +0100, ysgrifennodd Cornelia Huck:
> Would it be sufficient just to make the busses wait until all their
> devices are through with their setup? This is what the ccw bus on s390
> does:
For ATA and IDE no, it might work with SCSI but your devices would
randomly re-order which is also obnoxious. IDE relies on both link probe
order and also has code that knows boot time processing is single
threaded.
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
2006-10-30 10:48 ` Alan Cox
@ 2006-10-30 12:29 ` Matthew Wilcox
0 siblings, 0 replies; 139+ messages in thread
From: Matthew Wilcox @ 2006-10-30 12:29 UTC (permalink / raw)
To: Alan Cox
Cc: Cornelia Huck, Andrew Morton, Pavel Machek, Greg KH,
Stephen Hemminger, Adrian Bunk, Linus Torvalds,
Linux Kernel Mailing List, linux-pci, James Bottomley
On Mon, Oct 30, 2006 at 10:48:51AM +0000, Alan Cox wrote:
> Ar Llu, 2006-10-30 am 10:44 +0100, ysgrifennodd Cornelia Huck:
> > Would it be sufficient just to make the busses wait until all their
> > devices are through with their setup? This is what the ccw bus on s390
> > does:
>
> For ATA and IDE no, it might work with SCSI but your devices would
> randomly re-order which is also obnoxious. IDE relies on both link probe
> order and also has code that knows boot time processing is single
> threaded.
There's no need to parallelise the scanning of SCSI host adapters.
Indeed, it only causes pain. With
http://git.kernel.org/git/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commitdiff;h=3e082a910d217b2e7b186077ebf5a1126a68c62f
and
http://git.parisc-linux.org/?p=linux-2.6.git;a=shortlog;h=scsi-async-scan
some bugfixing, and moving the scsi initialisation earlier (so it has
longer to complete while other things initialise), we should never have
to wait for scsi scans again.
And your devices only reorder as much as they ever used to with scsi.
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3)
2006-10-29 23:13 ` 2.6.19-rc3: known unfixed regressions (v3) Adrian Bunk
@ 2006-10-30 13:56 ` Michael S. Tsirkin
2006-10-30 16:17 ` Jun'ichi Nomura
2006-11-01 3:01 ` 2.6.19-rc <-> ThinkPads Adrian Bunk
0 siblings, 2 replies; 139+ messages in thread
From: Michael S. Tsirkin @ 2006-10-30 13:56 UTC (permalink / raw)
To: Pavel Machek
Cc: Adrian Bunk, Linus Torvalds, Andrew Morton,
Linux Kernel Mailing List, len.brown, linux-acpi, linux-pm,
Jun'ichi Nomura, Randy.Dunlap, Martin Lorenz
Quoting r. Adrian Bunk <bunk@stusta.de>:
> Subject : T60 stops triggering any ACPI events
> References : http://lkml.org/lkml/2006/10/4/425
> http://lkml.org/lkml/2006/10/16/262
> http://bugzilla.kernel.org/show_bug.cgi?id=7408
> Submitter : "Michael S. Tsirkin" <mst@mellanox.co.il>
> Status : unknown
OK, I spent half a night with git-bisect, and the patch that triggers this issue
seems to be this:
commit d7dd8fd9557840162b724a8ac1366dd78a12dff
Author: Andrew Morton <akpm@osdl.org>
[PATCH] blockdev.c: check driver layer errors
Reset to d7dd8fd9557840162b724a8ac1366dd78a12dff seems to hide part of the issue
(I have ACPI after kernel build, but not after suspend/resume). Both reverting
this patch, and reset to the parent of this patch seem to solve (or at least,
hide) both problems for me (no ACPI after suspend/resume and no ACPI after
kernel build).
I am currently running on 2.6.19-rc3 minus
d7dd8fd9557840162b724a8ac1366dd78a12dff, and in a full day of use I have not
observed any issues yet. 2.6.19-rc3 without reverting
d7dd8fd9557840162b724a8ac1366dd78a12dff stops receiving ACPI events after some
use (sometimes after suspend/resume, sometimes after kernel build stress). Now,
what does this tell us? Andrew, any idea?
Martin, could you test whether reverting this helps you, too, by chance?
Here's a patch to apply for testing this.
---
commit 658488b7577b7b2242372c43f081f55e2d274615
Author: Michael S. Tsirkin <mst@mellanox.co.il>
Date: Mon Oct 30 01:28:40 2006 +0200
Revert "[PATCH] blockdev.c: check driver layer errors"
This reverts commit 4d7dd8fd9557840162b724a8ac1366dd78a12dff.
diff --git a/fs/block_dev.c b/fs/block_dev.c
index bc8f27c..b15ad29 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -545,11 +545,11 @@ static struct kobject *bdev_get_holder(s
return kobject_get(bdev->bd_disk->holder_dir);
}
-static int add_symlink(struct kobject *from, struct kobject *to)
+static void add_symlink(struct kobject *from, struct kobject *to)
{
if (!from || !to)
- return 0;
- return sysfs_create_link(from, to, kobject_name(to));
+ return;
+ sysfs_create_link(from, to, kobject_name(to));
}
static void del_symlink(struct kobject *from, struct kobject *to)
@@ -650,38 +650,30 @@ static void free_bd_holder(struct bd_hol
* If there is no matching entry with @bo in @bdev->bd_holder_list,
* add @bo to the list, create symlinks.
*
- * Returns 0 if symlinks are created or already there.
- * Returns -ve if something fails and @bo can be freed.
+ * Returns 1 if @bo was added to the list.
+ * Returns 0 if @bo wasn't used by any reason and should be freed.
*/
static int add_bd_holder(struct block_device *bdev, struct bd_holder *bo)
{
struct bd_holder *tmp;
- int ret;
if (!bo)
- return -EINVAL;
+ return 0;
list_for_each_entry(tmp, &bdev->bd_holder_list, list) {
if (tmp->sdir == bo->sdir) {
tmp->count++;
- /* We've already done what we need to do here. */
- free_bd_holder(bo);
return 0;
}
}
if (!bd_holder_grab_dirs(bdev, bo))
- return -EBUSY;
+ return 0;
- ret = add_symlink(bo->sdir, bo->sdev);
- if (ret == 0) {
- ret = add_symlink(bo->hdir, bo->hdev);
- if (ret)
- del_symlink(bo->sdir, bo->sdev);
- }
- if (ret == 0)
- list_add_tail(&bo->list, &bdev->bd_holder_list);
- return ret;
+ add_symlink(bo->sdir, bo->sdev);
+ add_symlink(bo->hdir, bo->hdev);
+ list_add_tail(&bo->list, &bdev->bd_holder_list);
+ return 1;
}
/**
@@ -751,9 +743,7 @@ static int bd_claim_by_kobject(struct bl
mutex_lock_nested(&bdev->bd_mutex, BD_MUTEX_PARTITION);
res = bd_claim(bdev, holder);
- if (res == 0)
- res = add_bd_holder(bdev, bo);
- if (res)
+ if (res || !add_bd_holder(bdev, bo))
free_bd_holder(bo);
mutex_unlock(&bdev->bd_mutex);
--
MST
^ permalink raw reply related [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
2006-10-28 23:55 ` Linus Torvalds
@ 2006-10-30 14:23 ` Kyle Moffett
2006-10-30 14:38 ` Arjan van de Ven
2006-10-30 14:42 ` Matthew Wilcox
0 siblings, 2 replies; 139+ messages in thread
From: Kyle Moffett @ 2006-10-30 14:23 UTC (permalink / raw)
To: Linus Torvalds
Cc: Adam J. Richter, akpm, bunk, greg, linux-kernel, linux-pci,
matthew, pavel, shemminger
On Oct 28, 2006, at 19:55:42, Linus Torvalds wrote:
> On Sun, 29 Oct 2006, Adam J. Richter wrote:
>> If only calls to execute_in_parallel nest, your original
>> implementation would always deadlock when the nesting depth
>> exceeds the allowed number of threads, and also potentially in
>> some shallower nesting depths given a very unlucky order of
>> execution. In your original message, you mentioned allowing the
>> parallelism limit to be set as low as 1.
>
> No, I'm saying that nesting simply shouldn't be _done_. There's no
> real reason. Any user would be already either parallel or doesn't
> need to be parallel at all. Why would something that already _is_
> parallel start another parallel task?
Well, I would argue that there actually _is_ a reason; the same
reason that GNU make communicates between recursive invocations to
control the maximum number of in-progress execution threads ("-J4"
will have 4 make targets running at once, _even_ in the presence of
recursive make invocations and nested directories). Likewise in the
context of recursively nested busses and devices; multiple PCI
domains, USB, Firewire, etc.
> IOW, what I was trying to say (perhaps badly) is that "nesting"
> really isn't a sensible operation - you'd never do it. You'd do the
> "startup" and "shutdown" things at the very highest level, and then
> in between those calls you can start a parallel activity at any
> depth of the call stack, but at no point does it really make sense
> to start it from within something that is already parallel.
Well, perhaps it does. If I have (hypothetically) a 64-way system
with several PCI domains, I should be able to not only start scanning
each PCI domain individually, but once each domain has been scanned
it should be able to launch multiple probing threads, one for each
device on the PCI bus. That is, assuming that I have properly set up
my udev to statically name devices.
Perhaps it would make more sense for the allow_parallel() call to
specify instead a number of *additional* threads to spawn, such that
allow_parallel(0) on the top level would force the normal serial boot
order, allow_parallel(1) would allow one probing thread and the init
thread to both probe hardware at once, etc.
With a little per-thread context on the stack, you could fairly
easily keep track of the number of allowed sub-threads on a per-
allow_parallel() basis. Before you spawn each new thread, create its
new per-thread state for it and pass its pointer to the child
thread. With each new do_in_parallel() call it would down the
semaphores for each "context" up the tree until it hit the top, and
then it would allocate a new context and fork off a new thread for
the _previous_ call to do_in_parallel(). The last call would remain
unforked, and so finalize_parallel() would first execute that call in
the current thread and then reap all of the children by waiting on
their completions then freeing their contexts.
I admit the complexity is a bit high, but since the maximum nesting
is bounded by the complexity of the hardware and the number of
busses, and the maximum memory-allocation is strictly limited in the
single-threaded case this could allow 64-way systems to probe all
their hardware an order of magnitude faster than today without
noticeably impacting an embedded system even in the absolute worst case.
I _believe_ that this should also be coupled with a bit of cleanup of
probe-order dependencies. If a subsystem depends on another being
initialized, the depended-on one could very easily export a
wait_for_foo_init() function:
DECLARE_COMPLETION(foo_init_completion);
static int foo_init_result;
int wait_for_foo_init()
{
wait_for_completion(&foo_init_completion);
return foo_init_result;
}
int foo_init(struct parallel_state *state)
{
struct foo_device *dev;
allow_parallel(state, 3);
#if 1
/* Assumes: int foo_probe_device(void *dev); */
for_each_foo_device(dev)
do_in_parallel(state, foo_probe_device, dev);
#else
/* Assumes: int foo_probe_device(struct parallel_state *state,
void *dev); */
for_each_foo_device(dev)
do_in_parallel_nested(state, foo_probe_device, dev);
#endif
foo_init_result = finalize_parallel(state);
complete(&foo_init_completion);
return foo_init_result;
}
And of course if you wanted to init both the foo and bar busses in
parallel you could implement a virtually identical function using the
do_in_parallel_nested() variant on top of the foo_init() function.
I'm working on a sample implementation of the allow_parallel()
do_in_parallel() and finalize_parallel() functions, but I'm going to
take the time to make sure its right. In the mean-time, I'm
interested in any comments.
Cheers,
Kyle Moffett
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
2006-10-30 14:23 ` Kyle Moffett
@ 2006-10-30 14:38 ` Arjan van de Ven
2006-10-30 15:00 ` Xavier Bestel
2006-10-30 18:56 ` Kyle Moffett
2006-10-30 14:42 ` Matthew Wilcox
1 sibling, 2 replies; 139+ messages in thread
From: Arjan van de Ven @ 2006-10-30 14:38 UTC (permalink / raw)
To: Kyle Moffett
Cc: Linus Torvalds, Adam J. Richter, akpm, bunk, greg, linux-kernel,
linux-pci, matthew, pavel, shemminger
> I admit the complexity is a bit high, but since the maximum nesting
> is bounded by the complexity of the hardware and the number of
> busses, and the maximum memory-allocation is strictly limited in the
> single-threaded case this could allow 64-way systems to probe all
> their hardware an order of magnitude faster than today without
> noticeably impacting an embedded system even in the absolute worst case.
how much of this complexity goes away if you consider the
scanning/probing as a series of "work elements", and you end up with a
queue of work elements that threads can pull work off one at a time (so
that if one element blocks the others just continue to flow). If you
then find, say, a new PCI bus you just put another work element to
process it at the end of the queue, or you process it synchronously. Etc
etc.
All you need to scale then is the number of worker threads on the
system, which should be relatively easy to size....
(check every X miliseconds if there are more than X outstanding work
elements, if there are, spawn one new worker thread if the total number
of worker threads is less than the system wide max. Worker threads die
if they have nothing to do for more than Y miliseconds)
Oh and... we have a concept for this already, or at least mostly, via
the work queue mechanism :)
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
2006-10-30 14:23 ` Kyle Moffett
2006-10-30 14:38 ` Arjan van de Ven
@ 2006-10-30 14:42 ` Matthew Wilcox
2006-10-30 18:47 ` Kyle Moffett
1 sibling, 1 reply; 139+ messages in thread
From: Matthew Wilcox @ 2006-10-30 14:42 UTC (permalink / raw)
To: Kyle Moffett
Cc: Linus Torvalds, Adam J. Richter, akpm, bunk, greg, linux-kernel,
linux-pci, pavel, shemminger
On Mon, Oct 30, 2006 at 09:23:10AM -0500, Kyle Moffett wrote:
> recursive make invocations and nested directories). Likewise in the
> context of recursively nested busses and devices; multiple PCI
> domains, USB, Firewire, etc.
I don't think you know what a PCI domain is ...
> Well, perhaps it does. If I have (hypothetically) a 64-way system
> with several PCI domains, I should be able to not only start scanning
> each PCI domain individually, but once each domain has been scanned
> it should be able to launch multiple probing threads, one for each
> device on the PCI bus. That is, assuming that I have properly set up
> my udev to statically name devices.
There's still one spinlock that protects *all* accesses to PCI config
space. Maybe we should make it one per PCI root bridge or something,
but even that wouldn't help some architectures.
> I admit the complexity is a bit high, but since the maximum nesting
> is bounded by the complexity of the hardware and the number of
> busses, and the maximum memory-allocation is strictly limited in the
> single-threaded case this could allow 64-way systems to probe all
> their hardware an order of magnitude faster than today without
> noticeably impacting an embedded system even in the absolute worst case.
To be honest, I think just scaling PARALLEL to NR_CPUS*4 or something
would be a reasonable way to go.
If people actually want to get serious about this, I know the PPC folks
have some openfirmware call that tells them about power domains and how
many scsi discs they can spin up at one time (for example). Maybe
that's not necessary; if we can figure out what the system's max power
draw is and how close we are to it, we can decide whether to spawn
another thread or not.
It's quite complicated. You can spin up a disc over *here*, but not
over *there* ... this really is a gigantic can of worms being opened.
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
2006-10-30 14:38 ` Arjan van de Ven
@ 2006-10-30 15:00 ` Xavier Bestel
2006-10-30 15:05 ` Arjan van de Ven
2006-10-30 18:56 ` Kyle Moffett
1 sibling, 1 reply; 139+ messages in thread
From: Xavier Bestel @ 2006-10-30 15:00 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Kyle Moffett, Linus Torvalds, Adam J. Richter, akpm, bunk, greg,
linux-kernel, linux-pci, matthew, pavel, shemminger
On Mon, 2006-10-30 at 15:38 +0100, Arjan van de Ven wrote:
> how much of this complexity goes away if you consider the
> scanning/probing as a series of "work elements", and you end up with a
> queue of work elements that threads can pull work off one at a time (so
> that if one element blocks the others just continue to flow). If you
> then find, say, a new PCI bus you just put another work element to
> process it at the end of the queue, or you process it synchronously. Etc
> etc.
>
> All you need to scale then is the number of worker threads on the
> system, which should be relatively easy to size....
> (check every X miliseconds if there are more than X outstanding work
> elements, if there are, spawn one new worker thread if the total number
> of worker threads is less than the system wide max. Worker threads die
> if they have nothing to do for more than Y miliseconds)
Instead of checking every X ms, just check at each job insertion.
Xav
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
2006-10-30 15:00 ` Xavier Bestel
@ 2006-10-30 15:05 ` Arjan van de Ven
2006-10-30 15:28 ` Xavier Bestel
0 siblings, 1 reply; 139+ messages in thread
From: Arjan van de Ven @ 2006-10-30 15:05 UTC (permalink / raw)
To: Xavier Bestel
Cc: Kyle Moffett, Linus Torvalds, Adam J. Richter, akpm, bunk, greg,
linux-kernel, linux-pci, matthew, pavel, shemminger
On Mon, 2006-10-30 at 16:00 +0100, Xavier Bestel wrote:
> On Mon, 2006-10-30 at 15:38 +0100, Arjan van de Ven wrote:
>
> > how much of this complexity goes away if you consider the
> > scanning/probing as a series of "work elements", and you end up with a
> > queue of work elements that threads can pull work off one at a time (so
> > that if one element blocks the others just continue to flow). If you
> > then find, say, a new PCI bus you just put another work element to
> > process it at the end of the queue, or you process it synchronously. Etc
> > etc.
> >
> > All you need to scale then is the number of worker threads on the
> > system, which should be relatively easy to size....
> > (check every X miliseconds if there are more than X outstanding work
> > elements, if there are, spawn one new worker thread if the total number
> > of worker threads is less than the system wide max. Worker threads die
> > if they have nothing to do for more than Y miliseconds)
>
> Instead of checking every X ms, just check at each job insertion.
that would lead to a too eager amount of threads if processing the jobs
is really really quick ...
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
2006-10-30 15:05 ` Arjan van de Ven
@ 2006-10-30 15:28 ` Xavier Bestel
0 siblings, 0 replies; 139+ messages in thread
From: Xavier Bestel @ 2006-10-30 15:28 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Kyle Moffett, Linus Torvalds, Adam J. Richter, akpm, bunk, greg,
linux-kernel, linux-pci, matthew, pavel, shemminger
On Mon, 2006-10-30 at 16:05 +0100, Arjan van de Ven wrote:
> On Mon, 2006-10-30 at 16:00 +0100, Xavier Bestel wrote:
> > On Mon, 2006-10-30 at 15:38 +0100, Arjan van de Ven wrote:
> >
> > > how much of this complexity goes away if you consider the
> > > scanning/probing as a series of "work elements", and you end up with a
> > > queue of work elements that threads can pull work off one at a time (so
> > > that if one element blocks the others just continue to flow). If you
> > > then find, say, a new PCI bus you just put another work element to
> > > process it at the end of the queue, or you process it synchronously. Etc
> > > etc.
> > >
> > > All you need to scale then is the number of worker threads on the
> > > system, which should be relatively easy to size....
> > > (check every X miliseconds if there are more than X outstanding work
> > > elements, if there are, spawn one new worker thread if the total number
> > > of worker threads is less than the system wide max. Worker threads die
> > > if they have nothing to do for more than Y miliseconds)
> >
> > Instead of checking every X ms, just check at each job insertion.
>
> that would lead to a too eager amount of threads if processing the jobs
> is really really quick ...
Don't you have a "no more than X threads at once" limit ? You just
*check* at job insertion, not unconditionnaly fork.
Xav
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3)
2006-10-30 13:56 ` Michael S. Tsirkin
@ 2006-10-30 16:17 ` Jun'ichi Nomura
2006-10-30 16:32 ` Michael S. Tsirkin
2006-10-30 16:44 ` Linus Torvalds
2006-11-01 3:01 ` 2.6.19-rc <-> ThinkPads Adrian Bunk
1 sibling, 2 replies; 139+ messages in thread
From: Jun'ichi Nomura @ 2006-10-30 16:17 UTC (permalink / raw)
To: Michael S. Tsirkin, Martin Lorenz
Cc: Pavel Machek, Adrian Bunk, Linus Torvalds, Andrew Morton,
Linux Kernel Mailing List, len.brown, linux-acpi, linux-pm,
Randy.Dunlap
Hi Michael,
> 2.6.19-rc3 without reverting
> d7dd8fd9557840162b724a8ac1366dd78a12dff stops receiving ACPI events after some
> use (sometimes after suspend/resume, sometimes after kernel build stress). Now,
> what does this tell us? Andrew, any idea?
The code is related to bd_claim_by_disk which is called when
device-mapper or md tries to mark the underlying devices
for exclusive use and creates symlinks from/to the devices
in sysfs. The patch added error handlings which weren't in
the original code.
I have no idea how it affects ACPI event handling.
Are you using dm and/or md on your machine?
Have you seen any unusual kernel messages or symptoms regarding
dm/md before the ACPI problem occurs?
Michael S. Tsirkin wrote:
> Quoting r. Adrian Bunk <bunk@stusta.de>:
>> Subject : T60 stops triggering any ACPI events
>> References : http://lkml.org/lkml/2006/10/4/425
>> http://lkml.org/lkml/2006/10/16/262
>> http://bugzilla.kernel.org/show_bug.cgi?id=7408
>> Submitter : "Michael S. Tsirkin" <mst@mellanox.co.il>
>> Status : unknown
>
> OK, I spent half a night with git-bisect, and the patch that triggers this issue
> seems to be this:
>
> commit d7dd8fd9557840162b724a8ac1366dd78a12dff
> Author: Andrew Morton <akpm@osdl.org>
> [PATCH] blockdev.c: check driver layer errors
>
> Reset to d7dd8fd9557840162b724a8ac1366dd78a12dff seems to hide part of the issue
> (I have ACPI after kernel build, but not after suspend/resume). Both reverting
> this patch, and reset to the parent of this patch seem to solve (or at least,
> hide) both problems for me (no ACPI after suspend/resume and no ACPI after
> kernel build).
>
> I am currently running on 2.6.19-rc3 minus
> d7dd8fd9557840162b724a8ac1366dd78a12dff, and in a full day of use I have not
> observed any issues yet. 2.6.19-rc3 without reverting
> d7dd8fd9557840162b724a8ac1366dd78a12dff stops receiving ACPI events after some
> use (sometimes after suspend/resume, sometimes after kernel build stress). Now,
> what does this tell us? Andrew, any idea?
>
>
> Martin, could you test whether reverting this helps you, too, by chance?
> Here's a patch to apply for testing this.
>
> ---
>
> commit 658488b7577b7b2242372c43f081f55e2d274615
> Author: Michael S. Tsirkin <mst@mellanox.co.il>
> Date: Mon Oct 30 01:28:40 2006 +0200
>
> Revert "[PATCH] blockdev.c: check driver layer errors"
>
> This reverts commit 4d7dd8fd9557840162b724a8ac1366dd78a12dff.
Thanks,
--
Jun'ichi Nomura, NEC Corporation of America
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3)
2006-10-30 16:17 ` Jun'ichi Nomura
@ 2006-10-30 16:32 ` Michael S. Tsirkin
2006-10-30 17:20 ` Jun'ichi Nomura
2006-10-30 16:44 ` Linus Torvalds
1 sibling, 1 reply; 139+ messages in thread
From: Michael S. Tsirkin @ 2006-10-30 16:32 UTC (permalink / raw)
To: Jun'ichi Nomura
Cc: Martin Lorenz, Pavel Machek, Adrian Bunk, Linus Torvalds,
Andrew Morton, Linux Kernel Mailing List, len.brown, linux-acpi,
linux-pm, Randy.Dunlap
Quoting r. Jun'ichi Nomura <j-nomura@ce.jp.nec.com>:
> Subject: Re: 2.6.19-rc3: known unfixed regressions (v3)
>
> Hi Michael,
>
> > 2.6.19-rc3 without reverting
> > d7dd8fd9557840162b724a8ac1366dd78a12dff stops receiving ACPI events after some
> > use (sometimes after suspend/resume, sometimes after kernel build stress). Now,
> > what does this tell us? Andrew, any idea?
>
> The code is related to bd_claim_by_disk which is called when
> device-mapper or md tries to mark the underlying devices
> for exclusive use and creates symlinks from/to the devices
> in sysfs. The patch added error handlings which weren't in
> the original code.
>
> I have no idea how it affects ACPI event handling.
It's a mystery. Probably exposes a bug somewhere?
> Are you using dm and/or md on your machine?
The .config is attached to bugzilla.
> Have you seen any unusual kernel messages or symptoms regarding
> dm/md before the ACPI problem occurs?
I haven't.
--
MST
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3)
2006-10-30 16:17 ` Jun'ichi Nomura
2006-10-30 16:32 ` Michael S. Tsirkin
@ 2006-10-30 16:44 ` Linus Torvalds
2006-10-30 17:34 ` Jun'ichi Nomura
1 sibling, 1 reply; 139+ messages in thread
From: Linus Torvalds @ 2006-10-30 16:44 UTC (permalink / raw)
To: Jun'ichi Nomura
Cc: Michael S. Tsirkin, Martin Lorenz, Pavel Machek, Adrian Bunk,
Andrew Morton, Linux Kernel Mailing List, len.brown, linux-acpi,
linux-pm, Randy.Dunlap
On Mon, 30 Oct 2006, Jun'ichi Nomura wrote:
>
> The code is related to bd_claim_by_disk which is called when
> device-mapper or md tries to mark the underlying devices
> for exclusive use and creates symlinks from/to the devices
> in sysfs. The patch added error handlings which weren't in
> the original code.
Actually, looking closer at the code, the patch seems to add _incorrect_
error handling.
For example, look at bd_claim_by_kobject(): if the "bd_claim()" inside of
it succeeds, we used to always return success. Now, we don't necessarily
do that: we may have done a _successful_ "bd_claim()" call, but then we
return an error because something else failed, and now we're returning
with from bd_claim_by_kobject() with the bd_claim() done, but with an
error return (so the caller will _not_ call "bd_release()", and the
block_device will forever stay exclusive).
No?
Now, exactly why acpi stops working as a result, I don't know, but maybe
something else tries to get exclusive access to a swap partition, for
example, and now fails, causing some acpi sequence to not be set up?
Dunno.
So I suspect it should be reverted, but maybe somebody can see exactly
what goes wrong here.
Linus
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3)
2006-10-30 16:32 ` Michael S. Tsirkin
@ 2006-10-30 17:20 ` Jun'ichi Nomura
2006-10-30 17:54 ` Michael S. Tsirkin
0 siblings, 1 reply; 139+ messages in thread
From: Jun'ichi Nomura @ 2006-10-30 17:20 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Martin Lorenz, Pavel Machek, Adrian Bunk, Linus Torvalds,
Andrew Morton, Linux Kernel Mailing List, len.brown, linux-acpi,
linux-pm, Randy.Dunlap
Hi Michael,
Michael S. Tsirkin wrote:
>> The code is related to bd_claim_by_disk which is called when
>> device-mapper or md tries to mark the underlying devices
>> for exclusive use and creates symlinks from/to the devices
>> in sysfs. The patch added error handlings which weren't in
>> the original code.
>>
>> I have no idea how it affects ACPI event handling.
>
> It's a mystery. Probably exposes a bug somewhere?
>
>> Are you using dm and/or md on your machine?
>
> The .config is attached to bugzilla.
OK, I found you disabled CONFIG_MD, which means neither
dm.ko nor md.ko was built.
Do you have any out-of-tree kernel modules which call either
bd_claim_by_kobject or bd_claim_by_disk?
If you aren't using either of them, I'm afraid reverting
the patch doesn't really solve your problem because the patched
code is called only from them.
>> Have you seen any unusual kernel messages or symptoms regarding
>> dm/md before the ACPI problem occurs?
>
> I haven't.
Thanks,
--
Jun'ichi Nomura, NEC Corporation of America
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3)
2006-10-30 16:44 ` Linus Torvalds
@ 2006-10-30 17:34 ` Jun'ichi Nomura
2006-10-30 18:16 ` Linus Torvalds
0 siblings, 1 reply; 139+ messages in thread
From: Jun'ichi Nomura @ 2006-10-30 17:34 UTC (permalink / raw)
To: Linus Torvalds
Cc: Michael S. Tsirkin, Martin Lorenz, Pavel Machek, Adrian Bunk,
Andrew Morton, Linux Kernel Mailing List, len.brown, linux-acpi,
linux-pm, Randy.Dunlap
Hi Linus,
Linus Torvalds wrote:
> Actually, looking closer at the code, the patch seems to add _incorrect_
> error handling.
>
> For example, look at bd_claim_by_kobject(): if the "bd_claim()" inside of
> it succeeds, we used to always return success. Now, we don't necessarily
> do that: we may have done a _successful_ "bd_claim()" call, but then we
> return an error because something else failed, and now we're returning
> with from bd_claim_by_kobject() with the bd_claim() done, but with an
> error return (so the caller will _not_ call "bd_release()", and the
> block_device will forever stay exclusive).
>
> No?
You're right.
> Now, exactly why acpi stops working as a result, I don't know, but maybe
> something else tries to get exclusive access to a swap partition, for
> example, and now fails, causing some acpi sequence to not be set up?
> Dunno.
>
> So I suspect it should be reverted, but maybe somebody can see exactly
> what goes wrong here.
Please revert the patch. I'll fix the wrong error handling.
I'm not sure reverting the patch solves the ACPI problem
because Michael's kernel seems not having any user of
bd_claim_by_kobject.
Thanks,
--
Jun'ichi Nomura, NEC Corporation of America
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3)
2006-10-30 17:20 ` Jun'ichi Nomura
@ 2006-10-30 17:54 ` Michael S. Tsirkin
0 siblings, 0 replies; 139+ messages in thread
From: Michael S. Tsirkin @ 2006-10-30 17:54 UTC (permalink / raw)
To: Jun'ichi Nomura
Cc: Martin Lorenz, Pavel Machek, Adrian Bunk, Linus Torvalds,
Andrew Morton, Linux Kernel Mailing List, len.brown, linux-acpi,
linux-pm, Randy.Dunlap
Quoting r. Jun'ichi Nomura <j-nomura@ce.jp.nec.com>:
> Subject: Re: 2.6.19-rc3: known unfixed regressions (v3)
>
> Hi Michael,
>
> Michael S. Tsirkin wrote:
> >> The code is related to bd_claim_by_disk which is called when
> >> device-mapper or md tries to mark the underlying devices
> >> for exclusive use and creates symlinks from/to the devices
> >> in sysfs. The patch added error handlings which weren't in
> >> the original code.
> >>
> >> I have no idea how it affects ACPI event handling.
> >
> > It's a mystery. Probably exposes a bug somewhere?
> >
> >> Are you using dm and/or md on your machine?
> >
> > The .config is attached to bugzilla.
>
> OK, I found you disabled CONFIG_MD, which means neither
> dm.ko nor md.ko was built.
> Do you have any out-of-tree kernel modules which call either
> bd_claim_by_kobject or bd_claim_by_disk?
No, I don't have any out-of-tree modules.
> If you aren't using either of them, I'm afraid reverting
> the patch doesn't really solve your problem because the patched
> code is called only from them.
I agree this could be just papering over some issue.
The test results (of both git-bisect and reverting the patch) seem to be pretty
consistent so far though. Keep me posted if you rework the patch.
> >> Have you seen any unusual kernel messages or symptoms regarding
> >> dm/md before the ACPI problem occurs?
> >
> > I haven't.
>
> Thanks,
--
MST
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3)
2006-10-30 17:34 ` Jun'ichi Nomura
@ 2006-10-30 18:16 ` Linus Torvalds
2006-10-30 18:35 ` Adrian Bunk
` (2 more replies)
0 siblings, 3 replies; 139+ messages in thread
From: Linus Torvalds @ 2006-10-30 18:16 UTC (permalink / raw)
To: Jun'ichi Nomura
Cc: Michael S. Tsirkin, Martin Lorenz, Pavel Machek, Adrian Bunk,
Andrew Morton, Linux Kernel Mailing List, len.brown, linux-acpi,
linux-pm, Randy.Dunlap
On Mon, 30 Oct 2006, Jun'ichi Nomura wrote:
>
> Please revert the patch. I'll fix the wrong error handling.
>
> I'm not sure reverting the patch solves the ACPI problem
> because Michael's kernel seems not having any user of
> bd_claim_by_kobject.
Yeah, doing a grep does seem to imply that there is no way that those
changes could matter.
Michael, can you double-check? I think Jun'ichi is right - in your kernel,
according to the config posted on bugzilla, I don't think there should be
a single caller of bd_claim_by_disk, since CONFIG_MD is disabled.
So it does seem strange. But if you bisected to that patch, and it
reliably does _not_ have problems with the patch reverted, maybe there is
some strange preprocessor thing that makes "grep" not find the caller.
Michael, you also reported:
> Reset to d7dd8fd9557840162b724a8ac1366dd78a12dff seems to hide part of
> the issue (I have ACPI after kernel build, but not after
> suspend/resume). Both reverting this patch, and reset to the parent of
> this patch seem to solve (or at least, hide) both problems for me (no
> ACPI after suspend/resume and no ACPI after kernel build).
(where that "d7dd8f.." is actually missing the initial "4" - I think you
cut-and-pasted things incorrectly).
So I wonder.. You still had ACPI working _after_ the kernel build even
with that patch in place, and it seems that suspend/resume is the real
issue. Martin Lorenz reports on the same bugzilla entry, and he only has
problems with suspend/resume.
I assume that "compile the kernel" just triggers some magic ACPI event
(probably fan-related due to heat), and I wonder if the bisection faked
you out because once you get "close enough" the differences are small
enough that the kernel compile is quick and the heat event doesn't
actually trigger?
See what I'm saying? Maybe the act of bisecting itself changed the
results, and then when you just revert the patch, you end up in the same
situation: you only recompile a small part (you only recompile that
particular file), and the problem doesn't occur, so you'd think that the
revert "fixed" it.
If it's heat-related, it should probably trigger by anything that does a
lot of CPU (and perhaps disk) accesses, not just kernel builds. It might
be good to try to find another test-case for it than a kernel recompile,
one that doesn't depend on how much changed in the kernel..
Linus
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3)
2006-10-30 18:16 ` Linus Torvalds
@ 2006-10-30 18:35 ` Adrian Bunk
2006-10-30 19:00 ` Michael S. Tsirkin
` (2 more replies)
2006-10-30 18:58 ` Michael S. Tsirkin
2006-10-31 21:15 ` Michael S. Tsirkin
2 siblings, 3 replies; 139+ messages in thread
From: Adrian Bunk @ 2006-10-30 18:35 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jun'ichi Nomura, Michael S. Tsirkin, Martin Lorenz,
Pavel Machek, Andrew Morton, Linux Kernel Mailing List, len.brown,
linux-acpi, linux-pm, Randy.Dunlap
On Mon, Oct 30, 2006 at 10:16:34AM -0800, Linus Torvalds wrote:
>...
> I assume that "compile the kernel" just triggers some magic ACPI event
> (probably fan-related due to heat), and I wonder if the bisection faked
> you out because once you get "close enough" the differences are small
> enough that the kernel compile is quick and the heat event doesn't
> actually trigger?
>
> See what I'm saying? Maybe the act of bisecting itself changed the
> results, and then when you just revert the patch, you end up in the same
> situation: you only recompile a small part (you only recompile that
> particular file), and the problem doesn't occur, so you'd think that the
> revert "fixed" it.
>
> If it's heat-related, it should probably trigger by anything that does a
> lot of CPU (and perhaps disk) accesses, not just kernel builds. It might
> be good to try to find another test-case for it than a kernel recompile,
> one that doesn't depend on how much changed in the kernel..
Martin's original bug report stated "now I loose ACPI events after
suspend/resume. not every time, but roughly 3 out of 4 times."
This seems to support your theory.
But considering that two people have independently reported this as a
2.6.19-rc regression for similar hardware (Michael for a T60 and Martin
for an X60), a problem in the kernel seems to be involved.
Martin, Michael, can you send complete "dmesg -s 1000000" for both
2.6.18.1 and a non-working 2.6.19-rc kernel after resume?
I don't have high hopes, but perhaps looking at the dmesg and/or
diff'ing them might give a hint.
> Linus
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
2006-10-30 14:42 ` Matthew Wilcox
@ 2006-10-30 18:47 ` Kyle Moffett
2006-10-30 19:13 ` Matthew Wilcox
0 siblings, 1 reply; 139+ messages in thread
From: Kyle Moffett @ 2006-10-30 18:47 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Linus Torvalds, Adam J. Richter, akpm, bunk, greg, linux-kernel,
linux-pci, pavel, shemminger
On Oct 30, 2006, at 09:42:59, Matthew Wilcox wrote:
> On Mon, Oct 30, 2006 at 09:23:10AM -0500, Kyle Moffett wrote:
>> recursive make invocations and nested directories). Likewise in
>> the context of recursively nested busses and devices; multiple PCI
>> domains, USB, Firewire, etc.
>
> I don't think you know what a PCI domain is ...
Fair enough, I guess I don't, really...
>> Well, perhaps it does. If I have (hypothetically) a 64-way system
>> with several PCI domains, I should be able to not only start
>> scanning each PCI domain individually, but once each domain has
>> been scanned it should be able to launch multiple probing threads,
>> one for each device on the PCI bus. That is, assuming that I have
>> properly set up my udev to statically name devices.
>
> There's still one spinlock that protects *all* accesses to PCI
> config space. Maybe we should make it one per PCI root bridge or
> something, but even that wouldn't help some architectures.
Well, yes, but it would help some architectures. It would seem
rather stupid to build a hardware limitation into a 64+ cpu system
such that it cannot initialize or reconfigure multiple pieces of
hardware at once. It also would help for more "mundane" systems such
as my "Quad" G5 desktop which takes an appreciable time to probe all
the various PCI, USB, SATA, and Firewire devices in the system.
Cheers,
Kyle Moffett
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
2006-10-30 14:38 ` Arjan van de Ven
2006-10-30 15:00 ` Xavier Bestel
@ 2006-10-30 18:56 ` Kyle Moffett
1 sibling, 0 replies; 139+ messages in thread
From: Kyle Moffett @ 2006-10-30 18:56 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Linus Torvalds, Adam J. Richter, akpm, bunk, greg, linux-kernel,
linux-pci, matthew, pavel, shemminger
On Oct 30, 2006, at 09:38:00, Arjan van de Ven wrote:
>> I admit the complexity is a bit high, but since the maximum
>> nesting is bounded by the complexity of the hardware and the
>> number of busses, and the maximum memory-allocation is strictly
>> limited in the single-threaded case this could allow 64-way
>> systems to probe all their hardware an order of magnitude faster
>> than today without noticeably impacting an embedded system even in
>> the absolute worst case.
>
> how much of this complexity goes away if you consider the scanning/
> probing as a series of "work elements", and you end up with a queue
> of work elements that threads can pull work off one at a time (so
> that if one element blocks the others just continue to flow). If
> you then find, say, a new PCI bus you just put another work element
> to process it at the end of the queue, or you process it
> synchronously. Etc etc.
Well, I suppose the "trick" would be to ensure that the top-level
code can probe multiple independent busses in parallel, while
allowing certain of those to serialize their execution order for
whatever reason without changing the resulting linear order. This
would make it possible to have independent pci.multithread_probe=1
and scsi.multithread_probe=1 arguments so the sysadmin can force
serialization for one subsystem if they don't have their device-
numbering issues with that subsystem entirely sorted out.
Cheers,
Kyle Movvett
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3)
2006-10-30 18:16 ` Linus Torvalds
2006-10-30 18:35 ` Adrian Bunk
@ 2006-10-30 18:58 ` Michael S. Tsirkin
2006-10-31 21:15 ` Michael S. Tsirkin
2 siblings, 0 replies; 139+ messages in thread
From: Michael S. Tsirkin @ 2006-10-30 18:58 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jun'ichi Nomura, Martin Lorenz, Pavel Machek, Adrian Bunk,
Andrew Morton, Linux Kernel Mailing List, len.brown, linux-acpi,
linux-pm, Randy.Dunlap
Quoting r. Linus Torvalds <torvalds@osdl.org>:
> Subject: Re: 2.6.19-rc3: known unfixed regressions (v3)
>
>
>
> On Mon, 30 Oct 2006, Jun'ichi Nomura wrote:
> >
> > Please revert the patch. I'll fix the wrong error handling.
> >
> > I'm not sure reverting the patch solves the ACPI problem
> > because Michael's kernel seems not having any user of
> > bd_claim_by_kobject.
>
> Yeah, doing a grep does seem to imply that there is no way that those
> changes could matter.
>
> Michael, can you double-check? I think Jun'ichi is right - in your kernel,
> according to the config posted on bugzilla, I don't think there should be
> a single caller of bd_claim_by_disk, since CONFIG_MD is disabled.
I will, just maybe not today.
> So it does seem strange. But if you bisected to that patch, and it
> reliably does _not_ have problems with the patch reverted, maybe there is
> some strange preprocessor thing that makes "grep" not find the caller.
>
> Michael, you also reported:
>
> > Reset to d7dd8fd9557840162b724a8ac1366dd78a12dff seems to hide part of
> > the issue (I have ACPI after kernel build, but not after
> > suspend/resume). Both reverting this patch, and reset to the parent of
> > this patch seem to solve (or at least, hide) both problems for me (no
> > ACPI after suspend/resume and no ACPI after kernel build).
>
> (where that "d7dd8f.." is actually missing the initial "4" - I think you
> cut-and-pasted things incorrectly).
Yes.
> So I wonder.. You still had ACPI working _after_ the kernel build even
> with that patch in place, and it seems that suspend/resume is the real
> issue. Martin Lorenz reports on the same bugzilla entry, and he only has
> problems with suspend/resume.
>
> I assume that "compile the kernel" just triggers some magic ACPI event
> (probably fan-related due to heat), and I wonder if the bisection faked
> you out because once you get "close enough" the differences are small
> enough that the kernel compile is quick and the heat event doesn't
> actually trigger?
>
> See what I'm saying? Maybe the act of bisecting itself changed the
> results, and then when you just revert the patch, you end up in the same
> situation: you only recompile a small part (you only recompile that
> particular file), and the problem doesn't occur, so you'd think that the
> revert "fixed" it.
>
> If it's heat-related, it should probably trigger by anything that does a
> lot of CPU (and perhaps disk) accesses, not just kernel builds. It might
> be good to try to find another test-case for it than a kernel recompile,
> one that doesn't depend on how much changed in the kernel..
>
> Linus
>
>
Linus, I agree something fishy is going on, I'm just not sure how to debug.
It kind of looks like some memory corruption, or something.
I plan double-checking sometime later.
2 points I'd like to clarify:
1. When I git-bisected, I tested ACPI after suspend/resume,
this is much faster to test but might be a separate issue.
I really tested several times, and unless I repeated
same mistake several times just switching between commit above
and its parent made ACPI after resume work/not work.
2. When I test kernel compile, I do
git clone -s ~/scm/linux-2.6
cd linux-2.6
make defconfig
make -j 4
so the build I do in testing is repeatable.
--
MST
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3)
2006-10-30 18:35 ` Adrian Bunk
@ 2006-10-30 19:00 ` Michael S. Tsirkin
2006-10-30 19:06 ` Hugh Dickins
2006-10-31 12:47 ` Martin Lorenz
2 siblings, 0 replies; 139+ messages in thread
From: Michael S. Tsirkin @ 2006-10-30 19:00 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linus Torvalds, Jun'ichi Nomura, Martin Lorenz, Pavel Machek,
Andrew Morton, Linux Kernel Mailing List, len.brown, linux-acpi,
linux-pm, Randy.Dunlap
Quoting r. Adrian Bunk <bunk@stusta.de>:
> Martin, Michael, can you send complete "dmesg -s 1000000" for both
> 2.6.18.1 and a non-working 2.6.19-rc kernel after resume?
> I don't have high hopes, but perhaps looking at the dmesg and/or
> diff'ing them might give a hint.
OK, I'll try to go back to this, just not today.
--
MST
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3)
2006-10-30 18:35 ` Adrian Bunk
2006-10-30 19:00 ` Michael S. Tsirkin
@ 2006-10-30 19:06 ` Hugh Dickins
2006-10-31 12:47 ` Martin Lorenz
2 siblings, 0 replies; 139+ messages in thread
From: Hugh Dickins @ 2006-10-30 19:06 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linus Torvalds, Jun'ichi Nomura, Michael S. Tsirkin,
Martin Lorenz, Pavel Machek, Andrew Morton,
Linux Kernel Mailing List, len.brown, linux-acpi, linux-pm,
Randy.Dunlap
On Mon, 30 Oct 2006, Adrian Bunk wrote:
>
> Martin's original bug report stated "now I loose ACPI events after
> suspend/resume. not every time, but roughly 3 out of 4 times."
> This seems to support your theory.
>
> But considering that two people have independently reported this as a
> 2.6.19-rc regression for similar hardware (Michael for a T60 and Martin
> for an X60), a problem in the kernel seems to be involved.
Add me to the list, on a T43p. I believe it was happening in -rc1,
but seems worse with -rc3 and current. But it's one of those things
which doesn't happen if you just go to test it out, only when you
need to suspend and resume for real.
Hugh
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
2006-10-30 18:47 ` Kyle Moffett
@ 2006-10-30 19:13 ` Matthew Wilcox
2006-10-31 5:39 ` Grant Grundler
0 siblings, 1 reply; 139+ messages in thread
From: Matthew Wilcox @ 2006-10-30 19:13 UTC (permalink / raw)
To: Kyle Moffett
Cc: Linus Torvalds, Adam J. Richter, akpm, bunk, greg, linux-kernel,
linux-pci, pavel, shemminger
On Mon, Oct 30, 2006 at 01:47:53PM -0500, Kyle Moffett wrote:
> Well, yes, but it would help some architectures. It would seem
> rather stupid to build a hardware limitation into a 64+ cpu system
> such that it cannot initialize or reconfigure multiple pieces of
> hardware at once. It also would help for more "mundane" systems such
> as my "Quad" G5 desktop which takes an appreciable time to probe all
> the various PCI, USB, SATA, and Firewire devices in the system.
Probing PCI devices really doesn't take that long. It's the extra stuff
the drivers do at ->probe that takes the time. And the stand-out
offender here is SCSI (and FC), which I'm working to fix. Firewire, USB
and SATA are somewhere intermediate.
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels
2006-10-30 19:13 ` Matthew Wilcox
@ 2006-10-31 5:39 ` Grant Grundler
0 siblings, 0 replies; 139+ messages in thread
From: Grant Grundler @ 2006-10-31 5:39 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Kyle Moffett, Linus Torvalds, Adam J. Richter, akpm, bunk, greg,
linux-kernel, linux-pci, pavel, shemminger
On Mon, Oct 30, 2006 at 12:13:07PM -0700, Matthew Wilcox wrote:
> Probing PCI devices really doesn't take that long.
Yeah - usually measured in "milliseconds".
> It's the extra stuff
> the drivers do at ->probe that takes the time. And the stand-out
> offender here is SCSI (and FC), which I'm working to fix. Firewire, USB
> and SATA are somewhere intermediate.
ISTR that the SATA Port timeout is 5 seconds or something like that.
And some cards have lots of ports...so my impression is SATA would
benefit alot from parallelism as well.
I'm certainly no SATA expert...maybe someone else could speak
more definitely on the topic of worst case SATA timeout.
thanks,
grant
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3)
2006-10-30 18:35 ` Adrian Bunk
2006-10-30 19:00 ` Michael S. Tsirkin
2006-10-30 19:06 ` Hugh Dickins
@ 2006-10-31 12:47 ` Martin Lorenz
2 siblings, 0 replies; 139+ messages in thread
From: Martin Lorenz @ 2006-10-31 12:47 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linus Torvalds, Jun'ichi Nomura, Michael S. Tsirkin,
Pavel Machek, Andrew Morton, Linux Kernel Mailing List, len.brown,
linux-acpi, linux-pm, Randy.Dunlap
On Mon, Oct 30, 2006 at 07:35:22PM +0100, Adrian Bunk wrote:
> On Mon, Oct 30, 2006 at 10:16:34AM -0800, Linus Torvalds wrote:
[...]
> Martin, Michael, can you send complete "dmesg -s 1000000" for both
> 2.6.18.1 and a non-working 2.6.19-rc kernel after resume?
> I don't have high hopes, but perhaps looking at the dmesg and/or
> diff'ing them might give a hint.
>
there are quite a few outputs from different kernels on my webpage
www.lorenz.eu.org/~mlo/kernel/?C=M;O=D
I hope I can go deeper into that tonight, but at the moment I can't promise
anything.
gruss
mlo
--
Dipl.-Ing. Martin Lorenz
They that can give up essential liberty
to obtain a little temporary safety
deserve neither liberty nor safety.
Benjamin Franklin
please encrypt your mail to me
GnuPG key-ID: F1AAD37D
get it here:
http://blackhole.pca.dfn.de:11371/pks/lookup?op=get&search=0xF1AAD37D
ICQ UIN: 33588107
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [linux-usb-devel] [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled
2006-10-28 21:39 ` Adrian Bunk
@ 2006-10-31 17:40 ` David Brownell
2006-10-31 18:07 ` Adrian Bunk
0 siblings, 1 reply; 139+ messages in thread
From: David Brownell @ 2006-10-31 17:40 UTC (permalink / raw)
To: linux-usb-devel
Cc: Adrian Bunk, Randy Dunlap, akpm, zippel, netdev, linux-kernel,
link, Christoph Hellwig, torvalds, greg, toralf.foerster
> > +#if defined(CONFIG_MII) || defined(CONFIG_MII_MODULE)
> > +#define HAVE_MII
> >...
>
> This seems to cause a CONFIG_USB_USBNET=y, CONFIG_MII=m breakage
> (as already described earlier in this thread)?
Well, "alluded to" not described. Fixable by the equivalent of
config USB_USBNET
...
depends on MII if MII != n
except that Kconfig doesn't comprehend conditionals like that.
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [linux-usb-devel] [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled
2006-10-31 17:40 ` [linux-usb-devel] " David Brownell
@ 2006-10-31 18:07 ` Adrian Bunk
2006-10-31 19:36 ` David Brownell
0 siblings, 1 reply; 139+ messages in thread
From: Adrian Bunk @ 2006-10-31 18:07 UTC (permalink / raw)
To: David Brownell
Cc: linux-usb-devel, Randy Dunlap, akpm, zippel, netdev, linux-kernel,
link, Christoph Hellwig, torvalds, greg, toralf.foerster
On Tue, Oct 31, 2006 at 10:40:15AM -0700, David Brownell wrote:
>
> > > +#if defined(CONFIG_MII) || defined(CONFIG_MII_MODULE)
> > > +#define HAVE_MII
> > >...
> >
> > This seems to cause a CONFIG_USB_USBNET=y, CONFIG_MII=m breakage
> > (as already described earlier in this thread)?
>
> Well, "alluded to" not described. Fixable by the equivalent of
>
> config USB_USBNET
> ...
> depends on MII if MII != n
>
> except that Kconfig doesn't comprehend conditionals like that.
You can express this in Kconfig:
depends MII || MII=n
But my suggestion was:
#if defined(CONFIG_MII) || (defined(CONFIG_MII_MODULE) && defined(MODULE))
Or simply select MII ...
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [linux-usb-devel] [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled
2006-10-31 18:07 ` Adrian Bunk
@ 2006-10-31 19:36 ` David Brownell
2006-11-01 1:23 ` Adrian Bunk
0 siblings, 1 reply; 139+ messages in thread
From: David Brownell @ 2006-10-31 19:36 UTC (permalink / raw)
To: Adrian Bunk
Cc: linux-usb-devel, Randy Dunlap, akpm, zippel, netdev, linux-kernel,
link, Christoph Hellwig, torvalds, greg, toralf.foerster
> > ...
> > depends on MII if MII != n
> >
> > except that Kconfig doesn't comprehend conditionals like that.
>
> You can express this in Kconfig:
> depends MII || MII=n
Except that:
Warning! Found recursive dependency: USB_USBNET USB_NET_AX8817X MII USB_USBNET
I think this is another case where Kconfig gets in the way and forces
introduction of a pseudovariable. I'll give that a try.
> But my suggestion was:
> #if defined(CONFIG_MII) || (defined(CONFIG_MII_MODULE) && defined(MODULE))
>
> Or simply select MII ...
Nope; those both prevent completely legit configurations.
MII is not required, except for those two adapter options.
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3)
2006-10-30 18:16 ` Linus Torvalds
2006-10-30 18:35 ` Adrian Bunk
2006-10-30 18:58 ` Michael S. Tsirkin
@ 2006-10-31 21:15 ` Michael S. Tsirkin
2 siblings, 0 replies; 139+ messages in thread
From: Michael S. Tsirkin @ 2006-10-31 21:15 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jun'ichi Nomura, Martin Lorenz, Pavel Machek, Adrian Bunk,
Andrew Morton, Linux Kernel Mailing List, len.brown, linux-acpi,
linux-pm, Randy.Dunlap
Quoting r. Linus Torvalds <torvalds@osdl.org>:
> Subject: Re: 2.6.19-rc3: known unfixed regressions (v3)
>
>
>
> On Mon, 30 Oct 2006, Jun'ichi Nomura wrote:
> >
> > Please revert the patch. I'll fix the wrong error handling.
> >
> > I'm not sure reverting the patch solves the ACPI problem
> > because Michael's kernel seems not having any user of
> > bd_claim_by_kobject.
>
> Yeah, doing a grep does seem to imply that there is no way that those
> changes could matter.
>
> Michael, can you double-check? I think Jun'ichi is right - in your kernel,
> according to the config posted on bugzilla, I don't think there should be
> a single caller of bd_claim_by_disk, since CONFIG_MD is disabled.
I double-checked, and of course you are right - the issues resurfaced after some
more use, even with the patch reverted. I've written some scripts that do some
compiles from scratch, and suspend/resume several times. Plan to try bi-secting
with that and see what that will come up with.
OTOH, from the discussion it seems just randomly pointing a finger at a patch
has uncovered some bugs - so maybe we should do this a bit more :)
--
MST
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [linux-usb-devel] [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled
2006-10-31 19:36 ` David Brownell
@ 2006-11-01 1:23 ` Adrian Bunk
2006-11-02 20:19 ` David Brownell
0 siblings, 1 reply; 139+ messages in thread
From: Adrian Bunk @ 2006-11-01 1:23 UTC (permalink / raw)
To: David Brownell
Cc: linux-usb-devel, Randy Dunlap, akpm, zippel, netdev, linux-kernel,
link, Christoph Hellwig, torvalds, greg, toralf.foerster
On Tue, Oct 31, 2006 at 11:36:52AM -0800, David Brownell wrote:
>
> > > ...
> > > depends on MII if MII != n
> > >
> > > except that Kconfig doesn't comprehend conditionals like that.
> >
> > You can express this in Kconfig:
> > depends MII || MII=n
>
> Except that:
>
> Warning! Found recursive dependency: USB_USBNET USB_NET_AX8817X MII USB_USBNET
>
> I think this is another case where Kconfig gets in the way and forces
> introduction of a pseudovariable. I'll give that a try.
>
> > But my suggestion was:
> > #if defined(CONFIG_MII) || (defined(CONFIG_MII_MODULE) && defined(MODULE))
> >
> > Or simply select MII ...
>
> Nope; those both prevent completely legit configurations.
> MII is not required, except for those two adapter options.
What should work (with the USB_NET_MCS7830 part from Randy's patch
removed) together with your patch and the
#if defined(CONFIG_MII) || (defined(CONFIG_MII_MODULE) && defined(MODULE))
is:
config USB_USBNET
tristate "Multi-purpose USB Networking Framework"
select MII if USB_NET_AX8817X!=n || USB_NET_MCS7830!=n
---help---
...
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 139+ messages in thread
* 2.6.19-rc <-> ThinkPads
2006-10-30 13:56 ` Michael S. Tsirkin
2006-10-30 16:17 ` Jun'ichi Nomura
@ 2006-11-01 3:01 ` Adrian Bunk
2006-11-01 3:15 ` Len Brown
` (2 more replies)
1 sibling, 3 replies; 139+ messages in thread
From: Adrian Bunk @ 2006-11-01 3:01 UTC (permalink / raw)
To: Hugh Dickins
Cc: Michael S. Tsirkin, Pavel Machek, Linus Torvalds, Andrew Morton,
Linux Kernel Mailing List, len.brown, linux-acpi, linux-pm,
Martin Lorenz
FYI:
Subject : Thinkpad R50p: boot fail with (lapic && on_battery)
References : http://lkml.org/lkml/2006/10/31/333
Submitter : Ernst Herzberg <earny@net4u.de>
Status : submitter was asked to bisect
It seems to be completely unrelated (except that it's also a ThinkPad),
but it might be worth a try whether a (non-SMP) kernel without APIC
support fixes the issues after resume.
Hugh, your laptop seems to be a non-SMP laptop.
Do you have APIC enabled, and if yes does disabling help?
cu
Adrian
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 19
EXTRAVERSION = -rc4
NAME=ThinkPad Killer
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads
2006-11-01 3:01 ` 2.6.19-rc <-> ThinkPads Adrian Bunk
@ 2006-11-01 3:15 ` Len Brown
2006-11-01 5:11 ` Ernst Herzberg
2006-11-01 16:36 ` Hugh Dickins
2006-11-04 3:49 ` 2.6.19-rc <-> ThinkPads, summary Adrian Bunk
2 siblings, 1 reply; 139+ messages in thread
From: Len Brown @ 2006-11-01 3:15 UTC (permalink / raw)
To: Adrian Bunk
Cc: Hugh Dickins, Michael S. Tsirkin, Pavel Machek, Linus Torvalds,
Andrew Morton, Linux Kernel Mailing List, linux-acpi, linux-pm,
Martin Lorenz
The BIOS disables the LAPIC for a reason.
A couple of years ago Linux made the mistake of enabling the LAPIC
that the BIOS disabled, and all hell broke loose.
We fixed that bug about a year ago, but left "lapic"
to force it on for those where forcing it to be enabled actually
works (eg. some folks want the NMI profiling on their IOAPIC-less laptop)
But if you force the lapic to be enabled, you are running the system
in a mode not supported by the manufacturer and you are on your own.
I don't see an indication that this is a bug.
If it used to work and it is important to you,
then run the old software where it used to work --
because chances are good that it worked by accident.
-Len
On Tuesday 31 October 2006 22:01, Adrian Bunk wrote:
> FYI:
>
> Subject : Thinkpad R50p: boot fail with (lapic && on_battery)
> References : http://lkml.org/lkml/2006/10/31/333
> Submitter : Ernst Herzberg <earny@net4u.de>
> Status : submitter was asked to bisect
>
> It seems to be completely unrelated (except that it's also a ThinkPad),
> but it might be worth a try whether a (non-SMP) kernel without APIC
> support fixes the issues after resume.
>
> Hugh, your laptop seems to be a non-SMP laptop.
> Do you have APIC enabled, and if yes does disabling help?
>
> cu
> Adrian
>
>
> VERSION = 2
> PATCHLEVEL = 6
> SUBLEVEL = 19
> EXTRAVERSION = -rc4
> NAME=ThinkPad Killer
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads
2006-11-01 3:15 ` Len Brown
@ 2006-11-01 5:11 ` Ernst Herzberg
2006-11-01 5:26 ` Linus Torvalds
0 siblings, 1 reply; 139+ messages in thread
From: Ernst Herzberg @ 2006-11-01 5:11 UTC (permalink / raw)
To: Len Brown
Cc: Adrian Bunk, Hugh Dickins, Michael S. Tsirkin, Pavel Machek,
Linus Torvalds, Andrew Morton, Linux Kernel Mailing List,
linux-acpi, linux-pm, Martin Lorenz
On Wednesday 01 November 2006 04:15, Len Brown wrote:
> The BIOS disables the LAPIC for a reason.
> A couple of years ago Linux made the mistake of enabling the LAPIC
> that the BIOS disabled, and all hell broke loose.
> We fixed that bug about a year ago, but left "lapic"
> to force it on for those where forcing it to be enabled actually
> works (eg. some folks want the NMI profiling on their IOAPIC-less laptop)
>
> But if you force the lapic to be enabled, you are running the system
> in a mode not supported by the manufacturer and you are on your own.
>
> I don't see an indication that this is a bug.
> If it used to work and it is important to you,
> then run the old software where it used to work --
> because chances are good that it worked by accident.
Maybe. But why does it boot with AC connected and lapic enabled, bot not if AC
is disconnected and lapic enabled? If have no problem to run this laptop
without lapic, i don't relly need it. But i wondering that this happens only
if the machine runs (by accident:) on battery.
still bisecting, will report the result.
<earny>
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads
2006-11-01 5:11 ` Ernst Herzberg
@ 2006-11-01 5:26 ` Linus Torvalds
2006-11-01 5:54 ` Michael S. Tsirkin
2006-11-01 13:50 ` Stefan Seyfried
0 siblings, 2 replies; 139+ messages in thread
From: Linus Torvalds @ 2006-11-01 5:26 UTC (permalink / raw)
To: Ernst Herzberg
Cc: Len Brown, Adrian Bunk, Hugh Dickins, Michael S. Tsirkin,
Pavel Machek, Andrew Morton, Linux Kernel Mailing List,
linux-acpi, linux-pm, Martin Lorenz
On Wed, 1 Nov 2006, Ernst Herzberg wrote:
>
> still bisecting, will report the result.
Figuring out what caused an apparent change of behaviour is definitely a
good idea - it might give us some clue to what really is going on.
(Or it might not. Sometimes the patch that triggers changes really doesn't
seem to have anything to do with anything, and it literally was just a
latent bug that just happened to be exposed by something that had nothing
to do with anything at all but perhaps timing. But that's pretty rare in
the end. It happens, but it's definitely not the common case at all, and I
think it's great that you're bisecting even if there is a possibility
that we'll be left with a big "Huh? Whaa?" as the end result ;^)
Linus
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads
2006-11-01 5:26 ` Linus Torvalds
@ 2006-11-01 5:54 ` Michael S. Tsirkin
2006-11-01 6:16 ` Linus Torvalds
2006-11-01 6:18 ` Michael S. Tsirkin
2006-11-01 13:50 ` Stefan Seyfried
1 sibling, 2 replies; 139+ messages in thread
From: Michael S. Tsirkin @ 2006-11-01 5:54 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ernst Herzberg, Len Brown, Adrian Bunk, Hugh Dickins,
Pavel Machek, Andrew Morton, Linux Kernel Mailing List,
linux-acpi, linux-pm, Martin Lorenz, Andi Kleen
Quoting r. Linus Torvalds <torvalds@osdl.org>:
> Subject: Re: 2.6.19-rc <-> ThinkPads
>
>
>
> On Wed, 1 Nov 2006, Ernst Herzberg wrote:
> >
> > still bisecting, will report the result.
>
> Figuring out what caused an apparent change of behaviour is definitely a
> good idea - it might give us some clue to what really is going on.
I've been bisecting ACPI/suspend thinkpad issue myself and I seem to get
eea0e11c1f0d6ef89e64182b2f1223a4ca2b74a2 good,
cf4c6a2f27f5db810b69dcb1da7f194489e8ff88 bad.
At least this makes some sense since the log speaks about suspend. Problem is,
ACPI issues are in rare cases going away for a while for me so this needs more
testing before I can say for sure about the good part - I already had one false
negative. What I plan to do is using eea0e11c1f0d6ef89e64182b2f1223a4ca2b74a2
for a couple of days and see how this works out.
--
MST
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads
2006-11-01 5:54 ` Michael S. Tsirkin
@ 2006-11-01 6:16 ` Linus Torvalds
2006-11-01 17:25 ` Andi Kleen
2006-11-01 22:35 ` Bill Davidsen
2006-11-01 6:18 ` Michael S. Tsirkin
1 sibling, 2 replies; 139+ messages in thread
From: Linus Torvalds @ 2006-11-01 6:16 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Ernst Herzberg, Len Brown, Adrian Bunk, Hugh Dickins,
Pavel Machek, Andrew Morton, Linux Kernel Mailing List,
linux-acpi, linux-pm, Martin Lorenz, Andi Kleen
On Wed, 1 Nov 2006, Michael S. Tsirkin wrote:
>
> I've been bisecting ACPI/suspend thinkpad issue myself and I seem to get
> eea0e11c1f0d6ef89e64182b2f1223a4ca2b74a2 good,
> cf4c6a2f27f5db810b69dcb1da7f194489e8ff88 bad.
Very interesting..
That commit cf4c6a2f on the face of it looks like an obvious cleanup, but
looking closer, it actually changes the order of the apic writes in many
cases (high word first -> low word first).
It also does something else that looks really really wrong: it turns an
atomic "update ioapic and set irq-info" into two separate events, where
interrupts can happen in between. Same goes for resume (instead of
atomically changing all entries with the ioapic lock held, it now does
them individually, and locks them individually).
I wonder if the order matters more, though. Andi? We _used_ to write the
high word first, and I think the order matters. The low word contains the
enable bit, for example, so when enabling an interrupt, you should write
the low word last, when you disable it you should write the low word
first.
And that's exactly what we _used_ to do, and it's what that particular
commit totally and utterly _broke_.
I think that commit should either be reverted, or the code should be fixed
to do the writes in the proper order.
I suspect reverting it is the right thing to do - the patch only
introduces bugs, an doesn't actually _fix_ anything, it just "cleans
things up".
Andi, you need to be a hell of a lot more careful! Apparently x86-64 is
also totally broken in this regard, because somebody didn't realize that
the ordering _matters_.
Linus
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads
2006-11-01 5:54 ` Michael S. Tsirkin
2006-11-01 6:16 ` Linus Torvalds
@ 2006-11-01 6:18 ` Michael S. Tsirkin
2006-11-01 9:33 ` Pavel Machek
2006-11-01 17:17 ` Andi Kleen
1 sibling, 2 replies; 139+ messages in thread
From: Michael S. Tsirkin @ 2006-11-01 6:18 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ernst Herzberg, Len Brown, Adrian Bunk, Hugh Dickins,
Pavel Machek, Andrew Morton, Linux Kernel Mailing List,
linux-acpi, linux-pm, Martin Lorenz, Andi Kleen
Quoting r. Michael S. Tsirkin <mst@mellanox.co.il>:
> What I plan to do is using eea0e11c1f0d6ef89e64182b2f1223a4ca2b74a2
> for a couple of days and see how this works out.
Ugh. Unfortunately in that kernel version, the e1000 driver says
the eeprom checksum is bad (works fine with 2.6.19-rc3).
So, I tried some suspends/resumes and things seem to work, but
I won't be able to test it under real use conditions.
But maybe its another red herring?
Andi, could you maybe look at that commit and tell me whether
it could cause troubles with ACPI after suspend/resume even
theoretically?
--
MST
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads
2006-11-01 6:18 ` Michael S. Tsirkin
@ 2006-11-01 9:33 ` Pavel Machek
2006-11-01 12:02 ` Michael S. Tsirkin
2006-11-01 17:17 ` Andi Kleen
1 sibling, 1 reply; 139+ messages in thread
From: Pavel Machek @ 2006-11-01 9:33 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Linus Torvalds, Ernst Herzberg, Len Brown, Adrian Bunk,
Hugh Dickins, Andrew Morton, Linux Kernel Mailing List,
linux-acpi, linux-pm, Martin Lorenz, Andi Kleen
On Wed 2006-11-01 08:18:57, Michael S. Tsirkin wrote:
> Quoting r. Michael S. Tsirkin <mst@mellanox.co.il>:
> > What I plan to do is using eea0e11c1f0d6ef89e64182b2f1223a4ca2b74a2
> > for a couple of days and see how this works out.
>
> Ugh. Unfortunately in that kernel version, the e1000 driver says
> the eeprom checksum is bad (works fine with 2.6.19-rc3).
> So, I tried some suspends/resumes and things seem to work, but
> I won't be able to test it under real use conditions.
Just comment out the eeprom checksum check...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads
2006-11-01 9:33 ` Pavel Machek
@ 2006-11-01 12:02 ` Michael S. Tsirkin
0 siblings, 0 replies; 139+ messages in thread
From: Michael S. Tsirkin @ 2006-11-01 12:02 UTC (permalink / raw)
To: Pavel Machek
Cc: Linus Torvalds, Ernst Herzberg, Len Brown, Adrian Bunk,
Hugh Dickins, Andrew Morton, Linux Kernel Mailing List,
linux-acpi, linux-pm, Martin Lorenz, Andi Kleen
Quoting Pavel Machek <pavel@ucw.cz>:
> > > What I plan to do is using eea0e11c1f0d6ef89e64182b2f1223a4ca2b74a2
> > > for a couple of days and see how this works out.
> >
> > Ugh. Unfortunately in that kernel version, the e1000 driver says
> > the eeprom checksum is bad (works fine with 2.6.19-rc3).
> > So, I tried some suspends/resumes and things seem to work, but
> > I won't be able to test it under real use conditions.
>
> Just comment out the eeprom checksum check...
>
Right, that worked, thanks.
I'm running on eea0e11c1f0d6ef89e64182b2f1223a4ca2b74a2 now, seems to be fine
so far.
--
MST
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads
2006-11-01 5:26 ` Linus Torvalds
2006-11-01 5:54 ` Michael S. Tsirkin
@ 2006-11-01 13:50 ` Stefan Seyfried
1 sibling, 0 replies; 139+ messages in thread
From: Stefan Seyfried @ 2006-11-01 13:50 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andrew Morton, linux-acpi, linux-pm, Michael S. Tsirkin,
Hugh Dickins, Linux Kernel Mailing List, Martin Lorenz,
Adrian Bunk, Ernst Herzberg
On Tue, Oct 31, 2006 at 09:26:12PM -0800, Linus Torvalds wrote:
> (Or it might not. Sometimes the patch that triggers changes really doesn't
> seem to have anything to do with anything, and it literally was just a
> latent bug that just happened to be exposed by something that had nothing
> to do with anything at all but perhaps timing.
Especially when "booting on AC works, but on battery it doesn't", (or the
other way round), looking at timing problems seems sane to me.
--
Stefan Seyfried
QA / R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out."
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads
2006-11-01 3:01 ` 2.6.19-rc <-> ThinkPads Adrian Bunk
2006-11-01 3:15 ` Len Brown
@ 2006-11-01 16:36 ` Hugh Dickins
2006-11-04 3:49 ` 2.6.19-rc <-> ThinkPads, summary Adrian Bunk
2 siblings, 0 replies; 139+ messages in thread
From: Hugh Dickins @ 2006-11-01 16:36 UTC (permalink / raw)
To: Adrian Bunk
Cc: Michael S. Tsirkin, Pavel Machek, Linus Torvalds, Andrew Morton,
Linux Kernel Mailing List, len.brown, linux-acpi, linux-pm,
Martin Lorenz
On Wed, 1 Nov 2006, Adrian Bunk wrote:
>
> Subject : Thinkpad R50p: boot fail with (lapic && on_battery)
> References : http://lkml.org/lkml/2006/10/31/333
> Submitter : Ernst Herzberg <earny@net4u.de>
> Status : submitter was asked to bisect
>
> It seems to be completely unrelated (except that it's also a ThinkPad),
> but it might be worth a try whether a (non-SMP) kernel without APIC
> support fixes the issues after resume.
>
> Hugh, your laptop seems to be a non-SMP laptop.
That's right.
> Do you have APIC enabled, and if yes does disabling help?
Yes, I do. But I've just tried booting with "noapic" and with "nolapic"
and with "noapic nolapic", but none of those make any difference.
(That is, they make no difference to the FnF4-ineffective-after-resume
behaviour that I'm finding fairly easy to reproduce at will today on
2.6.19-rc4; whereas yesterday it was seeming to me that -rc4 was much
better than -rc3 in this regard. Something I have learnt today is that
the key is ineffective "for a while", but may become effective later.
It's conceivable that the behaviour I'm reproducing today is not quite
the same as what I was experiencing earlier with real-life suspends.)
More to the point, with great hope in my heart, I've tried backing
out Andi's git-cf4c6a2f27f5db810b69dcb1da7f194489e8ff88.patch
to arch/i386/kernel/io_apic.c, the one which Michael and Linus have
homed in on. But sadly that makes no difference for me: I'd better
get down to my own bisection.
Hugh
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads
2006-11-01 6:18 ` Michael S. Tsirkin
2006-11-01 9:33 ` Pavel Machek
@ 2006-11-01 17:17 ` Andi Kleen
1 sibling, 0 replies; 139+ messages in thread
From: Andi Kleen @ 2006-11-01 17:17 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Linus Torvalds, Ernst Herzberg, Len Brown, Adrian Bunk,
Hugh Dickins, Pavel Machek, Andrew Morton,
Linux Kernel Mailing List, linux-acpi, linux-pm, Martin Lorenz
On Wednesday 01 November 2006 07:18, Michael S. Tsirkin wrote:
> Quoting r. Michael S. Tsirkin <mst@mellanox.co.il>:
> > What I plan to do is using eea0e11c1f0d6ef89e64182b2f1223a4ca2b74a2
> > for a couple of days and see how this works out.
>
> Ugh. Unfortunately in that kernel version, the e1000 driver says
> the eeprom checksum is bad (works fine with 2.6.19-rc3).
> So, I tried some suspends/resumes and things seem to work, but
> I won't be able to test it under real use conditions.
>
> But maybe its another red herring?
> Andi, could you maybe look at that commit and tell me whether
> it could cause troubles with ACPI after suspend/resume even
> theoretically?
It touches suspend/resume so it could break something theoretically.
-Andi
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads
2006-11-01 6:16 ` Linus Torvalds
@ 2006-11-01 17:25 ` Andi Kleen
2006-11-01 18:12 ` Michael S. Tsirkin
2006-11-01 18:25 ` Linus Torvalds
2006-11-01 22:35 ` Bill Davidsen
1 sibling, 2 replies; 139+ messages in thread
From: Andi Kleen @ 2006-11-01 17:25 UTC (permalink / raw)
To: Linus Torvalds
Cc: Michael S. Tsirkin, Ernst Herzberg, Len Brown, Adrian Bunk,
Hugh Dickins, Pavel Machek, Andrew Morton,
Linux Kernel Mailing List, linux-acpi, linux-pm, Martin Lorenz
> I suspect reverting it is the right thing to do - the patch only
> introduces bugs, an doesn't actually _fix_ anything, it just "cleans
> things up".
Ok please revert the i386 patch for now then if it fixes the ThinkPads.
The x86-64 version should be probably fixed too, but doesn't cleanly. I will
send you later a patch to fix this there properly.
-Andi
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads
2006-11-01 17:25 ` Andi Kleen
@ 2006-11-01 18:12 ` Michael S. Tsirkin
2006-11-01 18:25 ` Linus Torvalds
1 sibling, 0 replies; 139+ messages in thread
From: Michael S. Tsirkin @ 2006-11-01 18:12 UTC (permalink / raw)
To: Andi Kleen
Cc: Linus Torvalds, Ernst Herzberg, Len Brown, Adrian Bunk,
Hugh Dickins, Pavel Machek, Andrew Morton,
Linux Kernel Mailing List, linux-acpi, linux-pm, Martin Lorenz
Quoting r. Andi Kleen <ak@suse.de>:
> Subject: Re: 2.6.19-rc <-> ThinkPads
>
>
> > I suspect reverting it is the right thing to do - the patch only
> > introduces bugs, an doesn't actually _fix_ anything, it just "cleans
> > things up".
>
> Ok please revert the i386 patch for now then if it fixes the ThinkPads.
> The x86-64 version should be probably fixed too, but doesn't cleanly. I will
> send you later a patch to fix this there properly.
Could you sent the patch so I can test it, pls?
git revert creates conflicts.
--
MST
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads
2006-11-01 17:25 ` Andi Kleen
2006-11-01 18:12 ` Michael S. Tsirkin
@ 2006-11-01 18:25 ` Linus Torvalds
2006-11-01 19:33 ` Michael S. Tsirkin
2006-11-01 19:34 ` Andi Kleen
1 sibling, 2 replies; 139+ messages in thread
From: Linus Torvalds @ 2006-11-01 18:25 UTC (permalink / raw)
To: Andi Kleen
Cc: Michael S. Tsirkin, Ernst Herzberg, Len Brown, Adrian Bunk,
Hugh Dickins, Pavel Machek, Andrew Morton,
Linux Kernel Mailing List, linux-acpi, linux-pm, Martin Lorenz
On Wed, 1 Nov 2006, Andi Kleen wrote:
>
> Ok please revert the i386 patch for now then if it fixes the ThinkPads.
> The x86-64 version should be probably fixed too, but doesn't cleanly. I will
> send you later a patch to fix this there properly.
Actually, I should have just fixed the ordering. I did some cleanups too,
but those are unrelated (except in the sense that I wanted to look at the
assembly code, and the cleanups made the code generation at least half-way
sane!)
I've pushed out the changes, but here is the part that may or may not
matter for anybody who wants to test it if they don't use git or if it
hasn't mirrored out yet. Michael? Martin?
Andi: I think the patches should work pretty much as-is for x86-64 too,
since all the issues would seem to be similar.
I'm not entirely happy with "ioapic_write_entry()" now either (if we
change an entry that was already unmasked, we should probably mask it
first by writing the low word with the mask bit set, then write the high
word, and then write the low word again), but
- this makes us match the ordering we _used_ to have, so if the cleanup
broke things for people, this should unbreak it, and at least not be
any worse than it used to be.
- when we write new unmasked entries, they all _should_ have been masked
before, so hopefully the "change a unmasked entry while it's unmasked"
case doesn't actually ever happen. But I didn't actually _check_.
Somebody should look into that case. Does anybody feel like they want to
learn more about the IO-APIC? Halloween is over and gone, but if you want
to scare small children _next_ year, telling them about the IO-APIC is
likely a good strategy.
Linus
---
commit f9dadfa71bc594df09044da61d1c72701121d802
Author: Linus Torvalds <torvalds@macmini.osdl.org>
Date: Wed Nov 1 10:05:35 2006 -0800
i386: write IO APIC irq routing entries in correct order
Since the "mask" bit is in the low word, when we write a new entry, we
need to write the high word first, before we potentially unmask it.
The exception is when we actually want to mask the interrupt, in which
case we want to write the low word first to make sure that the high word
doesn't change while the interrupt routing is still active.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
diff --git a/arch/i386/kernel/io_apic.c b/arch/i386/kernel/io_apic.c
index eb10bd5..507983c 100644
--- a/arch/i386/kernel/io_apic.c
+++ b/arch/i386/kernel/io_apic.c
@@ -147,12 +147,34 @@ static struct IO_APIC_route_entry ioapic
return eu.entry;
}
+/*
+ * When we write a new IO APIC routing entry, we need to write the high
+ * word first! If the mask bit in the low word is clear, we will enable
+ * the interrupt, and we need to make sure the entry is fully populated
+ * before that happens.
+ */
static void ioapic_write_entry(int apic, int pin, struct IO_APIC_route_entry e)
{
unsigned long flags;
union entry_union eu;
eu.entry = e;
spin_lock_irqsave(&ioapic_lock, flags);
+ io_apic_write(apic, 0x11 + 2*pin, eu.w2);
+ io_apic_write(apic, 0x10 + 2*pin, eu.w1);
+ spin_unlock_irqrestore(&ioapic_lock, flags);
+}
+
+/*
+ * When we mask an IO APIC routing entry, we need to write the low
+ * word first, in order to set the mask bit before we change the
+ * high bits!
+ */
+static void ioapic_mask_entry(int apic, int pin)
+{
+ unsigned long flags;
+ union entry_union eu = { .entry.mask = 1 };
+
+ spin_lock_irqsave(&ioapic_lock, flags);
io_apic_write(apic, 0x10 + 2*pin, eu.w1);
io_apic_write(apic, 0x11 + 2*pin, eu.w2);
spin_unlock_irqrestore(&ioapic_lock, flags);
@@ -274,9 +296,7 @@ static void clear_IO_APIC_pin(unsigned i
/*
* Disable it in the IO-APIC irq-routing table:
*/
- memset(&entry, 0, sizeof(entry));
- entry.mask = 1;
- ioapic_write_entry(apic, pin, entry);
+ ioapic_mask_entry(apic, pin);
}
static void clear_IO_APIC (void)
^ permalink raw reply related [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads
2006-11-01 18:25 ` Linus Torvalds
@ 2006-11-01 19:33 ` Michael S. Tsirkin
2006-11-01 19:44 ` Linus Torvalds
2006-11-01 19:34 ` Andi Kleen
1 sibling, 1 reply; 139+ messages in thread
From: Michael S. Tsirkin @ 2006-11-01 19:33 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andi Kleen, Ernst Herzberg, Len Brown, Adrian Bunk, Hugh Dickins,
Pavel Machek, Andrew Morton, Linux Kernel Mailing List,
linux-acpi, linux-pm, Martin Lorenz
Quoting r. Linus Torvalds <torvalds@osdl.org>:
> Subject: Re: 2.6.19-rc <-> ThinkPads
>
>
>
> On Wed, 1 Nov 2006, Andi Kleen wrote:
> >
> > Ok please revert the i386 patch for now then if it fixes the ThinkPads.
> > The x86-64 version should be probably fixed too, but doesn't cleanly. I will
> > send you later a patch to fix this there properly.
>
> Actually, I should have just fixed the ordering. I did some cleanups too,
> but those are unrelated (except in the sense that I wanted to look at the
> assembly code, and the cleanups made the code generation at least half-way
> sane!)
>
> I've pushed out the changes, but here is the part that may or may not
> matter for anybody who wants to test it if they don't use git or if it
> hasn't mirrored out yet. Michael? Martin?
I pulled the latest git, and seems to work for me, thanks.
This still could be a false negative (happened already) so I'll
continue using this, and will post the results.
> Andi: I think the patches should work pretty much as-is for x86-64 too,
> since all the issues would seem to be similar.
>
> I'm not entirely happy with "ioapic_write_entry()" now either (if we
> change an entry that was already unmasked, we should probably mask it
> first by writing the low word with the mask bit set, then write the high
> word, and then write the low word again), but
>
> - this makes us match the ordering we _used_ to have, so if the cleanup
> broke things for people, this should unbreak it, and at least not be
> any worse than it used to be.
>
> - when we write new unmasked entries, they all _should_ have been masked
> before, so hopefully the "change a unmasked entry while it's unmasked"
> case doesn't actually ever happen. But I didn't actually _check_.
>
> Somebody should look into that case. Does anybody feel like they want to
> learn more about the IO-APIC? Halloween is over and gone, but if you want
> to scare small children _next_ year, telling them about the IO-APIC is
> likely a good strategy.
>
> Linus
Hmm, sounds interesting :)
Is this a good place to start (I'm feeling lucky hit for IO-APIC)?
http://www.intel.com/design/chipsets/datashts/290566.htm
--
MST
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads
2006-11-01 18:25 ` Linus Torvalds
2006-11-01 19:33 ` Michael S. Tsirkin
@ 2006-11-01 19:34 ` Andi Kleen
2006-11-01 19:52 ` Linus Torvalds
1 sibling, 1 reply; 139+ messages in thread
From: Andi Kleen @ 2006-11-01 19:34 UTC (permalink / raw)
To: Linus Torvalds
Cc: Michael S. Tsirkin, Ernst Herzberg, Len Brown, Adrian Bunk,
Hugh Dickins, Pavel Machek, Andrew Morton,
Linux Kernel Mailing List, linux-acpi, linux-pm, Martin Lorenz
On Wednesday 01 November 2006 19:25, Linus Torvalds wrote:
>
> On Wed, 1 Nov 2006, Andi Kleen wrote:
> >
> > Ok please revert the i386 patch for now then if it fixes the ThinkPads.
> > The x86-64 version should be probably fixed too, but doesn't cleanly. I will
> > send you later a patch to fix this there properly.
>
> Actually, I should have just fixed the ordering. I did some cleanups too,
> but those are unrelated (except in the sense that I wanted to look at the
> assembly code, and the cleanups made the code generation at least half-way
> sane!)
Thanks.
Some of them are still different than the old code now, but that's probably
ok.
But the irq race you pointed out is still there (unless you fixed it in a differnet patch)
I don't know if it makes
a difference, but here is a patch to fix it.
-Andi
Fix race in IO-APIC routing entry setup.
Interrupt could happen between setting the IO-APIC entry
and setting its interrupt data.
Pointed out by Linus.
Signed-off-by: Andi Kleen <ak@suse.de>
Index: linux/arch/i386/kernel/io_apic.c
===================================================================
--- linux.orig/arch/i386/kernel/io_apic.c
+++ linux/arch/i386/kernel/io_apic.c
@@ -1298,10 +1298,12 @@ static void __init setup_IO_APIC_irqs(vo
if (!apic && (irq < 16))
disable_8259A_irq(irq);
}
+ local_irq_save(flags);
ioapic_write_entry(apic, pin, entry);
- spin_lock_irqsave(&ioapic_lock, flags);
+ spin_lock(&ioapic_lock);
set_native_irq_info(irq, TARGET_CPUS);
- spin_unlock_irqrestore(&ioapic_lock, flags);
+ spin_unlock(&ioapic_lock);
+ local_irq_restore(flags);
}
}
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads
2006-11-01 19:33 ` Michael S. Tsirkin
@ 2006-11-01 19:44 ` Linus Torvalds
0 siblings, 0 replies; 139+ messages in thread
From: Linus Torvalds @ 2006-11-01 19:44 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Andi Kleen, Ernst Herzberg, Len Brown, Adrian Bunk, Hugh Dickins,
Pavel Machek, Andrew Morton, Linux Kernel Mailing List,
linux-acpi, linux-pm, Martin Lorenz
On Wed, 1 Nov 2006, Michael S. Tsirkin wrote:
> > I've pushed out the changes, but here is the part that may or may not
> > matter for anybody who wants to test it if they don't use git or if it
> > hasn't mirrored out yet. Michael? Martin?
>
> I pulled the latest git, and seems to work for me, thanks.
> This still could be a false negative (happened already) so I'll
> continue using this, and will post the results.
Ok, thanks.
> > Somebody should look into that case. Does anybody feel like they want to
> > learn more about the IO-APIC? Halloween is over and gone, but if you want
> > to scare small children _next_ year, telling them about the IO-APIC is
> > likely a good strategy.
>
> Hmm, sounds interesting :)
> Is this a good place to start (I'm feeling lucky hit for IO-APIC)?
> http://www.intel.com/design/chipsets/datashts/290566.htm
Yeah, that's the datasheet. Note that a lot of the IO-APIC complexity is
not so much in the programming interfaces themselves, but in keeping track
of how the heck the thing is connected (ie ExtINT vs SCI vs "normal apic
interrupt" etc).
Linus
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads
2006-11-01 19:34 ` Andi Kleen
@ 2006-11-01 19:52 ` Linus Torvalds
2006-11-01 21:15 ` Andi Kleen
0 siblings, 1 reply; 139+ messages in thread
From: Linus Torvalds @ 2006-11-01 19:52 UTC (permalink / raw)
To: Andi Kleen
Cc: Michael S. Tsirkin, Ernst Herzberg, Len Brown, Adrian Bunk,
Hugh Dickins, Pavel Machek, Andrew Morton,
Linux Kernel Mailing List, linux-acpi, linux-pm, Martin Lorenz
On Wed, 1 Nov 2006, Andi Kleen wrote:
>
> Fix race in IO-APIC routing entry setup.
>
> Interrupt could happen between setting the IO-APIC entry
> and setting its interrupt data.
This doesn't fix anything at all.
The interrupt can come in on another CPU, and if we end up having an
affinity change due to that, we then have "set_ioapic_affinity_irq()"
called on that other irq, and it might get to mess with the cpumask
because we dropped the ioapic_lock.
In other words, the problem is not that interrupts were re-enabled, the
problem is literally that the locking is _wrong_.
It's a small window, but we simply should not release the ioapic_lock in
between setting the routing and doing the "set_native_irq_info()" call.
So I think doing the locking inside "ioapic_write_entry()" is simply
fundamentally wrong. When you did the cleanup, your commit message talked
about how it might add a few more lock/unlock things:
In a few cases the IO APIC lock is taken more often now, but this
isn't a problem because it's all initialization/shutdown only
slow path code.
but the point is, this is not about "performance". It's about
_correctness_.
Linus
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads
2006-11-01 19:52 ` Linus Torvalds
@ 2006-11-01 21:15 ` Andi Kleen
0 siblings, 0 replies; 139+ messages in thread
From: Andi Kleen @ 2006-11-01 21:15 UTC (permalink / raw)
To: Linus Torvalds
Cc: Michael S. Tsirkin, Ernst Herzberg, Len Brown, Adrian Bunk,
Hugh Dickins, Pavel Machek, Andrew Morton,
Linux Kernel Mailing List, linux-acpi, linux-pm, Martin Lorenz
On Wednesday 01 November 2006 20:52, Linus Torvalds wrote:
>
> On Wed, 1 Nov 2006, Andi Kleen wrote:
> >
> > Fix race in IO-APIC routing entry setup.
> >
> > Interrupt could happen between setting the IO-APIC entry
> > and setting its interrupt data.
>
> This doesn't fix anything at all.
>
> The interrupt can come in on another CPU,
Only BP should be active at this point. At least not until
we implement IO-APIC hotplug, but so far that isn't there.
Ok in theory the BIOS could have put the other CPUs into
weird states where they are still doing something and causing
interrupts, but that would be a BIOS bug.
I suppose it could happen with kexec, but that has still
other problems anyways.
The common case of no kexec shouldn't be affected at least.
-Andi
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads
2006-11-01 6:16 ` Linus Torvalds
2006-11-01 17:25 ` Andi Kleen
@ 2006-11-01 22:35 ` Bill Davidsen
1 sibling, 0 replies; 139+ messages in thread
From: Bill Davidsen @ 2006-11-01 22:35 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andrew Morton, linux-pm, Ernst Herzberg, Andi Kleen,
Linux Kernel Mailing List, linux-acpi, Hugh Dickins, Adrian Bunk,
Martin Lorenz
Linus Torvalds wrote:
> I wonder if the order matters more, though. Andi? We _used_ to write the
> high word first, and I think the order matters. The low word contains the
> enable bit, for example, so when enabling an interrupt, you should write
> the low word last, when you disable it you should write the low word
> first.
>
Although you can argue that anyone coding here should be a guru, in
practice things this subtle really would be helped by a comment in the
initial code. I don't agree that "if it was hard to write it should be
hard to understand." Clearly several competent people missed this
dependency, or the patch would not have gone in.
--
Bill Davidsen <davidsen@tmr.com>
Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a
normal user and is setuid root, with the "vi" line edit mode selected,
and the character set is "big5," an off-by-one errors occurs during
wildcard (glob) expansion.
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled
2006-10-26 2:22 ` David Brownell
@ 2006-11-02 7:15 ` Greg KH
2006-11-02 20:29 ` David Brownell
0 siblings, 1 reply; 139+ messages in thread
From: Greg KH @ 2006-11-02 7:15 UTC (permalink / raw)
To: David Brownell
Cc: Randy Dunlap, toralf.foerster, netdev, linux-usb-devel, link,
akpm, zippel, torvalds, linux-kernel
On Wed, Oct 25, 2006 at 07:22:08PM -0700, David Brownell wrote:
> On Wednesday 25 October 2006 4:58 pm, Randy Dunlap wrote:
> > On Wed, 25 Oct 2006 15:27:09 -0700 David Brownell wrote:
> >
> > > Instead, "usbnet.c" should #ifdef the relevant ethtool hooks
> > > according to CONFIG_MII ... since it's completely legit to
> > > use usbnet with peripherals that don't need MII.
>
> I had in mind something simpler -- #ifdeffing the entire functions,
> as in this patch. It looks more complicated than it is, because
> "diff" gets confused by moving two functions earlier in the file.
>
> (Thanks for starting this, Randy ... these two patches should be merged
> before RC4 ships.)
Argh, there were just too many different versions of these patches
floating around. Can you resend the final versions please?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [linux-usb-devel] [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled
2006-11-01 1:23 ` Adrian Bunk
@ 2006-11-02 20:19 ` David Brownell
0 siblings, 0 replies; 139+ messages in thread
From: David Brownell @ 2006-11-02 20:19 UTC (permalink / raw)
To: Adrian Bunk
Cc: linux-usb-devel, Randy Dunlap, akpm, zippel, netdev, linux-kernel,
link, Christoph Hellwig, torvalds, greg, toralf.foerster
On Tuesday 31 October 2006 5:23 pm, Adrian Bunk wrote:
> select MII if USB_NET_AX8817X!=n || USB_NET_MCS7830!=n
Thing is, I'm seeing that get morphed inside Kconfig to "select MII" in
some cases ... the "if x != n" gets ignored, MII can't be deselected.
That looks to me like a Kconfig dependency engine bug, so I'm just
noting it here rather than fixing it. I guess it's not quite enough
of a Prolog engine ... ;)
- Dave
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled
2006-11-02 7:15 ` Greg KH
@ 2006-11-02 20:29 ` David Brownell
2006-11-03 2:27 ` Adrian Bunk
0 siblings, 1 reply; 139+ messages in thread
From: David Brownell @ 2006-11-02 20:29 UTC (permalink / raw)
To: Greg KH
Cc: Randy Dunlap, toralf.foerster, netdev, linux-usb-devel, link,
akpm, zippel, torvalds, linux-kernel
On Wednesday 01 November 2006 11:15 pm, Greg KH wrote:
> Argh, there were just too many different versions of these patches
> floating around. Can you resend the final versions please?
This should replace BOTH of Randy's patches. It addresses all the
issues I've heard raised, and resolves the regresssion introduced
when adding the mcs7830 minidriver.
- Dave
============ CUT HERE
Fix mcs7830 patch
The recent mcs7830 update to make the MII support sharable goofed various
pre-existing configurations in two ways:
- it made the usbnet infrastructure reference MII symbols even
when they're not needed in the kernel being built
- it didn't enable MII along with the mcs7830 minidriver
This patch fixes these two problems.
However, there does seem to be a Kconfig reverse dependency bug in that MII
gets wrongly enabled in some cases (like USBNET=y and USBNET_MII=n); I think
I've noticed that same problem in other situations too. So the result can
mean kernels being bloated by stuff that's needlessly enabled ... better
than wrongly being disabled, but contributing to bloat.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Index: at91/drivers/usb/net/Kconfig
===================================================================
--- at91.orig/drivers/usb/net/Kconfig 2006-11-02 10:58:49.000000000 -0800
+++ at91/drivers/usb/net/Kconfig 2006-11-02 12:10:13.000000000 -0800
@@ -92,8 +92,13 @@ config USB_RTL8150
To compile this driver as a module, choose M here: the
module will be called rtl8150.
+config USB_USBNET_MII
+ tristate
+ default n
+
config USB_USBNET
tristate "Multi-purpose USB Networking Framework"
+ select MII if USBNET_MII != n
---help---
This driver supports several kinds of network links over USB,
with "minidrivers" built around a common network driver core
@@ -129,7 +134,7 @@ config USB_NET_AX8817X
tristate "ASIX AX88xxx Based USB 2.0 Ethernet Adapters"
depends on USB_USBNET && NET_ETHERNET
select CRC32
- select MII
+ select USB_USBNET_MII
default y
help
This option adds support for ASIX AX88xxx based USB 2.0
@@ -210,6 +215,7 @@ config USB_NET_PLUSB
config USB_NET_MCS7830
tristate "MosChip MCS7830 based Ethernet adapters"
depends on USB_USBNET
+ select USB_USBNET_MII
help
Choose this option if you're using a 10/100 Ethernet USB2
adapter based on the MosChip 7830 controller. This includes
Index: at91/drivers/usb/net/usbnet.c
===================================================================
--- at91.orig/drivers/usb/net/usbnet.c 2006-11-02 10:58:49.000000000 -0800
+++ at91/drivers/usb/net/usbnet.c 2006-11-02 11:09:29.000000000 -0800
@@ -669,6 +669,9 @@ done:
* they'll probably want to use this base set.
*/
+#if defined(CONFIG_MII) || defined(CONFIG_MII_MODULE)
+#define HAVE_MII
+
int usbnet_get_settings (struct net_device *net, struct ethtool_cmd *cmd)
{
struct usbnet *dev = netdev_priv(net);
@@ -699,20 +702,6 @@ int usbnet_set_settings (struct net_devi
}
EXPORT_SYMBOL_GPL(usbnet_set_settings);
-
-void usbnet_get_drvinfo (struct net_device *net, struct ethtool_drvinfo *info)
-{
- struct usbnet *dev = netdev_priv(net);
-
- /* REVISIT don't always return "usbnet" */
- strncpy (info->driver, driver_name, sizeof info->driver);
- strncpy (info->version, DRIVER_VERSION, sizeof info->version);
- strncpy (info->fw_version, dev->driver_info->description,
- sizeof info->fw_version);
- usb_make_path (dev->udev, info->bus_info, sizeof info->bus_info);
-}
-EXPORT_SYMBOL_GPL(usbnet_get_drvinfo);
-
u32 usbnet_get_link (struct net_device *net)
{
struct usbnet *dev = netdev_priv(net);
@@ -730,40 +719,57 @@ u32 usbnet_get_link (struct net_device *
}
EXPORT_SYMBOL_GPL(usbnet_get_link);
-u32 usbnet_get_msglevel (struct net_device *net)
+int usbnet_nway_reset(struct net_device *net)
{
struct usbnet *dev = netdev_priv(net);
- return dev->msg_enable;
+ if (!dev->mii.mdio_write)
+ return -EOPNOTSUPP;
+
+ return mii_nway_restart(&dev->mii);
}
-EXPORT_SYMBOL_GPL(usbnet_get_msglevel);
+EXPORT_SYMBOL_GPL(usbnet_nway_reset);
-void usbnet_set_msglevel (struct net_device *net, u32 level)
+#endif /* HAVE_MII */
+
+void usbnet_get_drvinfo (struct net_device *net, struct ethtool_drvinfo *info)
{
struct usbnet *dev = netdev_priv(net);
- dev->msg_enable = level;
+ /* REVISIT don't always return "usbnet" */
+ strncpy (info->driver, driver_name, sizeof info->driver);
+ strncpy (info->version, DRIVER_VERSION, sizeof info->version);
+ strncpy (info->fw_version, dev->driver_info->description,
+ sizeof info->fw_version);
+ usb_make_path (dev->udev, info->bus_info, sizeof info->bus_info);
}
-EXPORT_SYMBOL_GPL(usbnet_set_msglevel);
+EXPORT_SYMBOL_GPL(usbnet_get_drvinfo);
-int usbnet_nway_reset(struct net_device *net)
+u32 usbnet_get_msglevel (struct net_device *net)
{
struct usbnet *dev = netdev_priv(net);
- if (!dev->mii.mdio_write)
- return -EOPNOTSUPP;
+ return dev->msg_enable;
+}
+EXPORT_SYMBOL_GPL(usbnet_get_msglevel);
- return mii_nway_restart(&dev->mii);
+void usbnet_set_msglevel (struct net_device *net, u32 level)
+{
+ struct usbnet *dev = netdev_priv(net);
+
+ dev->msg_enable = level;
}
-EXPORT_SYMBOL_GPL(usbnet_nway_reset);
+EXPORT_SYMBOL_GPL(usbnet_set_msglevel);
/* drivers may override default ethtool_ops in their bind() routine */
static struct ethtool_ops usbnet_ethtool_ops = {
+#ifdef HAVE_MII
.get_settings = usbnet_get_settings,
.set_settings = usbnet_set_settings,
- .get_drvinfo = usbnet_get_drvinfo,
.get_link = usbnet_get_link,
.nway_reset = usbnet_nway_reset,
+#endif
+ .get_drvinfo = usbnet_get_drvinfo,
.get_msglevel = usbnet_get_msglevel,
.set_msglevel = usbnet_set_msglevel,
};
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled
2006-11-02 20:29 ` David Brownell
@ 2006-11-03 2:27 ` Adrian Bunk
2006-11-03 2:47 ` David Brownell
0 siblings, 1 reply; 139+ messages in thread
From: Adrian Bunk @ 2006-11-03 2:27 UTC (permalink / raw)
To: David Brownell
Cc: Greg KH, Randy Dunlap, toralf.foerster, netdev, linux-usb-devel,
link, akpm, zippel, torvalds, linux-kernel
On Thu, Nov 02, 2006 at 12:29:12PM -0800, David Brownell wrote:
> On Wednesday 01 November 2006 11:15 pm, Greg KH wrote:
>
> > Argh, there were just too many different versions of these patches
> > floating around. Can you resend the final versions please?
>
> This should replace BOTH of Randy's patches. It addresses all the
> issues I've heard raised, and resolves the regresssion introduced
> when adding the mcs7830 minidriver.
It seems to lack the "select MII" at the USB_RTL8150 option that was in
Randy's first patch?
> - Dave
>...
> --- at91.orig/drivers/usb/net/Kconfig 2006-11-02 10:58:49.000000000 -0800
> +++ at91/drivers/usb/net/Kconfig 2006-11-02 12:10:13.000000000 -0800
> @@ -92,8 +92,13 @@ config USB_RTL8150
> To compile this driver as a module, choose M here: the
> module will be called rtl8150.
>
> +config USB_USBNET_MII
> + tristate
> + default n
> +
> config USB_USBNET
> tristate "Multi-purpose USB Networking Framework"
> + select MII if USBNET_MII != n
> ---help---
> This driver supports several kinds of network links over USB,
> with "minidrivers" built around a common network driver core
> @@ -129,7 +134,7 @@ config USB_NET_AX8817X
> tristate "ASIX AX88xxx Based USB 2.0 Ethernet Adapters"
> depends on USB_USBNET && NET_ETHERNET
> select CRC32
> - select MII
> + select USB_USBNET_MII
> default y
> help
> This option adds support for ASIX AX88xxx based USB 2.0
> @@ -210,6 +215,7 @@ config USB_NET_PLUSB
> config USB_NET_MCS7830
> tristate "MosChip MCS7830 based Ethernet adapters"
> depends on USB_USBNET
> + select USB_USBNET_MII
> help
> Choose this option if you're using a 10/100 Ethernet USB2
> adapter based on the MosChip 7830 controller. This includes
> Index: at91/drivers/usb/net/usbnet.c
> ===================================================================
> --- at91.orig/drivers/usb/net/usbnet.c 2006-11-02 10:58:49.000000000 -0800
> +++ at91/drivers/usb/net/usbnet.c 2006-11-02 11:09:29.000000000 -0800
>...
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled
2006-11-03 2:27 ` Adrian Bunk
@ 2006-11-03 2:47 ` David Brownell
2006-11-03 2:58 ` Randy.Dunlap
2006-11-04 2:51 ` [2.6 patch] USB_RTL8150 must select MII Adrian Bunk
0 siblings, 2 replies; 139+ messages in thread
From: David Brownell @ 2006-11-03 2:47 UTC (permalink / raw)
To: Adrian Bunk
Cc: Greg KH, Randy Dunlap, toralf.foerster, netdev, linux-usb-devel,
link, akpm, zippel, torvalds, linux-kernel
On Thursday 02 November 2006 6:27 pm, Adrian Bunk wrote:
> It seems to lack the "select MII" at the USB_RTL8150 option that was in
> Randy's first patch?
I was just addressing the usbnet issues ... that driver doesn't
use the usbnet framework.
- Dave
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled
2006-11-03 2:47 ` David Brownell
@ 2006-11-03 2:58 ` Randy.Dunlap
2006-11-04 2:51 ` [2.6 patch] USB_RTL8150 must select MII Adrian Bunk
1 sibling, 0 replies; 139+ messages in thread
From: Randy.Dunlap @ 2006-11-03 2:58 UTC (permalink / raw)
To: David Brownell
Cc: Adrian Bunk, Greg KH, Randy Dunlap, toralf.foerster, netdev,
linux-usb-devel, link, akpm, zippel, torvalds, linux-kernel
On Thu, 2 Nov 2006, David Brownell wrote:
> On Thursday 02 November 2006 6:27 pm, Adrian Bunk wrote:
>
> > It seems to lack the "select MII" at the USB_RTL8150 option that was in
> > Randy's first patch?
>
> I was just addressing the usbnet issues ... that driver doesn't
> use the usbnet framework.
and Randy is away for a few days with very limited net access.
--
~Randy
^ permalink raw reply [flat|nested] 139+ messages in thread
* [2.6 patch] USB_RTL8150 must select MII
2006-11-03 2:47 ` David Brownell
2006-11-03 2:58 ` Randy.Dunlap
@ 2006-11-04 2:51 ` Adrian Bunk
1 sibling, 0 replies; 139+ messages in thread
From: Adrian Bunk @ 2006-11-04 2:51 UTC (permalink / raw)
To: David Brownell
Cc: Greg KH, Randy Dunlap, toralf.foerster, netdev, linux-usb-devel,
link, akpm, zippel, torvalds, linux-kernel
On Thu, Nov 02, 2006 at 06:47:15PM -0800, David Brownell wrote:
> On Thursday 02 November 2006 6:27 pm, Adrian Bunk wrote:
>
> > It seems to lack the "select MII" at the USB_RTL8150 option that was in
> > Randy's first patch?
>
> I was just addressing the usbnet issues ... that driver doesn't
> use the usbnet framework.
OK, the patch for this driver is below.
> - Dave
cu
Adrian
<-- snip -->
USB_RTL8150 must select MII to avoid link errors.
Stolen from a patch by Randy Dunlap.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2619-rc3-pv.orig/drivers/usb/net/Kconfig
+++ linux-2619-rc3-pv/drivers/usb/net/Kconfig
@@ -84,6 +84,7 @@ config USB_PEGASUS
config USB_RTL8150
tristate "USB RTL8150 based ethernet device support (EXPERIMENTAL)"
depends on EXPERIMENTAL
+ select MII
help
Say Y here if you have RTL8150 based usb-ethernet adapter.
Send me <petkan@users.sourceforge.net> any comments you may have.
^ permalink raw reply [flat|nested] 139+ messages in thread
* 2.6.19-rc <-> ThinkPads, summary
2006-11-01 3:01 ` 2.6.19-rc <-> ThinkPads Adrian Bunk
2006-11-01 3:15 ` Len Brown
2006-11-01 16:36 ` Hugh Dickins
@ 2006-11-04 3:49 ` Adrian Bunk
2006-11-04 13:51 ` Hugh Dickins
2006-11-04 14:04 ` Russell King
2 siblings, 2 replies; 139+ messages in thread
From: Adrian Bunk @ 2006-11-04 3:49 UTC (permalink / raw)
To: Hugh Dickins, Michael S. Tsirkin, Pavel Machek, Linus Torvalds,
Andrew Morton, Linux Kernel Mailing List, len.brown, linux-acpi,
linux-pm, Martin Lorenz, Andi Kleen, discuss, Russell King,
linux-serial, linux-thinkpad, Ernst Herzberg
As far as I can see, the 2.6.19-rc ThinkPad situation is still
confusing and we don't even know how many different bugs we are
chasing...
Below is all the information I have found, plus some questions for the
four people who reported problems that might hopefully bring us nearer
to solutions.
Michael S. Tsirkin:
- ThinkPad T60 not coming out of suspend to RAM
- broken by commit cf4c6a2f27f5db810b69dcb1da7f194489e8ff88
("i386: Factor out common io apic routing entry access")
- question: Did the post -rc4 arch/i386/kernel/io_apic.c changes fix it?
Ernst Herzberg:
- ThinkPad R50p: boot fail with (lapic && on_battery)
- kernel compiled without cardbus support works
- question: Does reverting the bisected
commit 1fbbac4bcb03033d325c71fc7273aa0b9c1d9a03
("serial_cs: convert multi-port table to quirk table")
fix the problem?
- question: Does reverting commit cf4c6a2f27f5db810b69dcb1da7f194489e8ff88
("i386: Factor out common io apic routing entry access") help?
- question: If yes, did the post -rc4 arch/i386/kernel/io_apic.c changes
fix it?
Hugh Dickins:
- ThinkPad T43p
- booting with "noapic nolapic" didn't make any difference
- reverting commit cf4c6a2f27f5db810b69dcb1da7f194489e8ff88
("i386: Factor out common io apic routing entry access") didn't help
- question: Was your bisecting successful?
Martin Lorenz:
- ThinkPad X60: lose ACPI events after suspend/resume
not every time, but roughly 3 out of 4 times
- question: Does reverting commit cf4c6a2f27f5db810b69dcb1da7f194489e8ff88
("i386: Factor out common io apic routing entry access")
in -rc4 help?
- question: If yes, did the post -rc4 arch/i386/kernel/io_apic.c changes
fix it?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads, summary
2006-11-04 3:49 ` 2.6.19-rc <-> ThinkPads, summary Adrian Bunk
@ 2006-11-04 13:51 ` Hugh Dickins
2006-11-04 14:04 ` Russell King
1 sibling, 0 replies; 139+ messages in thread
From: Hugh Dickins @ 2006-11-04 13:51 UTC (permalink / raw)
To: Adrian Bunk
Cc: Michael S. Tsirkin, Pavel Machek, Linus Torvalds, Andrew Morton,
Linux Kernel Mailing List, len.brown, linux-acpi, linux-pm,
Martin Lorenz, Andi Kleen, discuss, Russell King, linux-serial,
linux-thinkpad, Ernst Herzberg
On Sat, 4 Nov 2006, Adrian Bunk wrote:
>
> Hugh Dickins:
> - ThinkPad T43p
> - booting with "noapic nolapic" didn't make any difference
> - reverting commit cf4c6a2f27f5db810b69dcb1da7f194489e8ff88
> ("i386: Factor out common io apic routing entry access") didn't help
> - question: Was your bisecting successful?
Not quite what I'd call successful, but I think I've just about arrived
at some kind of conclusion.
Short summary: forget my complaint, assume it's fixed in current -git.
Boring version:
I think I have two slightly different, perhaps not unrelated, issues.
One manifested in habitual usage, to and from work, suspending for quiet
at home, etc, etc. As 2.6.19-rc progressed, I more and more often found
it impossible to re-suspend after the first time: suspend key ignored.
rc3 seemed worst, rc4 at first seemed okay, then not, perhaps because...
In order to bisect on this, I had to speed up the testing from a day
or two to a few minutes; and I'm now thinking that this may have
focussed on a different problem. After several reset bisections
converging on absurd patches (e.g. sparse annotations or unbuilt
sources), I grew even more suspicious of my "good" cases, and
yesterday found even 2.6.18 and 2.6.17 (didn't try earlier) behave
like this: occasionally the suspend key gets ignored for about one
minute (in the few cases I timed).
So whatever I was bisecting on, it's not a regression in 2.6.19.
It may be a software bug, it would be worth fixing if I can work
it out (though the pleasure of bisection was not having to think,
I've grown addicted); but it's not anything to hold up 2.6.19.
And as far as habitual usage goes, experience so far with -gits
post rc4 suggests that that problem has gone away: it's a little
too early to tell for sure, but I've not had to go back to using
2.6.18 to avoid it yet.
Hugh
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads, summary
2006-11-04 3:49 ` 2.6.19-rc <-> ThinkPads, summary Adrian Bunk
2006-11-04 13:51 ` Hugh Dickins
@ 2006-11-04 14:04 ` Russell King
2006-11-05 6:23 ` Adrian Bunk
1 sibling, 1 reply; 139+ messages in thread
From: Russell King @ 2006-11-04 14:04 UTC (permalink / raw)
To: Adrian Bunk
Cc: Hugh Dickins, Michael S. Tsirkin, Pavel Machek, Linus Torvalds,
Andrew Morton, Linux Kernel Mailing List, len.brown, linux-acpi,
linux-pm, Martin Lorenz, Andi Kleen, discuss, linux-serial,
linux-thinkpad, Ernst Herzberg
On Sat, Nov 04, 2006 at 04:49:07AM +0100, Adrian Bunk wrote:
> As far as I can see, the 2.6.19-rc ThinkPad situation is still
> confusing and we don't even know how many different bugs we are
> chasing...
Why am I copied on this? Nothing jumps out as being in any area of my
interest (which today is limited to ARM architecture only.)
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads, summary
2006-11-04 14:04 ` Russell King
@ 2006-11-05 6:23 ` Adrian Bunk
2006-11-07 20:06 ` Russell King
0 siblings, 1 reply; 139+ messages in thread
From: Adrian Bunk @ 2006-11-05 6:23 UTC (permalink / raw)
To: Hugh Dickins, Michael S. Tsirkin, Pavel Machek, Linus Torvalds,
Andrew Morton, Linux Kernel Mailing List, len.brown, linux-acpi,
linux-pm, Martin Lorenz, Andi Kleen, discuss, linux-serial,
linux-thinkpad, Ernst Herzberg
On Sat, Nov 04, 2006 at 02:04:40PM +0000, Russell King wrote:
> On Sat, Nov 04, 2006 at 04:49:07AM +0100, Adrian Bunk wrote:
> > As far as I can see, the 2.6.19-rc ThinkPad situation is still
> > confusing and we don't even know how many different bugs we are
> > chasing...
>
> Why am I copied on this? Nothing jumps out as being in any area of my
> interest (which today is limited to ARM architecture only.)
Ernst bisected his problem to your
commit 1fbbac4bcb03033d325c71fc7273aa0b9c1d9a03
("serial_cs: convert multi-port table to quirk table").
It might be a false positive of the bisecting, but if it turns out to
actually cause problems it was your commit.
> Russell King
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads, summary
2006-11-05 6:23 ` Adrian Bunk
@ 2006-11-07 20:06 ` Russell King
2006-11-07 20:19 ` Ernst Herzberg
0 siblings, 1 reply; 139+ messages in thread
From: Russell King @ 2006-11-07 20:06 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, Linux Kernel Mailing List, Ernst Herzberg
On Sun, Nov 05, 2006 at 07:23:30AM +0100, Adrian Bunk wrote:
> On Sat, Nov 04, 2006 at 02:04:40PM +0000, Russell King wrote:
> > On Sat, Nov 04, 2006 at 04:49:07AM +0100, Adrian Bunk wrote:
> > > As far as I can see, the 2.6.19-rc ThinkPad situation is still
> > > confusing and we don't even know how many different bugs we are
> > > chasing...
> >
> > Why am I copied on this? Nothing jumps out as being in any area of my
> > interest (which today is limited to ARM architecture only.)
>
> Ernst bisected his problem to your
> commit 1fbbac4bcb03033d325c71fc7273aa0b9c1d9a03
> ("serial_cs: convert multi-port table to quirk table").
>
> It might be a false positive of the bisecting, but if it turns out to
> actually cause problems it was your commit.
No idea, sorry.
No information if a serial card was in the PCMCIA slot. If there's
no _PCMCIA_ serial card inserted, the code in that patch will not be
run.
Also no indication if serial_cs was built into Earnst's kernel. If
it wasn't, this commit couldn't be the cause.
NeedMoreInformation.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads, summary
2006-11-07 20:06 ` Russell King
@ 2006-11-07 20:19 ` Ernst Herzberg
0 siblings, 0 replies; 139+ messages in thread
From: Ernst Herzberg @ 2006-11-07 20:19 UTC (permalink / raw)
To: Russell King; +Cc: Adrian Bunk, Andrew Morton, Linux Kernel Mailing List
On Tuesday 07 November 2006 21:06, Russell King wrote:
> On Sun, Nov 05, 2006 at 07:23:30AM +0100, Adrian Bunk wrote:
> > On Sat, Nov 04, 2006 at 02:04:40PM +0000, Russell King wrote:
> > > On Sat, Nov 04, 2006 at 04:49:07AM +0100, Adrian Bunk wrote:
> > > > As far as I can see, the 2.6.19-rc ThinkPad situation is still
> > > > confusing and we don't even know how many different bugs we are
> > > > chasing...
> > >
> > > Why am I copied on this? Nothing jumps out as being in any area of
> > > my interest (which today is limited to ARM architecture only.)
> >
> > Ernst bisected his problem to your
> > commit 1fbbac4bcb03033d325c71fc7273aa0b9c1d9a03
> > ("serial_cs: convert multi-port table to quirk table").
> >
> > It might be a false positive of the bisecting, but if it turns out to
> > actually cause problems it was your commit.
>
> No idea, sorry.
>
> No information if a serial card was in the PCMCIA slot. If there's
> no _PCMCIA_ serial card inserted, the code in that patch will not be
> run.
>
> Also no indication if serial_cs was built into Earnst's kernel. If
> it wasn't, this commit couldn't be the cause.
>
> NeedMoreInformation.
It was a false positive of the bisecting. Now i can reproduce the problem
without Cardbus/PCMCIA complied in.
So you are now allowed to remove yoursef from the distribution list ;-)
Sorry,
<earny>
^ permalink raw reply [flat|nested] 139+ messages in thread
end of thread, other threads:[~2006-11-07 20:19 UTC | newest]
Thread overview: 139+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-10-23 23:22 Linux 2.6.19-rc3 Linus Torvalds
2006-10-24 2:24 ` Gene Heskett
2006-10-24 7:46 ` Muli Ben-Yehuda
2006-10-24 18:07 ` Badari Pulavarty
2006-10-24 20:21 ` 2.6.19-rc3: known unfixed regressions Adrian Bunk
2006-10-24 21:44 ` 2.6.19-rc3: known unfixed regressions: confirmations teunis
2006-10-26 15:31 ` Adrian Bunk
2006-10-26 15:54 ` teunis
2006-10-25 1:51 ` 2.6.19-rc3: known regressions with patches Adrian Bunk
2006-10-25 11:25 ` Linux 2.6.19-rc3 Jean Delvare
2006-10-25 12:01 ` Damien Wyart
2006-10-25 16:25 ` Auke Kok
2006-10-26 7:20 ` Jean Delvare
2006-10-25 20:13 ` Linux 2.6.19-rc3: !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB Athanasius
2006-10-25 22:17 ` [PATCH] " Randy Dunlap
2006-10-25 22:27 ` David Brownell
2006-10-25 23:58 ` [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled Randy Dunlap
2006-10-26 2:22 ` David Brownell
2006-11-02 7:15 ` Greg KH
2006-11-02 20:29 ` David Brownell
2006-11-03 2:27 ` Adrian Bunk
2006-11-03 2:47 ` David Brownell
2006-11-03 2:58 ` Randy.Dunlap
2006-11-04 2:51 ` [2.6 patch] USB_RTL8150 must select MII Adrian Bunk
2006-10-26 15:46 ` [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled Adrian Bunk
2006-10-26 15:51 ` Randy.Dunlap
2006-10-28 11:21 ` Christoph Hellwig
2006-10-28 21:10 ` David Brownell
2006-10-28 21:13 ` Christoph Hellwig
2006-10-28 22:30 ` David Brownell
2006-10-28 21:39 ` Adrian Bunk
2006-10-31 17:40 ` [linux-usb-devel] " David Brownell
2006-10-31 18:07 ` Adrian Bunk
2006-10-31 19:36 ` David Brownell
2006-11-01 1:23 ` Adrian Bunk
2006-11-02 20:19 ` David Brownell
2006-10-25 23:59 ` [PATCH 1/2] !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB Randy Dunlap
2006-10-26 2:24 ` David Brownell
2006-10-26 5:05 ` Randy.Dunlap
2006-10-26 5:24 ` David Brownell
2006-10-26 22:45 ` 2.6.19-rc3: known unfixed regressions (v2) Adrian Bunk
2006-10-27 1:02 ` [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN Adrian Bunk
2006-10-27 1:20 ` Matthew Wilcox
2006-10-27 1:28 ` Andrew Morton
2006-10-27 2:11 ` Stephen Hemminger
2006-10-27 17:07 ` Greg KH
2006-10-27 17:22 ` Pavel Machek
2006-10-27 18:39 ` Andrew Morton
2006-10-27 18:41 ` vmlinux.lds: consolidate initcall sections Andrew Morton
2006-10-27 18:42 ` [patch] drivers: wait for threaded probes between initcall levels Andrew Morton
2006-10-27 18:47 ` Stephen Hemminger
2006-10-27 20:15 ` Andrew Morton
2006-10-27 20:42 ` Linus Torvalds
2006-10-27 20:48 ` Linus Torvalds
2006-10-28 1:11 ` Greg KH
2006-10-28 1:50 ` Linus Torvalds
2006-10-27 22:59 ` Alan Cox
2006-10-27 23:06 ` Andrew Morton
2006-10-28 5:09 ` Grant Grundler
2006-10-28 5:19 ` Andrew Morton
2006-10-28 5:32 ` Andrew Morton
2006-10-28 6:08 ` Grant Grundler
2006-10-28 20:48 ` Stefan Richter
2006-10-28 23:34 ` Alan Cox
2006-10-29 2:01 ` Randy Dunlap
2006-10-30 9:44 ` Cornelia Huck
2006-10-30 10:48 ` Alan Cox
2006-10-30 12:29 ` Matthew Wilcox
2006-10-27 23:12 ` Olaf Hering
2006-10-27 19:31 ` vmlinux.lds: consolidate initcall sections Haavard Skinnemoen
2006-10-29 10:21 ` Geert Uytterhoeven
2006-10-27 19:44 ` Matthew Wilcox
2006-10-27 20:17 ` Andrew Morton
2006-10-27 20:27 ` Matthew Wilcox
2006-10-27 22:23 ` [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN Adrian Bunk
2006-10-27 22:38 ` Andrew Morton
2006-10-28 1:08 ` Greg KH
2006-10-27 23:03 ` Alan Cox
2006-10-27 22:57 ` Alan Cox
2006-10-27 8:27 ` Pavel Machek
2006-10-29 23:13 ` 2.6.19-rc3: known unfixed regressions (v3) Adrian Bunk
2006-10-30 13:56 ` Michael S. Tsirkin
2006-10-30 16:17 ` Jun'ichi Nomura
2006-10-30 16:32 ` Michael S. Tsirkin
2006-10-30 17:20 ` Jun'ichi Nomura
2006-10-30 17:54 ` Michael S. Tsirkin
2006-10-30 16:44 ` Linus Torvalds
2006-10-30 17:34 ` Jun'ichi Nomura
2006-10-30 18:16 ` Linus Torvalds
2006-10-30 18:35 ` Adrian Bunk
2006-10-30 19:00 ` Michael S. Tsirkin
2006-10-30 19:06 ` Hugh Dickins
2006-10-31 12:47 ` Martin Lorenz
2006-10-30 18:58 ` Michael S. Tsirkin
2006-10-31 21:15 ` Michael S. Tsirkin
2006-11-01 3:01 ` 2.6.19-rc <-> ThinkPads Adrian Bunk
2006-11-01 3:15 ` Len Brown
2006-11-01 5:11 ` Ernst Herzberg
2006-11-01 5:26 ` Linus Torvalds
2006-11-01 5:54 ` Michael S. Tsirkin
2006-11-01 6:16 ` Linus Torvalds
2006-11-01 17:25 ` Andi Kleen
2006-11-01 18:12 ` Michael S. Tsirkin
2006-11-01 18:25 ` Linus Torvalds
2006-11-01 19:33 ` Michael S. Tsirkin
2006-11-01 19:44 ` Linus Torvalds
2006-11-01 19:34 ` Andi Kleen
2006-11-01 19:52 ` Linus Torvalds
2006-11-01 21:15 ` Andi Kleen
2006-11-01 22:35 ` Bill Davidsen
2006-11-01 6:18 ` Michael S. Tsirkin
2006-11-01 9:33 ` Pavel Machek
2006-11-01 12:02 ` Michael S. Tsirkin
2006-11-01 17:17 ` Andi Kleen
2006-11-01 13:50 ` Stefan Seyfried
2006-11-01 16:36 ` Hugh Dickins
2006-11-04 3:49 ` 2.6.19-rc <-> ThinkPads, summary Adrian Bunk
2006-11-04 13:51 ` Hugh Dickins
2006-11-04 14:04 ` Russell King
2006-11-05 6:23 ` Adrian Bunk
2006-11-07 20:06 ` Russell King
2006-11-07 20:19 ` Ernst Herzberg
-- strict thread matches above, loose matches on Subject: below --
2006-10-28 8:23 [patch] drivers: wait for threaded probes between initcall levels Adam J. Richter
2006-10-28 9:22 ` Russell King
2006-10-28 12:10 ` Russell King
2006-10-28 19:41 ` Linus Torvalds
2006-10-28 23:50 Adam J. Richter
2006-10-28 23:55 ` Linus Torvalds
2006-10-30 14:23 ` Kyle Moffett
2006-10-30 14:38 ` Arjan van de Ven
2006-10-30 15:00 ` Xavier Bestel
2006-10-30 15:05 ` Arjan van de Ven
2006-10-30 15:28 ` Xavier Bestel
2006-10-30 18:56 ` Kyle Moffett
2006-10-30 14:42 ` Matthew Wilcox
2006-10-30 18:47 ` Kyle Moffett
2006-10-30 19:13 ` Matthew Wilcox
2006-10-31 5:39 ` Grant Grundler
2006-10-29 20:38 Adam J. Richter
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox