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
[email protected] (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
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.
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
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
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 : [email protected]
[email protected]
Jiri Slaby <[email protected]>
Status : unknown
Subject : X60s: BUG()s, lose ACPI events after suspend/resume
References : http://lkml.org/lkml/2006/10/10/39
Submitter : Martin Lorenz <[email protected]>
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" <[email protected]>
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 <[email protected]>
Status : unknown
Subject : unable to rip cd
References : http://lkml.org/lkml/2006/10/13/100
Submitter : Alex Romosan <[email protected]>
Status : unknown
Subject : SMP kernel can not generate ISA irq properly
References : http://lkml.org/lkml/2006/10/22/15
Submitter : Komuro <[email protected]>
Handled-By : Thomas Gleixner <[email protected]>
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 <[email protected]>
Caused-By : Stefan Richter <[email protected]>
commit ea6104c22468239083857fa07425c312b1ecb424
Handled-By : Stefan Richter <[email protected]>
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 <[email protected]>
Handled-By : Mark Langsdorf <[email protected]>
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 <[email protected]>
Handled-By : Greg KH <[email protected]>
Status : Greg is working on a fix
-----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 : [email protected]
> [email protected]
> Jiri Slaby <[email protected]>
> 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-----
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 <[email protected]>
Gleb Natapov <[email protected]>
Caused-By : Yinghai Lu <[email protected]>
commit 45edfd1db02f818b3dc7e4743ee8585af6b78f78
Handled-By : Eric W. Biederman <[email protected]>
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 <[email protected]>
Handled-By : Patrick McHardy <[email protected]>
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 <[email protected]>
Caused-By : Heiko Carstens <[email protected]>
commit 8abfe01dae8c0ed7ca6bfb153a7fcab47df72a52
Handled-By : Paul Mundt <[email protected]>
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 <[email protected]>
Caused-By : Eiichiro Oiwa <[email protected]>
commit b5e4efe7e061ff52ac97b9fa45acca529d8daeea
Handled-By : Eiichiro Oiwa <[email protected]>
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 <[email protected]>
Caused-By : David Howells <[email protected]>
commit 7d12e780e003f93433d49ce78cfedf4b4c52adc5
Handled-By : Andrey Panin <[email protected]>
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 <[email protected]>
Caused-By : "Andrew de Quincey" <[email protected]>
commit 176ac9da4f09820a43fd48f0e74b1486fc3603ba
Handled-By : Trent Piepho <[email protected]>
Patch : http://lkml.org/lkml/2006/10/14/157
Status : patch available
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
> > Auke Kok (1):
> > e100: fix reboot -f with netconsole enabled
* Jean Delvare <[email protected]> [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
Damien Wyart wrote:
>>> Auke Kok (1):
>>> e100: fix reboot -f with netconsole enabled
>
> * Jean Delvare <[email protected]> [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);
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
From: Randy Dunlap <[email protected]>
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 <[email protected]>
---
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 <[email protected]> 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
---
> @@ -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.
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 <[email protected]>
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 <[email protected]>
---
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);
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 <[email protected]>
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 <[email protected]>
---
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 <[email protected]> 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
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 <[email protected]>
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,
};
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
>
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
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
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 <[email protected]> [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
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 : [email protected]
> > [email protected]
> > Jiri Slaby <[email protected]>
> > 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
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
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
-----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 : [email protected]
>>> [email protected]
>>> Jiri Slaby <[email protected]>
>>> 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: [email protected]; 23/10/06 10:34 AM
From: Jeff Dike <[email protected]>
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 <[email protected]>
Cc: Cedric Le Goater <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
- ---
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-----
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 <[email protected]>
Status : unknown
Subject : MSI errors during boot (CONFIG_PCI_MULTITHREAD_PROBE)
References : http://lkml.org/lkml/2006/10/16/291
Submitter : Stephen Hemminger <[email protected]>
Handled-By : Greg KH <[email protected]>
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 <[email protected]>
Status : unknown
Subject : X60s: BUG()s, lose ACPI events after suspend/resume
References : http://lkml.org/lkml/2006/10/10/39
Submitter : Martin Lorenz <[email protected]>
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" <[email protected]>
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 <[email protected]>
Status : unknown
Subject : unable to rip cd
References : http://lkml.org/lkml/2006/10/13/100
Submitter : Alex Romosan <[email protected]>
Status : unknown
Subject : SMP kernel can not generate ISA irq properly
References : http://lkml.org/lkml/2006/10/22/15
Submitter : Komuro <[email protected]>
Handled-By : Thomas Gleixner <[email protected]>
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 <[email protected]>
Caused-By : Stefan Richter <[email protected]>
commit ea6104c22468239083857fa07425c312b1ecb424
Handled-By : Stefan Richter <[email protected]>
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 <[email protected]>
Handled-By : Mark Langsdorf <[email protected]>
Status : Mark is investigating
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 <[email protected]>
> Status : unknown
>
>
> Subject : MSI errors during boot (CONFIG_PCI_MULTITHREAD_PROBE)
> References : http://lkml.org/lkml/2006/10/16/291
> Submitter : Stephen Hemminger <[email protected]>
> Handled-By : Greg KH <[email protected]>
> 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 <[email protected]>
--- 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
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.
On Thu, 26 Oct 2006 19:20:58 -0600
Matthew Wilcox <[email protected]> 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 :(
On Thu, 26 Oct 2006 18:28:38 -0700
Andrew Morton <[email protected]> wrote:
> On Thu, 26 Oct 2006 19:20:58 -0600
> Matthew Wilcox <[email protected]> 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.
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
On Thu, Oct 26, 2006 at 07:11:31PM -0700, Stephen Hemminger wrote:
> On Thu, 26 Oct 2006 18:28:38 -0700
> Andrew Morton <[email protected]> wrote:
>
> > On Thu, 26 Oct 2006 19:20:58 -0600
> > Matthew Wilcox <[email protected]> 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
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
On Fri, 27 Oct 2006 19:22:19 +0200
Pavel Machek <[email protected]> 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 ;)
From: Andrew Morton <[email protected]>
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 <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---
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)
+
_
From: Andrew Morton <[email protected]>
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 <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---
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)
_
On Fri, 27 Oct 2006 11:42:37 -0700
Andrew Morton <[email protected]> wrote:
> From: Andrew Morton <[email protected]>
>
> 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 <[email protected]>
> Signed-off-by: Andrew Morton <[email protected]>
> ---
>
This looks like a good place to use a counting semaphore.
--
Stephen Hemminger <[email protected]>
On 10/27/06, Andrew Morton <[email protected]> wrote:
> From: Andrew Morton <[email protected]>
>
> 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 <[email protected]>
---
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
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.
On Fri, 27 Oct 2006 11:47:29 -0700
Stephen Hemminger <[email protected]> wrote:
> On Fri, 27 Oct 2006 11:42:37 -0700
> Andrew Morton <[email protected]> wrote:
>
> > From: Andrew Morton <[email protected]>
> >
> > 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 <[email protected]>
> > Signed-off-by: Andrew Morton <[email protected]>
> > ---
> >
>
> 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.
On Fri, 27 Oct 2006 13:44:13 -0600
Matthew Wilcox <[email protected]> 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.
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 ...
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
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
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 <[email protected]> wrote:
> >
> > > On Thu, 26 Oct 2006 19:20:58 -0600
> > > Matthew Wilcox <[email protected]> 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
On Sat, 28 Oct 2006 00:23:26 +0200
Adrian Bunk <[email protected]> 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?
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.
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
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
On Fri, 27 Oct 2006 23:59:30 +0100
Alan Cox <[email protected]> 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 ;)
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.
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
On Fri, Oct 27, 2006 at 03:38:54PM -0700, Andrew Morton wrote:
> On Sat, 28 Oct 2006 00:23:26 +0200
> Adrian Bunk <[email protected]> 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
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
On Fri, Oct 27, 2006 at 04:06:26PM -0700, Andrew Morton wrote:
> On Fri, 27 Oct 2006 23:59:30 +0100
> Alan Cox <[email protected]> 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
On Fri, 27 Oct 2006 23:09:05 -0600
Grant Grundler <[email protected]> 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 <[email protected]> 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.
On Fri, 27 Oct 2006 22:19:25 -0700
Andrew Morton <[email protected]> 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.
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
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);
}
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
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 <[email protected]>
>
> 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 <[email protected]>
> ---
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
---end quoted text---
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:
[email protected]
SMTP error from remote mail server after MAIL FROM:<[email protected]> SIZE=3022:
host yggdrasil.com [61.49.148.168]: 553 5.1.8 <[email protected]>... Domain of sender address [email protected] 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
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
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/
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 <[email protected]>
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,
};
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.
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
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
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
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
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
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
On Fri, 27 Oct 2006, Haavard Skinnemoen wrote:
> On 10/27/06, Andrew Morton <[email protected]> wrote:
> > From: Andrew Morton <[email protected]>
> >
> > 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 <[email protected]>
--- 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 -- [email protected]
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
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
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 <[email protected]>
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 <[email protected]>
Status : unknown
Subject : X60s: BUG()s, lose ACPI events after suspend/resume
References : http://lkml.org/lkml/2006/10/10/39
Submitter : Martin Lorenz <[email protected]>
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" <[email protected]>
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 <[email protected]>
Status : unknown
Subject : unable to rip cd
References : http://lkml.org/lkml/2006/10/13/100
Submitter : Alex Romosan <[email protected]>
Status : unknown
Subject : SMP kernel can not generate ISA irq properly
References : http://lkml.org/lkml/2006/10/22/15
Submitter : Komuro <[email protected]>
Handled-By : Thomas Gleixner <[email protected]>
Status : Thomas will investigate
Subject : cpufreq not working on AMD K8
References : http://lkml.org/lkml/2006/10/10/114
Submitter : Christian <[email protected]>
Handled-By : Mark Langsdorf <[email protected]>
Status : Mark is investigating
On Fri, 27 Oct 2006 16:06:26 -0700,
Andrew Morton <[email protected]> wrote:
> On Fri, 27 Oct 2006 23:59:30 +0100
> Alan Cox <[email protected]> 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: [email protected]
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.
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.
Quoting r. Adrian Bunk <[email protected]>:
> 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" <[email protected]>
> 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 <[email protected]>
[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 <[email protected]>
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
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
> 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 :)
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.
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
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
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
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 <[email protected]>:
>> 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" <[email protected]>
>> 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 <[email protected]>
> [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 <[email protected]>
> 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
Quoting r. Jun'ichi Nomura <[email protected]>:
> 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
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
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
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
Quoting r. Jun'ichi Nomura <[email protected]>:
> 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
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
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
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
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
Quoting r. Linus Torvalds <[email protected]>:
> 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
Quoting r. Adrian Bunk <[email protected]>:
> 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
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
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.
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
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
http://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
> > +#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.
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
> > ...
> > 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.
Quoting r. Linus Torvalds <[email protected]>:
> 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
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 <[email protected]>
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
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
FYI:
Subject : Thinkpad R50p: boot fail with (lapic && on_battery)
References : http://lkml.org/lkml/2006/10/31/333
Submitter : Ernst Herzberg <[email protected]>
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
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
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>
Quoting r. Linus Torvalds <[email protected]>:
> 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
Quoting r. Michael S. Tsirkin <[email protected]>:
> 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
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
On Wed 2006-11-01 08:18:57, Michael S. Tsirkin wrote:
> Quoting r. Michael S. Tsirkin <[email protected]>:
> > 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
Quoting Pavel Machek <[email protected]>:
> > > 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
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."
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 <[email protected]>
> 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
On Wednesday 01 November 2006 07:18, Michael S. Tsirkin wrote:
> Quoting r. Michael S. Tsirkin <[email protected]>:
> > 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
> 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
Quoting r. Andi Kleen <[email protected]>:
> 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
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 <[email protected]>
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 <[email protected]>
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)
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 <[email protected]>
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);
}
}
Quoting r. Linus Torvalds <[email protected]>:
> 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
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
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
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
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 <[email protected]>
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.
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
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 <[email protected]>
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,
};
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
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
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
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
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 <[email protected]>
--- 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 <[email protected]> any comments you may have.
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
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
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
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
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
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>