* Linux 2.6.19-rc3
@ 2006-10-23 23:22 Linus Torvalds
2006-10-24 2:24 ` Gene Heskett
` (7 more replies)
0 siblings, 8 replies; 152+ messages in thread
From: Linus Torvalds @ 2006-10-23 23:22 UTC (permalink / raw)
To: Linux Kernel Mailing List
[-- Attachment #1: Type: TEXT/PLAIN, Size: 36476 bytes --]
Ok,
a few days late, because I'm a retard and didn't think of doing a release
when I should have.
I'm also a bit grumpy, because I think people are sending me more stuff
than they should at this stage in the game. We've been pretty good about
keeping the later -rc releases quiet, please keep it that way.
That said, it's mostly harmless cleanups and some architecture updates.
And some of the added warnings about unused return values have caused a
number of people to add error handling. And on the driver front, there's
mainly new driver ID's, and a couple of new drivers.
Shortlog appended,
Linus
----
Adrian Bunk (12):
RDMA/amso1100: Fix a NULL dereference in error path
drivers/char/specialix.c: fix the baud conversion
USB: ftdi-elan.c: remove dead code
USB: mos7840.c: fix a check-after-dereference
[GFS2] fs/gfs2/dir.c:gfs2_dir_write_data(): remove dead code
[GFS2] fs/gfs2/ops_fstype.c:gfs2_get_sb_meta(): remove unused variable
[GFS2] fs/gfs2/dir.c:gfs2_dir_write_data(): don't use an uninitialized variable
[GFS2] fs/gfs2/ops_fstype.c:fill_super_meta(): fix NULL dereference
[GFS2] gfs2_dir_read_data(): fix uninitialized variable usage
one more ARM IRQ fix
ATA must depend on BLOCK
drivers/ide/pci/generic.c: re-add the __setup("all-generic-ide",...)
Akinobu Mita (8):
[CRYPTO] api: fix crypto_alloc_base() return value
md: fix /proc/mdstat refcounting
rd: memory leak on rd_init() failure
epca: prevent panic on tty_register_driver() failure
usb devio: handle class_device_create() error
cpcihp_generic: prevent loading without "bridge" parameter
driver core: kmalloc() failure check in driver_probe_device
ocfs2: delete redundant memcmp()
Al Viro (31):
gfp_t in netlabel
new cifs endianness bugs
hp drivers/input stuff: C99 initializers, NULL noise removal, __user annotations
sun3_ioremap() prototype
serial167 __user annotations, NULL noise removal
[GFS2] gfs2 endianness bug: be16 assigned to be32 field
bug: nfsd/nfs4xdr.c misuse of ERR_PTR()
fix svc_procfunc declaration
lockd endianness annotations
xdr annotations: NFSv2
xdr annotations: NFSv3
xdr annotations: NFSv4
xdr annotations: NFS readdir entries
fs/nfs/callback* passes error values big-endian
xdr annotations: fs/nfs/callback*
nfs: verifier is network-endian
xdr annotations: mount_clnt
nfs_common endianness annotations
nfsd: nfserrno() endianness annotations
nfsfh simple endianness annotations
xdr annotations: nfsd_dispatch()
xdr annotations: NFSv2 server
xdr annotations: NFSv3 server
xdr annotations: NFSv4 server
nfsd: vfs.c endianness annotations
nfsd: nfs4 code returns error values in net-endian
nfsd: NFSv{2,3} trivial endianness annotations for error values
nfsd: NFSv4 errno endianness annotations
xdr annotations: nfsd callback*
nfsd: misc endianness annotations
nfsd: nfs_replay_me
Alan Cox (10):
rio: fix array checking
ide: add sanity checking to ide taskfile ioctl
[ARM] switch to new pci_get_bus_and_slot API
pci: Stamp out pci_find_* usage in fakephp
PCI: quirks: switch quirks code offender to use pci_get API
pci: Additional search functions
irq updates: make eata_pio compile
ahci: readability tweak
libata-sff: Allow for wacky systems
[ATM] nicstar: Fix a bogus casting warning
Alan Stern (6):
USB: unusual_devs entry for Nokia 6131
UHCI: workaround for Asus motherboard
usbcore: fix refcount bug in endpoint removal
usbcore: fix endpoint device creation
USB: unusual_devs entry for Nokia 6234
Driver core: Don't ignore error returns from probing
Alexey Dobriyan (6):
ACPI: asus_acpi: don't printk on writing garbage to proc files
sx: fix user-visible typo (devic)
USB: drivers/usb/net/*: use BUILD_BUG_ON
OOM killer meets userspace headers
kernel/nsproxy.c: use kmemdup()
i2o/exec-osm.c: use "unsigned long flags;"
Alexey Y. Starikovskiy (2):
ACPI: Remove deferred execution from global lock acquire wakeup path
ACPI: created a dedicated workqueue for notify() execution
Allan Stephens (12):
[TIPC]: Add missing unlock in port timeout code.
[TIPC]: Debug print buffer enhancements and fixes
[TIPC]: Stream socket can now send > 66000 bytes at a time
[TIPC]: Added duplicate node address detection capability
[TIPC]: Optimize wakeup logic when socket has no waiting processes
[TIPC]: Remove code bloat introduced by print buffer rework
[TIPC]: Add support for Ethernet VLANs
[TIPC]: Name publication events now delivered in chronological order
[TIPC]: Fixed slow link reactivation when link tolerance is large
[TIPC]: Can now list multicast link on an isolated network node
[TIPC]: Unrecognized configuration command now returns error message
[TIPC]: Updated TIPC version number to 1.6.2
Amit Choudhary (5):
V4L/DVB (4738): Bt8xx/dvb-bt8xx.c: check kmalloc() return value.
[ALSA] sound/isa/gus/interwave.c: check kmalloc() return value
[ALSA] sound/isa/cmi8330.c: check kmalloc() return value
[ALSA] sound/isa/ad1816a/ad1816a.c: check kmalloc() return value
[ALSA] sound/isa/opti9xx/opti92x-ad1848.c: check kmalloc() return value
Amol Lad (5):
[WATCHDOG] ioremap balanced with iounmap for drivers/char/watchdog/s3c2410_wdt.c
drivers/isdn/hysdn: save_flags()/cli(), restore_flags() replaced appropriately
drivers/isdn/isdnloop: save_flags()/cli(), restore_flags() replaced appropriately
PCI hotplug: ioremap balanced with iounmap
drivers/isdn: ioremap balanced with iounmap
Andi Kleen (8):
x86-64: Update defconfig
i386: Update defconfig
x86: Use -maccumulate-outgoing-args
x86-64: Revert interrupt backlink changes
i386: Disable nmi watchdog on all ThinkPads
x86: Revert new unwind kernel stack termination
x86-64: Revert timer routing behaviour back to 2.6.16 state
x86-64: Fix C3 timer test
Andrew Morton (14):
r8169: PCI ID for Corega Gigabit network card
Lockdep: fix compile error in drivers/input/serio/serio.c
invalidate: remove_mapping() fix
PROC_NUMBUF is wrong
remove carta_random32
vmalloc(): don't pass __GFP_ZERO to slab
acpi_processor_latency_notifier(): UP warning fix
swsusp: fix memory leaks
USB: fix usbatm tiny race
PCI: pcie-check-and-return-bus_register-errors fix
separate bdi congestion functions from queue congestion functions
highest_possible_node_id() linkage fix
i386: fix .cfi_signal_frame copy-n-paste error
pci: declare pci_get_device_reverse()
Andrew Victor (1):
[WATCHDOG] Atmel AT91RM9200 rename.
Andrey Mirkin (1):
scsi: megaraid_{mm,mbox}: 64-bit DMA capability fix
Andy Whitcroft (1):
Reintroduce NODES_SPAN_OTHER_NODES for powerpc
Aneesh Kumar K.V (1):
Add entry.S labels to tag file
Anton Blanchard (4):
[POWERPC] Never panic when taking altivec exceptions from userspace
[POWERPC] POWER6 has 6 PMCs
[POWERPC] Better check in show_instructions
[POWERPC] Check for offline nodes in pci NUMA code
Arnaud Patard (1):
r8169: fix infinite loop during hotplug
Arnaud Patard (Rtp) (1):
[WATCHDOG] add ich8 support to iTCO_wdt.c
Arnd Bergmann (3):
USB: driver for mcs7830 (aka DeLOCK) USB ethernet adapter
usbnet: improve generic ethtool support
usbnet: add a mutex around phy register access
Aron Griffis (1):
[IA64] move ioremap/ioremap_nocache under __KERNEL__
Arthur Kepner (1):
IB/mthca: Use mmiowb after doorbell ring
Atsushi Nemoto (1):
[MIPS] save_context_stack fix
Auke Kok (1):
e100: fix reboot -f with netconsole enabled
Ben Collins (13):
[SPARC]: Fix some section mismatch warnings in sparc drivers.
[alim7101] Add pci dev table for auto module loading.
[mv643xx] Add pci device table for auto module loading.
[BusLogic] Add pci dev table for auto module loading.
[fdomain] Add pci dev table for module auto loading.
[initio] Add pci dev table for module auto loading.
[ixj] Add pci dev table for module auto loading.
[hid-core] TurboX Keyboard needs NOGET quirk.
[controlfb] Ifdef for when CONFIG_NVRAM isn't enabled.
[igafb] Add pci dev table for module auto loading.
[platinumfb] Ifdef for when CONFIG_NVRAM isn't enabled.
[valkyriefb] Ifdef for when CONFIG_NVRAM isn't enabled.
[pci_ids] Add Quicknet XJ vendor/device ID's.
Benjamin Herrenschmidt (1):
[POWERPC] Don't crash on cell with 2 BEs when !CONFIG_NUMA
bibo,mao (1):
x86-64: x86_64 add NX mask for PTE entry
Bjorn Helgaas (3):
[IA64] remove unused PAL_CALL_IC_OFF
[IA64] reformat pal.S to fit in 80 columns, fix typos
[IA64] remove unused acpi_kbd_controller_present, acpi_legacy_devices
Björn Steinbrink (1):
[NETFILTER]: Missing check for CAP_NET_ADMIN in iptables compat layer
Borislav Petkov (1):
readjust comments of task_timeslice for kernel doc
Brent Casavant (2):
ioc4: Remove SN2 feature and config dependencies
ioc4: Enable build on non-SN2
Brice Goglin (2):
PCI: Improve pci_msi_supported() comments
PCI: Update MSI-HOWTO.txt according to pci_msi_supported()
Cedric Le Goater (1):
[S390] fix vmlinux link when CONFIG_SYSIPC=n
Chandra Seetharaman (1):
configfs: handle kzalloc() failure in check_perm()
Chris Malley (1):
USB: Support for BT On-Air USB modem in cdc-acm.c
Christoph Lameter (1):
Slab: Do not fallback to nodes that have not been bootstrapped yet
Chuck Lever (5):
NFS: fix minor bug in new NFS symlink code
NFS: __nfs_revalidate_inode() can use "inode" before checking it is non-NULL
NFS: remove unused check in nfs4_open_revalidate
SUNRPC: fix race in in-kernel RPC portmapper client
SUNRPC: fix a typo
Corey Minyard (1):
x86-64: Fix for arch/x86_64/pci/Makefile CFLAGS
Cornelia Huck (8):
[S390] cio: sch_no -> schid.sch_no conversion.
[S390] cio: update documentation.
driver core fixes: sysfs_create_link() retval check in class.c
driver core fixes: bus_add_attrs() retval check
driver core fixes: bus_add_device() cleanup on error
driver core fixes: device_add() cleanup on error
driver core fixes: device_create_file() retval check in dmapool.c
driver core fixes: sysfs_create_group() retval in topology.c
Craig Shelley (1):
USB-SERIAL:cp2101 Add new device ID
Daniel Drake (1):
PCI: VIA IRQ quirk behaviour change
Daniel Ritz (2):
usbtouchscreen: fix data reading for ITM touchscreens
PCI: add ICH7/8 ACPI/GPIO io resource quirks
Daniel Walker (1):
clocksource: acpi_pm: add another greylist chipset
Darren Jenkins (1):
ACPI: asus_acpi: fix proc files parsing
Darrick J. Wong (1):
fix "ACPI: Processor native C-states using MWAIT"
Dave Jones (2):
ipmi: fix return codes in failure case
Remove useless comment from sb1250
Dave Kleikamp (3):
JFS: pageno needs to be long
airo: check if need to freeze
null dereference in fs/jbd2/journal.c
David Brownell (2):
USB: ohci-pnx4008 build fixes
USB: ftdi_sio whitespace fixes
David Gibson (2):
ibmveth: Fix index increment calculation
ibmveth: Fix index increment calculation
David Howells (2):
FRV: Use the correct preemption primitives in kmap_atomic() and co
autofs3: Make sure all dentries refs are released before calling kill_anon_super()
David M. Grimes (1):
knfsd: add nfs-export support to tmpfs
David S. Miller (12):
[XFRM]: Fix xfrm_state_num going negative.
[SPARC]: Kill BOOTME_SINGLE.
[SPARC64]: Fix PCI memory space root resource on Hummingbird.
[SPARC] {bbc_,}envctrl: Use call_usermodehelper().
[SPARC64]: Update defconfig.
[TG3]: Bump driver version and release date.
[IPV6]: Fix route.c warnings when multiple tables are disabled.
[SPARC64]: Compute dma_end argument to sabre_pbm_init() correctly.
[SPARC64]: Fix of_ioremap().
[DCCP] ipv6: Fix opt_skb leak.
[PKT_SCHED] netem: Orphan SKB when adding to queue.
[SPARC64]: 8-byte align return value from compat_alloc_user_space()
David Woodhouse (2):
fix `make headers_install'
[SPARC]: Clean up asm-sparc/elf.h pollution in userspace.
Deepak Saxena (1):
Update smc91x driver with ARM Versatile board info
Denis M. Sadykov (5):
ACPI: EC: Remove unnecessary delay added by previous transation patch.
ACPI: EC: Remove unused variables and duplicated code
ACPI: EC: Unify poll and interrupt mode transaction functions
ACPI: EC: Unify poll and interrupt gpe handlers
ACPI: EC: Simplify acpi_hw_low_level*() with inb()/outb().
Diego Calleja (1):
HOWTO: bug report addition
Dmitriy Monakhov (1):
mm: D-cache aliasing issue in cow_user_page
Dmitry Torokhov (6):
Input: add missing exports to fix modular build
Input: i8042 - supress ACK/NAKs when blinking during panic
Input: atkbd - supress "too many keys" error message
Input: serio core - handle errors returned by device_bind_driver()
Input: gameport core - handle errors returned by device_bind_driver()
ACPI: fix potential OOPS in power driver with CONFIG_ACPI_DEBUG
Dominic Cerquetti (1):
USB: xpad: dance pad support
Dominik Brodowski (1):
Documentation: feature-removal-schedule typo
Doug Warzecha (1):
firmware/dcdbas: add size check in smi_data_write
Duncan Sands (4):
usbatm: fix tiny race
speedtch: "extended reach"
cxacru: add the ZTE ZXDSL 852
Driver core: plug device probe memory leak
Ed L Cashin (14):
aoe: eliminate isbusy message
aoe: update copyright date
aoe: remove unused NARGS enum
aoe: zero copy write 1 of 2
aoe: jumbo frame support 1 of 2
aoe: clean up printks via macros
aoe: jumbo frame support 2 of 2
aoe: improve retransmission heuristics
aoe: zero copy write 2 of 2
aoe: module parameter for device timeout
aoe: use bio->bi_idx
aoe: remove sysfs comment
aoe: update driver version
aoe: revert printk macros
Eiichiro Oiwa (1):
ACPICA: Fix incorrect handling of PCI Express Root Bridge _HID
eiichiro.oiwa.nm@hitachi.com (1):
PCI: Turn pci_fixup_video into generic for embedded VGA
Enrico Scholz (1):
V4L/DVB (4740): Fixed an if-block to avoid floating with debug-messages
Eric Dumazet (6):
[NET]: reduce sizeof(struct inet_peer), cleanup, change in peer_check_expire()
[NET]: reduce per cpu ram used for loopback stats
[TCP]: One NET_INC_STATS() could be NET_INC_STATS_BH in tcp_v4_err()
[IPV4] inet_peer: Group together avl_left, avl_right, v4daddr to speedup lookups on some CPUS
[NET]: Can use __get_cpu_var() instead of per_cpu() in loopback driver.
[NET]: Reduce sizeof(struct flowi) by 20 bytes.
Eric Sesterhenn (7):
[POWERPC] Off-by-one in /arch/ppc/platforms/mpc8*
zd1201: Possible NULL dereference
USB: BUG_ON conversion for wacom.c
USB: fix use after free in wacom_sys.c
USB: fix dereference in drivers/usb/misc/adutux.c
USB: Memory leak in drivers/usb/serial/airprime.c
pciehp: Remove unnecessary check in pciehp_ctrl.c
Eric W. Biederman (2):
x86-64: Use irq_domain in ioapic_retrigger_irq
x86-64: Put more than one cpu in TARGET_CPUS
Evgeniy Polyakov (1):
w1 kconfig fix
Felix Kuehling (1):
[ALSA] hda_intel: add ATI RS690 HDMI audio support
Florin Malita (1):
airo.c: check returned values
Francisco Larramendi (1):
rtc-max6902: month conversion fix
Franck Bui-Huu (1):
[MIPS] Use kallsyms_lookup_size_offset() instead of kallsyms_lookup()
Geert Uytterhoeven (1):
CONFIG_TELCLOCK depends on X86
Gerrit Renker (1):
[DCCP]: Fix Oops in DCCPv6
Grant Coady (1):
adm9240: Update Grant Coady's email address
Grant Grundler (1):
USB: input: extract() and implement() are bit field manipulation routines
Greg Banks (1):
kbuild: allow multi-word $M in Makefile.modpost
Greg Kroah-Hartman (7):
USB: revert EHCI VIA workaround patch
USB: ftdi-elan: fix sparse warnings
USB: move trancevibrator.c to the proper usb directory
USB: add USB serial mos7720 driver
USB: cleanup sierra wireless driver a bit
PCI Hotplug: move pci_hotplug.h to include/linux/
aoe: fix sysfs_create_file warnings
Hans Verkuil (3):
V4L/DVB (4729): Fix VIDIOC_G_FMT for NTSC in cx25840.
V4L/DVB (4744): The Samsung TCPN2121P30A does not have a tda9887
V4L/DVB (4746): HM12 is YUV 4:2:0, not YUV 4:1:1
Hartmut Hackmann (1):
V4L/DVB (4727): Support status readout for saa713x based FM radio
Heiko Carstens (1):
[S390] Wire up epoll_pwait syscall.
Henrik Kretzschmar (1):
RDMA/amso1100: pci_module_init() conversion
Herbert Xu (1):
[CRYPTO] api: Select cryptomgr where needed
Hidetoshi Seto (2):
sysfs: remove duplicated dput in sysfs_update_file
sysfs: update obsolete comment in sysfs_update_file
Ingo Molnar (3):
lockdep: increase max allowed recursion depth
genirq: clean up irq-flow-type naming
genirq: clean up irq-flow-type naming, fix
J. Bruce Fields (4):
knfsd: nfsd4: fix owner-override on open
knfsd: nfsd4: fix open permission checking
knfsd: nfsd4: Fix error handling in nfsd's callback client
nfs4: initialize cl_ipaddr
Jack Steiner (2):
[IA64] - Allow IPIs in timer loop
[IA64] Count resched interrupts
Jan Beulich (2):
x86-64: Speed up dwarf2 unwinder
x86-64: Fix ENOSYS in system call tracing
Jan Dittmer (1):
[IPV6] sit: Add missing MODULE_LICENSE
Jan Kara (1):
Fix IO error reporting on fsync()
Jan Luebbe (1):
USB: Add device id for Sierra Wireless MC8755
Jan Mate (1):
USB Storage: unusual_devs.h entry for Sony Ericsson P990i
Jarek Poplawski (1):
USB: fix cdc-acm problems with hard irq? (inconsistent lock state)
Jaroslav Kysela (1):
[ALSA] version 1.0.13
Jean Delvare (5):
[WATCHDOG] includes for sample watchdog program.
hwmon: Fix documentation typos
smsc47m1: List the SMSC LPC47M112 as supported
hwmon: Let w83781d and lm78 load again
hwmon: Fix debug messages in w83781d
Jean Tourrilhes (2):
orinoco: fix WE-21 buffer overflow
wireless: More WE-21 potential overflows...
Jeff Dike (1):
uml: MODE_TT is bust
Jeff Garzik (15):
[WATCHDOG] watchdog/iTCO_wdt: fix bug related to gcc uninit warning
Input: fm801-gp - handle errors from pci_enable_device()
V4L/DVB (4741): {ov511,stv680}: handle sysfs errors
V4L/DVB (4742): Drivers/media/video: handle sysfs errors
drivers/led: handle sysfs errors
I2O: handle a few sysfs errors
fs/partitions/check: add sysfs error handling
rtc: fix printk of 64-bit res on 32-bit platform
ISDN: fix drivers, by handling errors thrown by ->readstat()
ISDN: check for userspace copy faults
USB/gadget/net2280: handle sysfs errors
Driver core: bus: remove indentation level
WAN/pc300: handle, propagate minor errors
[ATM]: handle sysfs errors
[ATM] firestream: handle thrown error
Jeff Moyer (1):
direct-io: sync and invalidate file region when falling back to buffered write
Jens Axboe (2):
Add lockless helpers for remove_suid()
Remove SUID when splicing into an inode
Jeremy Fitzhardinge (1):
i386: Fix fake return address
Jes Sorensen (1):
[IA64] update sn2_defconfig
Jesper Juhl (1):
Driver core: Don't leak 'old_class_name' in drivers/base/core.c::device_rename()
Jim Cromie (1):
w83791d: Fix unchecked return status
Jiri Kosina (3):
Input: serio - add lockdep annotations
ACPI: acpi_pci_link_set() can allocate with either GFP_ATOMIC or GFP_KERNEL
ACPI: check battery status on resume for un/plug events during sleep
Jiri Slaby (1):
Char: correct pci_get_device changes
John Heffner (1):
[TCP]: Bound TSO defer time
john stultz (1):
i386 Time: Avoid PIT SMP lockups
John W. Linville (2):
zd1211rw: fix build-break caused by association race fix
wireless: WE-20 compatibility for ESSID and NICKN ioctls
Jonathan Corbet (1):
V4L/DVB (4743): Fix oops in VIDIOC_G_PARM
keith mannthey (1):
x86-64: x86_64 hot-add memory srat.c fix
Kenji Kaneshige (5):
shpchp: fix shpchp_wait_cmd in poll
pciehp: fix improper info messages
pciehp - add missing locking
shpchp: fix command completion check
shpchp: remove unnecessary cmd_busy member from struct controller
Kevin Lloyd (1):
USB: Sierra Wireless driver update
Kimball Murray (1):
ACPI: SCI interrupt source override
Kristen Carlson Accardi (2):
change pci hotplug subsystem maintainer to Kristen
libata: use correct map_db values for ICH8
Kristoffer Ericson (2):
[ARM] 3889/1: [Jornada7xx] Addition of correct SDRAM params into cpu-sa1110.c
[ARM] 3890/1: [Jornada7xx] Addition of MCU commands into jornada720.h
Krzysztof Helt (1):
[SPARC]: Sparc compilation fix with floppy enabled
Kumar Gala (1):
[POWERPC] ppc: Add missing calls to set_irq_regs
Larry Finger (2):
bcm43xx-softmac: check returned value from pci_enable_device
bcm43xx-softmac: Fix system hang for x86-64 with >1GB RAM
Laurent Riffard (1):
sotftmac: fix a slab corruption in WEP restricted key association
Lebedev, Vladimir P (2):
ACPI: sbs: check for NULL device pointer
ACPI: sbs: fix module_param() initializers
Len Brown (1):
ACPI: update comments in motherboard.c
Lennart Poettering (3):
ACPI: consolidate functions in acpi ec driver
ACPI: EC: export ec_transaction() for msi-laptop driver
MSI S270 Laptop support: backlight, wlan, bluetooth states
Li Yang (3):
[POWERPC] Fix MPC8360EMDS PB board support
[POWERPC] Add Makefile entry for MPC832x_mds support
ucc_geth: changes to ucc_geth driver as a result of qe_lib changes and bugfixes
Liam Girdwood (1):
[ARM] 3888/1: add pxa27x SSP FSRT register bit definition
Lijun Chen (1):
[TIPC]: Added subscription cancellation capability
Linas Vepstas (1):
e1000: Reset all functions after a PCI error
Linus Torvalds (5):
Fix VM_MAYEXEC calculation
Fix USB gadget net2280.c compile
Revert "[mv643xx] Add pci device table for auto module loading."
Revert unintentional and bogus change to drivers/pci/quirks.c
Linux 2.6.19-rc3
Luiz Fernando N. Capitulino (1):
airprime: New device ID.
Marcel Holtmann (12):
[Bluetooth] Fix compat ioctl for BNEP, CMTP and HIDP
[Bluetooth] Handle return values from driver core functions
[Bluetooth] Make use of virtual devices tree
[Bluetooth] Support concurrent connect requests
[Bluetooth] Disconnect HID interrupt channel first
[Bluetooth] Fix reference count when connection lookup fails
[Bluetooth] Check if DLC is still attached to the TTY
[Bluetooth] Add locking for bt_proto array manipulation
[Bluetooth] Use work queue to trigger URB submission
[Bluetooth] Add support for newer ANYCOM USB dongles
[Bluetooth] Add missing entry for Nokia DTL-4 PCMCIA card
[Bluetooth] Fix HID disconnect NULL pointer dereference
Marcus Junker (1):
[WATCHDOG] w83697hf WDT driver
Marek W (1):
ACPI: asus_acpi: W3000 support
Mark Fasheh (4):
Take i_mutex in splice_from_pipe()
Introduce generic_file_splice_write_nolock()
ocfs2: fix page zeroing during simple extends
ocfs2: cond_resched() in ocfs2_zero_extend()
Martin Habets (1):
[SPARC]: Add sparc profiling support
Martin Schwidefsky (2):
[S390] Fix pte type checking.
[S390] update default configuration
Matt Domsch (1):
PCI: optionally sort device lists breadth-first
Matthew Wilcox (3):
V4L/DVB (4725): Fix vivi compile on parisc
Fix dev_printk() is now GPL-only
cciss: Fix warnings (and bug on 1TB discs)
matthieu castet (4):
UEAGLE : be suspend friendly
UEAGLE : use interruptible sleep
UEAGLE : comestic changes
UEAGLE: fix ueagle-atm Oops
Melissa Howland (1):
[S390] monwriter find header logic.
Michael Buesch (2):
bcm43xx: fix race condition in periodic work handler
softmac: Fix WX and association related races
Michael Chan (1):
[TG3]: Add lower bound checks for tx ring size.
Michael Krufky (3):
V4L/DVB (4731a): Kconfig: restore pvrusb2 menu items
V4L/DVB (4733): Tda10086: fix frontend selection for dvb_attach
V4L/DVB (4734): Tda826x: fix frontend selection for dvb_attach
Michel Dänzer (1):
[AGPGART] uninorth: Add module param 'aperture' for aperture size
Miklos Szeredi (6):
fuse: fix hang on SMP
document i_size_write locking rules
fuse: locking fix for nlookup
fuse: fix spurious BUG
fuse: fix handling of moved directory
fuse: fix dereferencing dentry parent
Muli Ben-Yehuda (1):
x86-64: increase PHB1 split transaction timeout
Neil Brown (1):
Convert cpu hotplug notifiers to use raw_notifier instead of blocking_notifier
NeilBrown (7):
knfsd: Fix bug in recent lockd patches that can cause reclaim to fail
knfsd: Allow lockd to drop replies as appropriate
knfsd: fix race that can disable NFS server
md: fix calculation of ->degraded for multipath and raid10
md: add another COMPAT_IOCTL for md
md: endian annotation for v1 superblock access
md: endian annotations for the bitmap superblock
Nick Piggin (1):
mm: more commenting on lock ordering
Nicolas Pitre (1):
fix PXA2xx UDC compilation error
Noguchi, Masato (1):
[POWERPC] spufs: fix support for read/write on cntl
OGAWA Hirofumi (1):
ext3/4: fix J_ASSERT(transaction->t_updates > 0) in journal_stop()
Olaf Hering (1):
Fix up rpaphp driver for pci hotplug header move
Oliver Neukum (3):
USB: remove private debug macros from kaweth
USB: suspend/resume support for kaweth
USB: fix suspend support for usblp
Pablo Neira Ayuso (1):
[NETFILTER]: ctnetlink: Remove debugging messages
Paolo 'Blaisorblade' Giarrusso (9):
fix typo in memory barrier docs
uml: remove some leftover PPC code
uml: split memory allocation prototypes out of user.h
uml: code convention cleanup of a file
uml: reenable compilation of enable_timer, disabled by mistake
uml: use DEFCONFIG_LIST to avoid reading host's config
uml: cleanup run_helper() API to fix a leak
uml: kconfig - silence warning
uml: mmapper - remove just added but wrong "const" attribute
Patrick Boettcher (2):
V4L/DVB (4748): Fixed oops for Nova-T USB2
V4L/DVB (4750): AGC command1/2 is board specific
Patrick Caulfield (1):
[DLM] fix iovec length in recvmsg
Patrick McHardy (6):
[DECNET]: Use correct config option for routing by fwmark in compare_keys()
[NETFILTER]: fix cut-and-paste error in exit functions
[NETFILTER]: arp_tables: missing unregistration on module unload
[NETFILTER]: ipt_ECN/ipt_TOS: fix incorrect checksum update
[NETFILTER]: xt_CONNSECMARK: fix Kconfig dependencies
[NETFILTER]: Update MAINTAINERS entry
Paul Fulghum (1):
synclink: remove PAGE_SIZE reference
Paul Jackson (1):
cpuset: mempolicy migration typo fix
Paul Moore (3):
NetLabel: only deref the CIPSOv4 standard map fields when using standard mapping
NetLabel: better error handling involving mls_export_cat()
NetLabel: the CIPSOv4 passthrough mapping does not pass categories correctly
Paul Mundt (7):
sh: Proper show_stack/show_trace() implementation.
sh: Remove board-specific ide.h headers.
sh: Cleanup board header directories.
sh: Fix exception_handling_table alignment.
sh: Add some missing board headers.
sh: Updates for irq-flow-type naming changes.
sh: Convert INTC2 to IRQ table registration.
Pavel Machek (1):
ACPI: ibm_acpi: delete obsolete documentation
Pekka Enberg (1):
ecryptfs: use special_file()
Peter Oberparleiter (1):
[S390] cio: invalid device operational notification
Peter Zijlstra (3):
Lockdep: add lockdep_set_class_and_subclass() and lockdep_set_subclass()
lockdep: annotate i386 apm
rt-mutex: fixup rt-mutex debug code
Petr Vandrovec (1):
Fix core files so they make sense to gdb...
Pierre Ossman (2):
ACPI: fix section for CPU init functions
New MMC maintainer
Ping Cheng (1):
USB: Wacom driver updates
Pádraig Brady (1):
V4L/DVB (4739): SECAM support for saa7113 into saa7115
Ralf Baechle (11):
[MIPS] Delete unneeded pt_regs forward declaration.
[MIPS] Malta: Fix uninitialized regs pointer.
[MIPS] A few more pt_regs fixups.
[MIPS] Use compat_sys_mount.
[MIPS] Reserve syscall numbers for kexec_load.
[MIPS] Fix iounmap argument to const volatile.
Make <linux/personality.h> userspace proof
Fix warnings for WARN_ON if CONFIG_BUG is disabled
Fix timer race
[MIPS] Cleanup remaining references to mips_counter_frequency.
[MIPS] Fix aliasing bug in copy_to_user_page / copy_from_user_page
Randy Dunlap (6):
ACPI: fix printk format warnings
fix epoll_pwait when EPOLL=n
Kconfig serial typos
cad_pid sysctl with PROC_FS=n
fs/Kconfig: move GENERIC_ACL, fix acl() call errors
[NET]: kernel-doc fix for sock.h
Randy Vinson (1):
[POWERPC] Fix IO Window Updates on P2P bridges.
Ranjit Manomohan (1):
[TG3]: Fix set ring params tx ring size implementation
Robert Walsh (1):
IB/ipath: Initialize diagpkt file on device init only
Rudolf Marek (2):
k8temp: Documentation update
w83627ehf: Fix the detection of fan5
Russell King (4):
[ARM] Fix fallout from IRQ regs changes
[ARM] Fix Zaurii keyboard/touchscreen drivers
[ARM] Update mach-types
Remove __must_check for device_for_each_child()
Samuel Tardieu (17):
[WATCHDOG] w83697hf/hg WDT driver - patch 1
[WATCHDOG] w83697hf/hg WDT driver - patch 2
[WATCHDOG] w83697hf/hg WDT driver - patch 3
[WATCHDOG] w83697hf/hg WDT driver - patch 4
[WATCHDOG] w83697hf/hg WDT driver - patch 5
[WATCHDOG] w83697hf/hg WDT driver - patch 6
[WATCHDOG] w83697hf/hg WDT driver - patch 7
[WATCHDOG] w83697hf/hg WDT driver - patch 8
[WATCHDOG] w83697hf/hg WDT driver - patch 9
[WATCHDOG] w83697hf/hg WDT driver - patch 10
[WATCHDOG] w83697hf/hg WDT driver - patch 11
[WATCHDOG] w83697hf/hg WDT driver - patch 12
[WATCHDOG] w83697hf/hg WDT driver - patch 13
[WATCHDOG] w83697hf/hg WDT driver - patch 14
[WATCHDOG] w83697hf/hg WDT driver - patch 15
[WATCHDOG] w83697hf/hg WDT driver - patch 16
[WATCHDOG] w83697hf/hg WDT driver - Kconfig patch
Satoru Takeuchi (1):
doc: fixing cpu-hotplug documentation
Stefan Schmidt (3):
ACPI: ibm_acpi: Remove experimental status for brightness and volume.
ACPI: ibm_acpi: Update documentation for brightness and volume.
ACPI: ibm_acpi: Documentation the wan feature.
Stefan Weinhuber (1):
[S390] dasd: clean up timer.
Stephen Hemminger (16):
[BRIDGE]: flush forwarding table when device carrier off
rename net_random to random32
sky2: MSI test is only a warning
sky2: turn of workaround timer
sky2: phy irq on shutdown
sky2: fiber pause bits
sky2: advertising register 16 bits
sky2: use duplex result bits
sky2: don't reset PHY twice
sky2: flow control setting fixes
sky2: no message on rx fifo overflow
sky2: version 1.9
sky2: accept multicast pause frames
sky2: GMAC pause frame
[NETPOLL]: initialize skb for UDP
sky2: 88E803X transmit lockup
Steven Toth (1):
V4L/DVB (4692): Add WinTV-HVR3000 DVB-T support
Steven Whitehouse (2):
[DECNET]: Fix input routing bug
[GFS2] Fix bmap to map extents properly
Sunil Mushran (1):
ocfs2: remove spurious d_count check in ocfs2_rename()
Sven Anders (1):
[WATCHDOG] Winbond SMsC37B787 watchdog driver
Takashi Iwai (8):
[ALSA] hda-codec - Fix assignment of PCM devices for Realtek codecs
[ALSA] Various fixes for suspend/resume of ALSA PCI drivers
[ALSA] Fix dependency of snd-adlib driver in Kconfig
[ALSA] hda-codec - Add model entry for ASUS U5F laptop
[ALSA] Fix re-use of va_list
[ALSA] Fix AC97 power-saving mode
[ALSA] Fix addition of user-defined boolean controls
[ALSA] hda-intel - Add check of MSI availabity
Tejun Heo (1):
libata: typo fix
Thiemo Seufer (1):
[MIPS] Fix O32 personality(2) call with 0xffffffff argument.
Thomas Gleixner (1):
posix-cpu-timers: prevent signal delivery starvation
Thomas Graf (4):
[IPv6] rules: Use RT6_LOOKUP_F_HAS_SADDR and fix source based selectors
[IPv4] fib: Remove unused fib_config members
[IPv6] route: Fix prohibit and blackhole routing decision
[IPv6] fib: initialize tb6_lock in common place to give lockdep a key
Thomas Maier (1):
export clear_queue_congested and set_queue_congested
Timur Tabi (1):
[POWERPC] Add DOS partition table support to mpc834x_itx_defconfig
Tobias Klauser (1):
[ATM]: No need to return void
Tobias Lorenz (1):
USB: Mitsumi USB FDD 061M: UNUSUAL_DEV multilun fix
Tony Luck (1):
[IA64] perfmon fix for global IRQ fix
Trond Myklebust (7):
NFSv4: Fix thinko in fs/nfs/super.c
NFS: Fix oops in nfs_cancel_commit_list
NFS: Fix error handling in nfs_direct_write_result()
NFS: Fix NFSv4 callback regression
NFS: Deal with failure of invalidate_inode_pages2()
VFS: Make d_materialise_unique() enforce directory uniqueness
NFS: Cache invalidation fixup
Ulrich Drepper (1):
make UML compile (FC6/x86-64)
Uwe Bugla (1):
V4L/DVB (4732): Fix spelling error in Kconfig help text for DVB_CORE_ATTACH
Venkatesh Pallipadi (1):
ACPI: Processor native C-states using MWAIT
Ville Nuorvala (6):
[IPV6]: Remove struct pol_chain.
[SCTP]: Fix minor typo
[IPV6]: Make sure error handling is done when calling ip6_route_output().
[IPV6]: Clean up BACKTRACK().
[IPV6]: Make IPV6_SUBTREES depend on IPV6_MULTIPLE_TABLES.
[IPV6]: Always copy rt->u.dst.error when copying a rt6_info.
Vivek Goyal (2):
x86-64: fix page align in e820 allocator
x86-64: Overlapping program headers in physical addr space fix
Vojtech Pavlik (1):
Fix DMA resource allocation in ACPIPnP
Wim Van Sebroeck (9):
[WATCHDOG] Winbond SMsC37B787 - remove trailing whitespace
[WATCHDOG] Winbond SMsC37B787 watchdog fixes
[WATCHDOG] Kconfig clean-up
[WATCHDOG] w836?7hf_wdt spinlock fixes.
[WATCHDOG] Kconfig clean up
[WATCHDOG] use ENOTTY instead of ENOIOCTLCMD in ioctl()
[WATCHDOG] w83697hf/hg WDT driver - autodetect patch
[WATCHDOG] add ich8 support to iTCO_wdt.c (patch 2)
[WATCHDOG] remove experimental on iTCO_wdt.c
Yasunori Goto (2):
Change log level of a message of acpi_memhotplug to KERN_DEBUG
acpi memory hotplug: remove strange add_memory fail message
Yinghai Lu (1):
x86-64: typo in __assign_irq_vector when updating pos for vector and offset
Yoichi Yuasa (4):
[MIPS] More vr41xx pt_regs fixups
[MIPS] Update pnx8500-jbs_defconfig
[MIPS] Update pnx8550-v2pci_defconfig
[MIPS] Update tb0287_defconfig
YOSHIFUJI Hideaki (1):
[IPV6]: Remove bogus WARN_ON in Proxy-NA handling.
Zachary Amsden (1):
Fix potential interrupts during alternative patching
Zhang, Yanmin (1):
PCI: fix pcie_portdrv_restore_config undefined without CONFIG_PM error
^ permalink raw reply [flat|nested] 152+ messages in thread* Re: Linux 2.6.19-rc3 2006-10-23 23:22 Linux 2.6.19-rc3 Linus Torvalds @ 2006-10-24 2:24 ` Gene Heskett 2006-10-24 7:46 ` Muli Ben-Yehuda ` (6 subsequent siblings) 7 siblings, 0 replies; 152+ messages in thread From: Gene Heskett @ 2006-10-24 2:24 UTC (permalink / raw) To: linux-kernel; +Cc: Linus Torvalds On Monday 23 October 2006 19:22, Linus Torvalds wrote: >Ok, > a few days late, because I'm a retard and didn't think of doing a > release when I should have. A couple of things noted in a dmesg report after booting it. drivers/rtc/hctosys.c: unable to open rtc device (rtc0) ----- warning: process `date' used the removed sysctl system call ----- warning: process `date' used the removed sysctl system call ----- warning: process `quotaon' used the removed sysctl system call ------ warning: process `kudzu' used the removed sysctl system call ieee1394: Host added: ID:BUS[0-00:1023] GUID[00d0035600a886d8] warning: process `kudzu' used the removed sysctl system call The system seems to be ok so far. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved. ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: Linux 2.6.19-rc3 2006-10-23 23:22 Linux 2.6.19-rc3 Linus Torvalds 2006-10-24 2:24 ` Gene Heskett @ 2006-10-24 7:46 ` Muli Ben-Yehuda 2006-10-24 18:07 ` Badari Pulavarty 2006-10-24 20:21 ` Adrian Bunk ` (5 subsequent siblings) 7 siblings, 1 reply; 152+ messages in thread From: Muli Ben-Yehuda @ 2006-10-24 7:46 UTC (permalink / raw) To: Linus Torvalds; +Cc: Linux Kernel Mailing List, Eric W. Biederman, Andi Kleen On Mon, Oct 23, 2006 at 04:22:59PM -0700, Linus Torvalds wrote: > > Ok, > a few days late, because I'm a retard and didn't think of doing a release > when I should have. > > I'm also a bit grumpy, because I think people are sending me more stuff > than they should at this stage in the game. We've been pretty good about > keeping the later -rc releases quiet, please keep it that way. > > That said, it's mostly harmless cleanups and some architecture updates. > And some of the added warnings about unused return values have caused a > number of people to add error handling. And on the driver front, there's > mainly new driver ID's, and a couple of new drivers. The genirq changes broke boot on my x86-64 x366 machine. It needs these two patches: http://marc.theaimsgroup.com/?l=linux-kernel&m=116157813623508&w=2 http://marc.theaimsgroup.com/?l=linux-kernel&m=116157837104613&w=2 It also broke tg3 on at least one other machine, so this is not specific to my machine. Cheers, Muli ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: Linux 2.6.19-rc3 2006-10-24 7:46 ` Muli Ben-Yehuda @ 2006-10-24 18:07 ` Badari Pulavarty 0 siblings, 0 replies; 152+ messages in thread From: Badari Pulavarty @ 2006-10-24 18:07 UTC (permalink / raw) To: Muli Ben-Yehuda Cc: Linus Torvalds, Linux Kernel Mailing List, Eric W. Biederman, Andi Kleen On Tue, 2006-10-24 at 09:46 +0200, Muli Ben-Yehuda wrote: > On Mon, Oct 23, 2006 at 04:22:59PM -0700, Linus Torvalds wrote: > > > > Ok, > > a few days late, because I'm a retard and didn't think of doing a release > > when I should have. > > > > I'm also a bit grumpy, because I think people are sending me more stuff > > than they should at this stage in the game. We've been pretty good about > > keeping the later -rc releases quiet, please keep it that way. > > > > That said, it's mostly harmless cleanups and some architecture updates. > > And some of the added warnings about unused return values have caused a > > number of people to add error handling. And on the driver front, there's > > mainly new driver ID's, and a couple of new drivers. > > The genirq changes broke boot on my x86-64 x366 machine. It needs > these two patches: > > http://marc.theaimsgroup.com/?l=linux-kernel&m=116157813623508&w=2 > http://marc.theaimsgroup.com/?l=linux-kernel&m=116157837104613&w=2 Yes. Without these patches, I can't seem to get my qlogic driver to work :( Thanks, Badari ACPI: PCI Interrupt 0000:01:05.0[A] -> GSI 17 (level, low) -> IRQ 17 qla2xxx 0000:01:05.0: Found an ISP2200, irq 17, iobase 0xffffc20000064000 qla2xxx 0000:01:05.0: Configuring PCI space... qla2xxx 0000:01:05.0: Configure NVRAM parameters... qla2xxx 0000:01:05.0: Verifying loaded RISC code... qla2xxx 0000:01:05.0: Allocated (252 KB) for firmware dump... qla2xxx 0000:01:05.0: LIP reset occured (f723). qla2xxx 0000:01:05.0: Waiting for LIP to complete... qla2xxx 0000:01:05.0: LIP occured (f723). qla2xxx 0000:01:05.0: LOOP UP detected (1 Gbps). qla2xxx 0000:01:05.0: Topology - (Loop), Host Loop address 0x7d qla2xxx 0000:01:05.0: Failed to reserve interrupt 17 already in use. qla2xxx: probe of 0000:01:05.0 failed with error -38 ACPI: PCI Interrupt 0000:0f:01.0[A] -> GSI 29 (level, low) -> IRQ 29 qla2xxx 0000:0f:01.0: Found an ISP2312, irq 29, iobase 0xffffc20000064000 qla2xxx 0000:0f:01.0: Configuring PCI space... qla2xxx 0000:0f:01.0: Configure NVRAM parameters... qla2xxx 0000:0f:01.0: Verifying loaded RISC code... qla2xxx 0000:0f:01.0: Allocated (412 KB) for firmware dump... qla2xxx 0000:0f:01.0: Waiting for LIP to complete... qla2xxx 0000:0f:01.0: Cable is unplugged... qla2xxx 0000:0f:01.0: Failed to reserve interrupt 29 already in use. qla2xxx: probe of 0000:0f:01.0 failed with error -38 ACPI: PCI Interrupt 0000:19:01.0[A] -> GSI 37 (level, low) -> IRQ 37 qla2xxx 0000:19:01.0: Found an ISP2200, irq 37, iobase 0xffffc20000064000 qla2xxx 0000:19:01.0: Configuring PCI space... qla2xxx 0000:19:01.0: Configure NVRAM parameters... qla2xxx 0000:19:01.0: Verifying loaded RISC code... qla2xxx 0000:19:01.0: Allocated (252 KB) for firmware dump... qla2xxx 0000:19:01.0: LIP reset occured (f725). qla2xxx 0000:19:01.0: Waiting for LIP to complete... qla2xxx 0000:19:01.0: LIP occured (f725). qla2xxx 0000:19:01.0: LOOP UP detected (1 Gbps). qla2xxx 0000:19:01.0: Topology - (Loop), Host Loop address 0x8 qla2xxx 0000:19:01.0: Failed to reserve interrupt 37 already in use. qla2xxx: probe of 0000:19:01.0 failed with error -38 ^ permalink raw reply [flat|nested] 152+ messages in thread
* 2.6.19-rc3: known unfixed regressions 2006-10-23 23:22 Linux 2.6.19-rc3 Linus Torvalds 2006-10-24 2:24 ` Gene Heskett @ 2006-10-24 20:21 ` Adrian Bunk 2006-10-24 20:21 ` Adrian Bunk ` (5 subsequent siblings) 7 siblings, 0 replies; 152+ messages in thread From: Adrian Bunk @ 2006-10-24 20:21 UTC (permalink / raw) To: Linus Torvalds, Andrew Morton Cc: Linux Kernel Mailing List, art, teunis, Jiri Slaby, pavel, linux-pm, ak, Martin Lorenz, len.brown, linux-acpi, Michael S. Tsirkin, Thierry Vignaud, jgarzik, linux-ide, Alex Romosan, Jens Axboe, Komuro, Thomas Gleixner, Benjamin Herrenschmidt, Stefan Richter, linux1394-devel, Christian, Mark Langsdorf, davej, cpufreq, Stephen Hemminger, Greg KH, linux- This email lists some known unfixed regressions in 2.6.19-rc3 compared to 2.6.18. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject : shutdown problem References : http://lkml.org/lkml/2006/10/22/140 Submitter : art@usfltd.com teunis@wintersgift.com Jiri Slaby <jirislaby@gmail.com> Status : unknown Subject : X60s: BUG()s, lose ACPI events after suspend/resume References : http://lkml.org/lkml/2006/10/10/39 Submitter : Martin Lorenz <martin@lorenz.eu.org> Status : unknown Subject : T60 stops triggering any ACPI events References : http://lkml.org/lkml/2006/10/4/425 http://lkml.org/lkml/2006/10/16/262 http://bugzilla.kernel.org/show_bug.cgi?id=7408 Submitter : "Michael S. Tsirkin" <mst@mellanox.co.il> Status : unknown Subject : sata-via doesn't detect anymore disks attached to VIA vt6421 References : http://bugzilla.kernel.org/show_bug.cgi?id=7255 Submitter : Thierry Vignaud <tvignaud@mandriva.com> Status : unknown Subject : unable to rip cd References : http://lkml.org/lkml/2006/10/13/100 Submitter : Alex Romosan <romosan@sycorax.lbl.gov> Status : unknown Subject : SMP kernel can not generate ISA irq properly References : http://lkml.org/lkml/2006/10/22/15 Submitter : Komuro <komurojun-mbn@nifty.com> Handled-By : Thomas Gleixner <tglx@linutronix.de> Status : Thomas will investigate Subject : ohci1394 on PPC_PMAC: pci_set_power_state() failure and breaking suspend References : http://lkml.org/lkml/2006/10/24/13 Submitter : Benjamin Herrenschmidt <benh@kernel.crashing.org> Caused-By : Stefan Richter <stefanr@s5r6.in-berlin.de> commit ea6104c22468239083857fa07425c312b1ecb424 Handled-By : Stefan Richter <stefanr@s5r6.in-berlin.de> Status : Stefan Richter: looking for an answer when to ignore the return code of pci_set_power_state Subject : cpufreq not working on AMD K8 References : http://lkml.org/lkml/2006/10/10/114 Submitter : Christian <christiand59@web.de> Handled-By : Mark Langsdorf <mark.langsdorf@amd.com> Status : Mark is investigating Subject : MSI errors during boot (CONFIG_PCI_MULTITHREAD_PROBE) References : http://lkml.org/lkml/2006/10/16/291 Submitter : Stephen Hemminger <shemminger@osdl.org> Handled-By : Greg KH <greg@kroah.com> Status : Greg is working on a fix ^ permalink raw reply [flat|nested] 152+ messages in thread
* 2.6.19-rc3: known unfixed regressions @ 2006-10-24 20:21 ` Adrian Bunk 0 siblings, 0 replies; 152+ messages in thread From: Adrian Bunk @ 2006-10-24 20:21 UTC (permalink / raw) To: Linus Torvalds, Andrew Morton Cc: Linux Kernel Mailing List, art, teunis, Jiri Slaby, pavel, linux-pm, ak, Martin Lorenz, len.brown, linux-acpi, Michael S. Tsirkin, Thierry Vignaud, jgarzik, linux-ide, Alex Romosan, Jens Axboe, Komuro, Thomas Gleixner, Benjamin Herrenschmidt, Stefan Richter, linux1394-devel, Christian, Mark Langsdorf, davej, cpufreq, Stephen Hemminger, Greg KH, linux-pci This email lists some known unfixed regressions in 2.6.19-rc3 compared to 2.6.18. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject : shutdown problem References : http://lkml.org/lkml/2006/10/22/140 Submitter : art@usfltd.com teunis@wintersgift.com Jiri Slaby <jirislaby@gmail.com> Status : unknown Subject : X60s: BUG()s, lose ACPI events after suspend/resume References : http://lkml.org/lkml/2006/10/10/39 Submitter : Martin Lorenz <martin@lorenz.eu.org> Status : unknown Subject : T60 stops triggering any ACPI events References : http://lkml.org/lkml/2006/10/4/425 http://lkml.org/lkml/2006/10/16/262 http://bugzilla.kernel.org/show_bug.cgi?id=7408 Submitter : "Michael S. Tsirkin" <mst@mellanox.co.il> Status : unknown Subject : sata-via doesn't detect anymore disks attached to VIA vt6421 References : http://bugzilla.kernel.org/show_bug.cgi?id=7255 Submitter : Thierry Vignaud <tvignaud@mandriva.com> Status : unknown Subject : unable to rip cd References : http://lkml.org/lkml/2006/10/13/100 Submitter : Alex Romosan <romosan@sycorax.lbl.gov> Status : unknown Subject : SMP kernel can not generate ISA irq properly References : http://lkml.org/lkml/2006/10/22/15 Submitter : Komuro <komurojun-mbn@nifty.com> Handled-By : Thomas Gleixner <tglx@linutronix.de> Status : Thomas will investigate Subject : ohci1394 on PPC_PMAC: pci_set_power_state() failure and breaking suspend References : http://lkml.org/lkml/2006/10/24/13 Submitter : Benjamin Herrenschmidt <benh@kernel.crashing.org> Caused-By : Stefan Richter <stefanr@s5r6.in-berlin.de> commit ea6104c22468239083857fa07425c312b1ecb424 Handled-By : Stefan Richter <stefanr@s5r6.in-berlin.de> Status : Stefan Richter: looking for an answer when to ignore the return code of pci_set_power_state Subject : cpufreq not working on AMD K8 References : http://lkml.org/lkml/2006/10/10/114 Submitter : Christian <christiand59@web.de> Handled-By : Mark Langsdorf <mark.langsdorf@amd.com> Status : Mark is investigating Subject : MSI errors during boot (CONFIG_PCI_MULTITHREAD_PROBE) References : http://lkml.org/lkml/2006/10/16/291 Submitter : Stephen Hemminger <shemminger@osdl.org> Handled-By : Greg KH <greg@kroah.com> Status : Greg is working on a fix ^ permalink raw reply [flat|nested] 152+ messages in thread
* 2.6.19-rc3: known unfixed regressions @ 2006-10-24 20:21 ` Adrian Bunk 0 siblings, 0 replies; 152+ messages in thread From: Adrian Bunk @ 2006-10-24 20:21 UTC (permalink / raw) To: Linus Torvalds, Andrew Morton Cc: Linux Kernel Mailing List, art, teunis, Jiri Slaby, pavel, linux-pm, ak, Martin Lorenz, len.brown, linux-acpi, Michael S. Tsirkin, Thierry Vignaud, jgarzik, linux-ide, Alex Romosan, Jens Axboe, Komuro, Thomas Gleixner, Benjamin Herrenschmidt, Stefan Richter, linux1394-devel, Christian, Mark Langsdorf, davej, cpufreq, Stephen Hemminger, Greg KH This email lists some known unfixed regressions in 2.6.19-rc3 compared to 2.6.18. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject : shutdown problem References : http://lkml.org/lkml/2006/10/22/140 Submitter : art@usfltd.com teunis@wintersgift.com Jiri Slaby <jirislaby@gmail.com> Status : unknown Subject : X60s: BUG()s, lose ACPI events after suspend/resume References : http://lkml.org/lkml/2006/10/10/39 Submitter : Martin Lorenz <martin@lorenz.eu.org> Status : unknown Subject : T60 stops triggering any ACPI events References : http://lkml.org/lkml/2006/10/4/425 http://lkml.org/lkml/2006/10/16/262 http://bugzilla.kernel.org/show_bug.cgi?id=7408 Submitter : "Michael S. Tsirkin" <mst@mellanox.co.il> Status : unknown Subject : sata-via doesn't detect anymore disks attached to VIA vt6421 References : http://bugzilla.kernel.org/show_bug.cgi?id=7255 Submitter : Thierry Vignaud <tvignaud@mandriva.com> Status : unknown Subject : unable to rip cd References : http://lkml.org/lkml/2006/10/13/100 Submitter : Alex Romosan <romosan@sycorax.lbl.gov> Status : unknown Subject : SMP kernel can not generate ISA irq properly References : http://lkml.org/lkml/2006/10/22/15 Submitter : Komuro <komurojun-mbn@nifty.com> Handled-By : Thomas Gleixner <tglx@linutronix.de> Status : Thomas will investigate Subject : ohci1394 on PPC_PMAC: pci_set_power_state() failure and breaking suspend References : http://lkml.org/lkml/2006/10/24/13 Submitter : Benjamin Herrenschmidt <benh@kernel.crashing.org> Caused-By : Stefan Richter <stefanr@s5r6.in-berlin.de> commit ea6104c22468239083857fa07425c312b1ecb424 Handled-By : Stefan Richter <stefanr@s5r6.in-berlin.de> Status : Stefan Richter: looking for an answer when to ignore the return code of pci_set_power_state Subject : cpufreq not working on AMD K8 References : http://lkml.org/lkml/2006/10/10/114 Submitter : Christian <christiand59@web.de> Handled-By : Mark Langsdorf <mark.langsdorf@amd.com> Status : Mark is investigating Subject : MSI errors during boot (CONFIG_PCI_MULTITHREAD_PROBE) References : http://lkml.org/lkml/2006/10/16/291 Submitter : Stephen Hemminger <shemminger@osdl.org> Handled-By : Greg KH <greg@kroah.com> Status : Greg is working on a fix ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions: confirmations 2006-10-24 20:21 ` Adrian Bunk (?) (?) @ 2006-10-24 21:44 ` teunis 2006-10-26 15:31 ` Adrian Bunk -1 siblings, 1 reply; 152+ messages in thread From: teunis @ 2006-10-24 21:44 UTC (permalink / raw) To: Adrian Bunk, linux-kernel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adrian Bunk wrote: > This email lists some known unfixed regressions in 2.6.19-rc3 compared > to 2.6.18. ... I'm not directly testing -rc3 as yet... rc2-mm2 + a few modifications works on the equipment I'm testing and as I can't afford more lost time due to faults - I'm keeping to that build for the short term. > Subject : shutdown problem > References : http://lkml.org/lkml/2006/10/22/140 > Submitter : art@usfltd.com > teunis@wintersgift.com > Jiri Slaby <jirislaby@gmail.com> > Status : unknown repaired by Jeff Dike's patch to fs/proc/array.c VFAT failure: inode.c patch worked. Has this been fixed in -rc3? (email I've reviewed implies no) HP nx6110 and nx6310 (i945G chipsets) - ACPI S3 and S4 (is that right?) now fully operational. speedstep not yet operational on nx6310 (Yonah). synaptic driver: does not recover in S3 mode on nx7400 () or Acer TravelMate 8000 (Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI) Suspect USB host problem as synaptic driver DOES recover on nx6130. This IS a regression as these worked fine in kernels where S3 formerly worked. Video does not yet fully recover on nx7400 - but it never has so that's not a regression (backlight fails to recover). Any idea when Yonah (family 6/model 14/stepping 8) will be supported by either speedstep, P4 or ACPI driver? NONE of these work. P4 did work briefly (-rc1-git4 and -rc1-git6) but I'm not sure that it's optimal. acpi-cpufreq hasn't loaded since 2.6.18 (which didn't work properly with other parts of the laptops so went with 2.6.19 rc series). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFPokhbFT/SAfwLKMRAgFrAKCS/3jAVs12uk2LWhAcN/vFZe7nvACfeLr2 EJOWO0HZ4hVk3UXZoxe4BbQ= =wO+m -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions: confirmations 2006-10-24 21:44 ` 2.6.19-rc3: known unfixed regressions: confirmations teunis @ 2006-10-26 15:31 ` Adrian Bunk 2006-10-26 15:54 ` teunis 0 siblings, 1 reply; 152+ messages in thread From: Adrian Bunk @ 2006-10-26 15:31 UTC (permalink / raw) To: teunis; +Cc: linux-kernel, art, Jiri Slaby, Jeff Dike, pavel, linux-pm On Tue, Oct 24, 2006 at 02:44:01PM -0700, teunis wrote: > Adrian Bunk wrote: > > This email lists some known unfixed regressions in 2.6.19-rc3 compared > > to 2.6.18. > ... > > I'm not directly testing -rc3 as yet... rc2-mm2 + a few modifications > works on the equipment I'm testing and as I can't afford more lost time > due to faults - I'm keeping to that build for the short term. > > > Subject : shutdown problem > > References : http://lkml.org/lkml/2006/10/22/140 > > Submitter : art@usfltd.com > > teunis@wintersgift.com > > Jiri Slaby <jirislaby@gmail.com> > > Status : unknown > > repaired by Jeff Dike's patch to fs/proc/array.c >... Can you give me a pointer to this patch? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions: confirmations 2006-10-26 15:31 ` Adrian Bunk @ 2006-10-26 15:54 ` teunis 0 siblings, 0 replies; 152+ messages in thread From: teunis @ 2006-10-26 15:54 UTC (permalink / raw) To: Adrian Bunk Cc: teunis, linux-kernel, art, Jiri Slaby, Jeff Dike, pavel, linux-pm -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adrian Bunk wrote: > On Tue, Oct 24, 2006 at 02:44:01PM -0700, teunis wrote: >> Adrian Bunk wrote: >>> This email lists some known unfixed regressions in 2.6.19-rc3 compared >>> to 2.6.18. >> ... >> >> I'm not directly testing -rc3 as yet... rc2-mm2 + a few modifications >> works on the equipment I'm testing and as I can't afford more lost time >> due to faults - I'm keeping to that build for the short term. >> >>> Subject : shutdown problem >>> References : http://lkml.org/lkml/2006/10/22/140 >>> Submitter : art@usfltd.com >>> teunis@wintersgift.com >>> Jiri Slaby <jirislaby@gmail.com> >>> Status : unknown >> repaired by Jeff Dike's patch to fs/proc/array.c >> ... > > Can you give me a pointer to this patch? > > cu > Adrian > I have no idea how to look up the link any other way - so here's a copy of the details from my mailbox (I've been keeping an archive local as I frequently work offline) posted by: akpm@osdl.org; 23/10/06 10:34 AM From: Jeff Dike <jdike@addtoit.com> add-process_session-helper-routine-deprecate-old-field-fix-warnings.patch in -mm causes UML to hang at shutdown - init is sitting in a select on the initctl socket. This patch fixes it for me. Signed-off-by: Jeff Dike <jdike@addtoit.com> Cc: Cedric Le Goater <clg@fr.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> - --- fs/proc/array.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN fs/proc/array.c~add-process_session-helper-routine-deprecate-old-field-fix-warnings-fix fs/proc/array.c - --- a/fs/proc/array.c~add-process_session-helper-routine-deprecate-old-field-fix-warnings-fix +++ a/fs/proc/array.c @@ -388,7 +388,7 @@ static int do_task_stat(struct task_stru stime = cputime_add(stime, sig->stime); } - - signal_session(sig); + sid = signal_session(sig); pgid = process_group(task); ppid = rcu_dereference(task->real_parent)->tgid; -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFQNojbFT/SAfwLKMRAqioAJ9+l+87bNRFJaHknJBGu6bYfrTlrACeOyts gkeCAiYDPBmR7E052LEMAtU= =eyIw -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 152+ messages in thread
* 2.6.19-rc3: known regressions with patches 2006-10-23 23:22 Linux 2.6.19-rc3 Linus Torvalds @ 2006-10-25 1:51 ` Adrian Bunk 2006-10-24 7:46 ` Muli Ben-Yehuda ` (6 subsequent siblings) 7 siblings, 0 replies; 152+ messages in thread From: Adrian Bunk @ 2006-10-25 1:51 UTC (permalink / raw) To: Linus Torvalds, Andrew Morton Cc: Linux Kernel Mailing List, Muli Ben-Yehuda, Gleb Natapov, Yinghai Lu, Eric W. Biederman, Alistair John Strachan, Patrick McHardy, herbert, linux-crypto, Paul Mundt, Heiko Carstens, linux-390, David Miller, Eiichiro Oiwa, gregkh, linux-pci, Jesper Juhl, David Howells, Andrey Panin, linux-visws-devel, Andrew de Quincey, Trent Piepho, v4l-dvb-maintainer This email lists some known regressions in 2.6.19-rc3 compared to 2.6.18 with patches available. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject : "ACPI: PCI interrupt for device ... disabled" References : http://lkml.org/lkml/2006/10/21/227 http://lkml.org/lkml/2006/10/23/89 Submitter : Muli Ben-Yehuda <muli@il.ibm.com> Gleb Natapov <glebn@voltaire.com> Caused-By : Yinghai Lu <yinghai.lu@amd.com> commit 45edfd1db02f818b3dc7e4743ee8585af6b78f78 Handled-By : Eric W. Biederman <ebiederm@xmission.com> Patch : http://marc.theaimsgroup.com/?l=linux-kernel&m=116157813623508&w=2 http://marc.theaimsgroup.com/?l=linux-kernel&m=116157837104613&w=2 Status : patches available Subject : missing select's of CRYPTO_ECB References : http://lkml.org/lkml/2006/10/22/203 Submitter : Alistair John Strachan <s0348365@sms.ed.ac.uk> Handled-By : Patrick McHardy <kaber@trash.net> Patch : http://lkml.org/lkml/2006/10/23/207 Status : patch available Subject : s390: Point sys_getcpu_wrapper at the proper syscall References : http://lkml.org/lkml/2006/10/19/72 Submitter : Paul Mundt <lethal@linux-sh.org> Caused-By : Heiko Carstens <heiko.carstens@de.ibm.com> commit 8abfe01dae8c0ed7ca6bfb153a7fcab47df72a52 Handled-By : Paul Mundt <lethal@linux-sh.org> Patch : http://lkml.org/lkml/2006/10/19/72 Status : patch available Subject : pci_fixup_video change blows up on sparc64 References : http://lkml.org/lkml/2006/10/19/17 Submitter : David Miller <davem@davemloft.net> Caused-By : Eiichiro Oiwa <eiichiro.oiwa.nm@hitachi.com> commit b5e4efe7e061ff52ac97b9fa45acca529d8daeea Handled-By : Eiichiro Oiwa <eiichiro.oiwa.nm@hitachi.com> Patch : http://lkml.org/lkml/2006/10/23/31 Status : patch available Subject : CONFIG_X86_VISWS=y, CONFIG_SMP=n compile error References : http://lkml.org/lkml/2006/10/7/51 Submitter : Jesper Juhl <jesper.juhl@gmail.com> Caused-By : David Howells <dhowells@redhat.com> commit 7d12e780e003f93433d49ce78cfedf4b4c52adc5 Handled-By : Andrey Panin <pazke@donpac.ru> Patch : http://lkml.org/lkml/2006/10/23/118 Status : patch available Subject : DVB frontend selection causes compile errors References : http://lkml.org/lkml/2006/10/8/244 Submitter : Adrian Bunk <bunk@stusta.de> Caused-By : "Andrew de Quincey" <adq_dvb@lidskialf.net> commit 176ac9da4f09820a43fd48f0e74b1486fc3603ba Handled-By : Trent Piepho <xyzzy@speakeasy.org> Patch : http://lkml.org/lkml/2006/10/14/157 Status : patch available ^ permalink raw reply [flat|nested] 152+ messages in thread
* 2.6.19-rc3: known regressions with patches @ 2006-10-25 1:51 ` Adrian Bunk 0 siblings, 0 replies; 152+ messages in thread From: Adrian Bunk @ 2006-10-25 1:51 UTC (permalink / raw) To: Linus Torvalds, Andrew Morton Cc: Linux Kernel Mailing List, Muli Ben-Yehuda, Gleb Natapov, Yinghai Lu, Eric W. Biederman, Alistair John Strachan, Patrick McHardy, herbert, linux-crypto, Paul Mundt, Heiko Carstens, linux-390, David Miller, Eiichiro Oiwa, gregkh, linux-pci, Jesper Juhl, David Howells, Andrey Panin, linux-visws-devel, Andrew de Quincey, Trent Piepho, v4l-dvb-maintainer This email lists some known regressions in 2.6.19-rc3 compared to 2.6.18 with patches available. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject : "ACPI: PCI interrupt for device ... disabled" References : http://lkml.org/lkml/2006/10/21/227 http://lkml.org/lkml/2006/10/23/89 Submitter : Muli Ben-Yehuda <muli@il.ibm.com> Gleb Natapov <glebn@voltaire.com> Caused-By : Yinghai Lu <yinghai.lu@amd.com> commit 45edfd1db02f818b3dc7e4743ee8585af6b78f78 Handled-By : Eric W. Biederman <ebiederm@xmission.com> Patch : http://marc.theaimsgroup.com/?l=linux-kernel&m=116157813623508&w=2 http://marc.theaimsgroup.com/?l=linux-kernel&m=116157837104613&w=2 Status : patches available Subject : missing select's of CRYPTO_ECB References : http://lkml.org/lkml/2006/10/22/203 Submitter : Alistair John Strachan <s0348365@sms.ed.ac.uk> Handled-By : Patrick McHardy <kaber@trash.net> Patch : http://lkml.org/lkml/2006/10/23/207 Status : patch available Subject : s390: Point sys_getcpu_wrapper at the proper syscall References : http://lkml.org/lkml/2006/10/19/72 Submitter : Paul Mundt <lethal@linux-sh.org> Caused-By : Heiko Carstens <heiko.carstens@de.ibm.com> commit 8abfe01dae8c0ed7ca6bfb153a7fcab47df72a52 Handled-By : Paul Mundt <lethal@linux-sh.org> Patch : http://lkml.org/lkml/2006/10/19/72 Status : patch available Subject : pci_fixup_video change blows up on sparc64 References : http://lkml.org/lkml/2006/10/19/17 Submitter : David Miller <davem@davemloft.net> Caused-By : Eiichiro Oiwa <eiichiro.oiwa.nm@hitachi.com> commit b5e4efe7e061ff52ac97b9fa45acca529d8daeea Handled-By : Eiichiro Oiwa <eiichiro.oiwa.nm@hitachi.com> Patch : http://lkml.org/lkml/2006/10/23/31 Status : patch available Subject : CONFIG_X86_VISWS=y, CONFIG_SMP=n compile error References : http://lkml.org/lkml/2006/10/7/51 Submitter : Jesper Juhl <jesper.juhl@gmail.com> Caused-By : David Howells <dhowells@redhat.com> commit 7d12e780e003f93433d49ce78cfedf4b4c52adc5 Handled-By : Andrey Panin <pazke@donpac.ru> Patch : http://lkml.org/lkml/2006/10/23/118 Status : patch available Subject : DVB frontend selection causes compile errors References : http://lkml.org/lkml/2006/10/8/244 Submitter : Adrian Bunk <bunk@stusta.de> Caused-By : "Andrew de Quincey" <adq_dvb@lidskialf.net> commit 176ac9da4f09820a43fd48f0e74b1486fc3603ba Handled-By : Trent Piepho <xyzzy@speakeasy.org> Patch : http://lkml.org/lkml/2006/10/14/157 Status : patch available ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: Linux 2.6.19-rc3 2006-10-23 23:22 Linux 2.6.19-rc3 Linus Torvalds ` (3 preceding siblings ...) 2006-10-25 1:51 ` Adrian Bunk @ 2006-10-25 11:25 ` Jean Delvare 2006-10-25 12:01 ` Damien Wyart 2006-10-25 20:13 ` Linux 2.6.19-rc3: !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB Athanasius ` (2 subsequent siblings) 7 siblings, 1 reply; 152+ messages in thread From: Jean Delvare @ 2006-10-25 11:25 UTC (permalink / raw) To: Auke Kok, Jeff Garzik Cc: Linux Kernel Mailing List, Linus Torvalds, Adrian Bunk On Mon, 23 Oct 2006 16:22:59 -0700 (PDT), Linus Torvalds wrote: > > Ok, > a few days late, because I'm a retard and didn't think of doing a release > when I should have. > > I'm also a bit grumpy, because I think people are sending me more stuff > than they should at this stage in the game. We've been pretty good about > keeping the later -rc releases quiet, please keep it that way. > > That said, it's mostly harmless cleanups and some architecture updates. > And some of the added warnings about unused return values have caused a > number of people to add error handling. And on the driver front, there's > mainly new driver ID's, and a couple of new drivers. > > Shortlog appended, > (...) > Auke Kok (1): > e100: fix reboot -f with netconsole enabled This one breaks power-off and reboot on my laptop (thanks to git bisect for isolating it). The shutdown freezes after "Shutdown: hda" or "Rebooting". SysRq-p says the CPU is idle. If you need additional information on my config or want me to do more tests, just ask. Adrian, you can add this to your list of known regressions. Thanks, -- Jean Delvare ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: Linux 2.6.19-rc3 2006-10-25 11:25 ` Linux 2.6.19-rc3 Jean Delvare @ 2006-10-25 12:01 ` Damien Wyart 2006-10-25 16:25 ` Auke Kok 0 siblings, 1 reply; 152+ messages in thread From: Damien Wyart @ 2006-10-25 12:01 UTC (permalink / raw) To: Jean Delvare Cc: Auke Kok, Jeff Garzik, Linux Kernel Mailing List, Linus Torvalds, Adrian Bunk > > Auke Kok (1): > > e100: fix reboot -f with netconsole enabled * Jean Delvare <khali@linux-fr.org> [2006-10-25 13:25]: This one breaks > power-off and reboot on my laptop (thanks to git bisect for isolating > it). The shutdown freezes after "Shutdown: hda" or "Rebooting". > SysRq-p says the CPU is idle. If you need additional information on my > config or want me to do more tests, just ask. This has already been discussed, a fix has been posted (see recent netdev messages) and should be pulled soon into mainline (I guess). -- Damien Wyart ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: Linux 2.6.19-rc3 2006-10-25 12:01 ` Damien Wyart @ 2006-10-25 16:25 ` Auke Kok 2006-10-26 7:20 ` Jean Delvare 0 siblings, 1 reply; 152+ messages in thread From: Auke Kok @ 2006-10-25 16:25 UTC (permalink / raw) To: Damien Wyart Cc: Jean Delvare, Jeff Garzik, Linux Kernel Mailing List, Linus Torvalds, Adrian Bunk Damien Wyart wrote: >>> Auke Kok (1): >>> e100: fix reboot -f with netconsole enabled > > * Jean Delvare <khali@linux-fr.org> [2006-10-25 13:25]: This one breaks >> power-off and reboot on my laptop (thanks to git bisect for isolating >> it). The shutdown freezes after "Shutdown: hda" or "Rebooting". >> SysRq-p says the CPU is idle. If you need additional information on my >> config or want me to do more tests, just ask. > > This has already been discussed, a fix has been posted (see recent > netdev messages) and should be pulled soon into mainline (I guess). > for those interested, here's the fix (which is already pushed to jgarzik) Cheers, Auke diff --git a/drivers/net/e100.c b/drivers/net/e100.c index d4a2572..815eb29 100644 --- a/drivers/net/e100.c +++ b/drivers/net/e100.c @@ -2719,7 +2719,10 @@ static int e100_suspend(struct pci_dev * struct net_device *netdev = pci_get_drvdata(pdev); struct nic *nic = netdev_priv(netdev); - netif_poll_disable(nic->netdev); +#ifdef CONFIG_E100_NAPI + if (netif_running(netdev)) + netif_poll_disable(nic->netdev); +#endif del_timer_sync(&nic->watchdog); netif_carrier_off(nic->netdev); @@ -2763,7 +2766,10 @@ static void e100_shutdown(struct pci_dev struct net_device *netdev = pci_get_drvdata(pdev); struct nic *nic = netdev_priv(netdev); - netif_poll_disable(nic->netdev); +#ifdef CONFIG_E100_NAPI + if (netif_running(netdev)) + netif_poll_disable(nic->netdev); +#endif del_timer_sync(&nic->watchdog); netif_carrier_off(nic->netdev); ^ permalink raw reply related [flat|nested] 152+ messages in thread
* Re: Linux 2.6.19-rc3 2006-10-25 16:25 ` Auke Kok @ 2006-10-26 7:20 ` Jean Delvare 0 siblings, 0 replies; 152+ messages in thread From: Jean Delvare @ 2006-10-26 7:20 UTC (permalink / raw) To: Auke Kok Cc: Damien Wyart, Jeff Garzik, Linux Kernel Mailing List, Linus Torvalds, Adrian Bunk Hi Auke, On Wed, 25 Oct 2006 09:25:14 -0700, Auke Kok wrote: > Damien Wyart wrote: > > > > Auke Kok (1): > > > > e100: fix reboot -f with netconsole enabled > > > > * Jean Delvare <khali@linux-fr.org> [2006-10-25 13:25]: This one breaks > > > power-off and reboot on my laptop (thanks to git bisect for isolating > > > it). The shutdown freezes after "Shutdown: hda" or "Rebooting". > > > SysRq-p says the CPU is idle. If you need additional information on my > > > config or want me to do more tests, just ask. > > > > This has already been discussed, a fix has been posted (see recent > > netdev messages) and should be pulled soon into mainline (I guess). > > for those interested, here's the fix (which is already pushed to jgarzik) > > diff --git a/drivers/net/e100.c b/drivers/net/e100.c > index d4a2572..815eb29 100644 > --- a/drivers/net/e100.c > +++ b/drivers/net/e100.c > @@ -2719,7 +2719,10 @@ static int e100_suspend(struct pci_dev * > struct net_device *netdev = pci_get_drvdata(pdev); > struct nic *nic = netdev_priv(netdev); > > - netif_poll_disable(nic->netdev); > +#ifdef CONFIG_E100_NAPI > + if (netif_running(netdev)) > + netif_poll_disable(nic->netdev); > +#endif > del_timer_sync(&nic->watchdog); > netif_carrier_off(nic->netdev); > > @@ -2763,7 +2766,10 @@ static void e100_shutdown(struct pci_dev > struct net_device *netdev = pci_get_drvdata(pdev); > struct nic *nic = netdev_priv(netdev); > > - netif_poll_disable(nic->netdev); > +#ifdef CONFIG_E100_NAPI > + if (netif_running(netdev)) > + netif_poll_disable(nic->netdev); > +#endif > del_timer_sync(&nic->watchdog); > netif_carrier_off(nic->netdev); The patch above had some formating problems, but after fixing that I could apply it and I confirm it fixes my problem. Thanks! -- Jean Delvare ^ permalink raw reply [flat|nested] 152+ messages in thread
* Linux 2.6.19-rc3: !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB 2006-10-23 23:22 Linux 2.6.19-rc3 Linus Torvalds ` (4 preceding siblings ...) 2006-10-25 11:25 ` Linux 2.6.19-rc3 Jean Delvare @ 2006-10-25 20:13 ` Athanasius 2006-10-25 22:17 ` [PATCH] " Randy Dunlap 2006-10-26 22:45 ` Adrian Bunk 2006-10-29 23:13 ` Adrian Bunk 7 siblings, 1 reply; 152+ messages in thread From: Athanasius @ 2006-10-25 20:13 UTC (permalink / raw) To: Linus Torvalds, linux-kernel; +Cc: David Brownell, Roman Zippel [-- Attachment #1.1: Type: text/plain, Size: 6816 bytes --] 1) It's possible in Device Drivers -> Network device support to go from having both: PHY device support Ethernet (10 or 100Mbit) set, to turning off the latter option, which automatically turns off the prior option, but still being able to get into the "PHY device support" option, although the options area is blank, and trying to cursor up/down just prints a ^@ (NUL ?). If an option is disabled in this way it really needs to be clearer as to what's happened to it. 2) With both those sections off it's possible to configure in "Device Drivers -> USB Support -> USB Network Adapters" options and modules, but then not have usbnet.ko successfully build because it now tries to use mii_* symbols which aren't available, cf: make bzImage ... <completes successfully> make V=1 modules ... make -f scripts/Makefile.build obj=lib/zlib_deflate make -f scripts/Makefile.build obj=lib/zlib_inflate make -f scripts/Makefile.build obj=arch/i386/lib Building modules, stage 2. make -f /usr/local/src/kernels/linux-2.6.19-rc3/scripts/Makefile.modpost scripts/mod/modpost -m -a -o /usr/local/src/kernels/linux-2.6.19-rc3/Module.symvers vmlinux arch/i386/crypto/aes-i586.o arch/i386/crypto/twofish-i586.o crypto/aes.o crypto/anubis.o crypto/arc4.o crypto/blowfish.o crypto/cast5.o crypto/cast6.o crypto/crc32c.o crypto/crypto_null.o crypto/ecb.o crypto/khazad.o crypto/md4.o crypto/michael_mic.o crypto/serpent.o crypto/sha256.o crypto/sha512.o crypto/tcrypt.o crypto/tea.o crypto/tgr192.o crypto/twofish.o crypto/twofish_common.o crypto/wp512.o drivers/ata/ahci.o drivers/ata/sata_promise.o drivers/ata/sata_sx4.o drivers/ata/sata_via.o drivers/base/firmware_class.o drivers/block/cryptoloop.o drivers/block/loop.o drivers/block/nbd.o drivers/block/rd.o drivers/bluetooth/bcm203x.o drivers/bluetooth/bfusb.o drivers/bluetooth/bpa10x.o drivers/bluetooth/hci_uart.o drivers/bluetooth/hci_usb.o drivers/bluetooth/hci_vhci.o drivers/char/ipmi/ipmi_devintf.o drivers/char/ipmi/ipmi_msghandler.o drivers/char/ipmi/ipmi_poweroff.o drivers/char/ipmi/ipmi_si.o drivers/char/ipmi/ipmi_watchdog.o drivers/char/lp.o drivers/connector/cn.o drivers/crypto/padlock-sha.o drivers/hwmon/hwmon-vid.o drivers/hwmon/hwmon.o drivers/hwmon/k8temp.o drivers/hwmon/lm75.o drivers/hwmon/w83627hf.o drivers/i2c/busses/i2c-isa.o drivers/i2c/busses/i2c-via.o drivers/i2c/busses/i2c-viapro.o drivers/i2c/chips/eeprom.o drivers/ide/ide-cd.o drivers/ieee1394/dv1394.o drivers/ieee1394/eth1394.o drivers/ieee1394/ieee1394.o drivers/ieee1394/ohci1394.o drivers/ieee1394/raw1394.o drivers/ieee1394/sbp2.o drivers/ieee1394/video1394.o drivers/input/evbug.o drivers/input/evdev.o drivers/input/gameport/gameport.o drivers/input/gameport/ns558.o drivers/input/joydev.o drivers/input/joystick/analog.o drivers/input/joystick/joydump.o drivers/input/misc/pcspkr.o drivers/input/misc/uinput.o drivers/input/mouse/psmouse.o drivers/media/video/c-qcam.o drivers/media/video/compat_ioctl32.o drivers/media/video/v4l1-compat.o drivers/media/video/v4l2-common.o drivers/media/video/video-buf.o drivers/media/video/videodev.o drivers/media/video/vivi.o drivers/misc/tifm_7xx1.o drivers/misc/tifm_core.o drivers/mmc/mmc_block.o drivers/mmc/mmc_core.o drivers/mmc/sdhci.o drivers/mmc/tifm_sd.o drivers/mmc/wbsd.o drivers/net/bsd_comp.o drivers/net/dummy.o drivers/net/ppp_async.o drivers/net/ppp_deflate.o drivers/net/ppp_generic.o drivers/net/ppp_mppe.o drivers/net/ppp_synctty.o drivers/net/pppoe.o drivers/net/pppox.o drivers/net/sk98lin/sk98lin.o drivers/net/slhc.o drivers/net/slip.o drivers/net/tun.o drivers/parport/parport.o drivers/parport/parport_pc.o drivers/scsi/ide-scsi.o drivers/scsi/scsi_transport_fc.o drivers/scsi/scsi_transport_iscsi.o drivers/scsi/scsi_transport_sas.o drivers/scsi/scsi_transport_spi.o drivers/scsi/sd_mod.o drivers/scsi/sg.o drivers/scsi/sr_mod.o drivers/serial/8250.o drivers/serial/8250_pci.o drivers/serial/8250_pnp.o drivers/serial/serial_core.o drivers/usb/class/cdc-acm.o drivers/usb/class/usblp.o drivers/usb/host/ehci-hcd.o drivers/usb/host/uhci-hcd.o drivers/usb/input/usbhid.o drivers/usb/net/cdc_ether.o drivers/usb/net/cdc_subset.o drivers/usb/net/net1080.o drivers/usb/net/usbnet.o drivers/usb/net/zaurus.o drivers/usb/serial/aircable.o drivers/usb/serial/option.o drivers/usb/serial/usbserial.o drivers/usb/storage/usb-storage.o drivers/video/cfbcopyarea.o drivers/video/cfbfillrect.o drivers/video/cfbimgblt.o drivers/video/console/bitblit.o drivers/video/console/fbcon.o drivers/video/console/font.o drivers/video/console/softcursor.o drivers/video/console/tileblit.o drivers/video/fb.o drivers/video/nvidia/nvidiafb.o fs/autofs/autofs.o fs/autofs4/autofs4.o fs/binfmt_aout.o fs/binfmt_misc.o fs/cifs/cifs.o fs/dlm/dlm.o fs/exportfs/exportfs.o fs/minix/minix.o fs/msdos/msdos.o fs/nfsd/nfsd.o fs/nls/nls_ascii.o fs/smbfs/smbfs.o lib/crc-ccitt.o lib/crc16.o lib/crc32.o lib/libcrc32c.o net/bluetooth/bluetooth.o net/bluetooth/bnep/bnep.o net/bluetooth/hidp/hidp.o net/bluetooth/l2cap.o net/bluetooth/rfcomm/rfcomm.o net/bluetooth/sco.o net/core/pktgen.o net/dccp/ccids/dccp_ccid2.o net/dccp/ccids/dccp_ccid3.o net/dccp/ccids/lib/dccp_tfrc_lib.o net/dccp/dccp.o net/dccp/dccp_diag.o net/dccp/dccp_ipv4.o net/ipv6/ip6_tunnel.o net/ipv6/netfilter/ip6_queue.o net/key/af_key.o net/sched/sch_netem.o net/sctp/sctp.o net/sunrpc/auth_gss/rpcsec_gss_spkm3.o sound/core/oss/snd-mixer-oss.o sound/core/oss/snd-pcm-oss.o sound/core/seq/oss/snd-seq-oss.o sound/core/seq/snd-seq-device.o sound/core/seq/snd-seq-dummy.o sound/core/seq/snd-seq-midi-event.o sound/core/seq/snd-seq-midi.o sound/core/seq/snd-seq-virmidi.o sound/core/seq/snd-seq.o sound/core/snd-page-alloc.o sound/core/snd-pcm.o sound/core/snd-rawmidi.o sound/core/snd-rtctimer.o sound/core/snd-timer.o sound/core/snd.o sound/drivers/mpu401/snd-mpu401-uart.o sound/drivers/mpu401/snd-mpu401.o sound/drivers/snd-dummy.o sound/drivers/snd-serial-u16550.o sound/drivers/snd-virmidi.o sound/pci/ac97/snd-ac97-bus.o sound/pci/ac97/snd-ac97-codec.o sound/pci/snd-via82xx-modem.o sound/pci/snd-via82xx.o sound/soundcore.o WARNING: "mii_ethtool_gset" [drivers/usb/net/usbnet.ko] undefined! WARNING: "mii_nway_restart" [drivers/usb/net/usbnet.ko] undefined! WARNING: "mii_link_ok" [drivers/usb/net/usbnet.ko] undefined! WARNING: "mii_ethtool_sset" [drivers/usb/net/usbnet.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 My example .config is attached. This worked fine with 2.6.19-rc2 before usbnet started referencing mii_* symbols. -Ath -- - Athanasius = Athanasius(at)miggy.org / http://www.miggy.org/ Finger athan(at)fysh.org for PGP key "And it's me who is my enemy. Me who beats me up. Me who makes the monsters. Me who strips my confidence." Paula Cole - ME [-- Attachment #1.2: emelia-2.6.19-rc3 --] [-- Type: text/plain, Size: 52677 bytes --] # # Automatically generated make config: don't edit # Linux kernel version: 2.6.19-rc3 # Wed Oct 25 20:57:36 2006 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y # CONFIG_UTS_NS is not set CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_RELAY=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_TASK_XACCT=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y # CONFIG_LBD is not set CONFIG_BLK_DEV_IO_TRACE=y CONFIG_LSF=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set CONFIG_MK8=y # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y # CONFIG_X86_MCE_P4THERMAL is not set CONFIG_VM86=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set CONFIG_X86_REBOOTFIXUPS=y # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y CONFIG_X86_CPUID=y # # Firmware Drivers # CONFIG_EDD=y # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_PAGE_OFFSET=0xC0000000 CONFIG_HIGHMEM=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_SPARSEMEM_STATIC=y CONFIG_SPLIT_PTLOCK_CPUS=4 # CONFIG_RESOURCES_64BIT is not set # CONFIG_HIGHPTE is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_REGPARM=y CONFIG_SECCOMP=y # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set CONFIG_HZ_1000=y CONFIG_HZ=1000 # CONFIG_KEXEC is not set # CONFIG_CRASH_DUMP is not set CONFIG_PHYSICAL_START=0x100000 # CONFIG_COMPAT_VDSO is not set CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y # # Power management options (ACPI, APM) # CONFIG_PM=y CONFIG_PM_LEGACY=y # CONFIG_PM_DEBUG is not set # CONFIG_PM_SYSFS_DEPRECATED is not set # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y # CONFIG_ACPI_SLEEP is not set # CONFIG_ACPI_AC is not set # CONFIG_ACPI_BATTERY is not set # CONFIG_ACPI_BUTTON is not set CONFIG_ACPI_VIDEO=y # CONFIG_ACPI_HOTKEY is not set CONFIG_ACPI_FAN=y # CONFIG_ACPI_DOCK is not set CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_IBM is not set # CONFIG_ACPI_TOSHIBA is not set # CONFIG_ACPI_CUSTOM_DSDT is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y # CONFIG_ACPI_CONTAINER is not set # CONFIG_ACPI_SBS is not set # # APM (Advanced Power Management) BIOS Support # # CONFIG_APM is not set # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y # CONFIG_CPU_FREQ_DEBUG is not set CONFIG_CPU_FREQ_STAT=y CONFIG_CPU_FREQ_STAT_DETAILS=y # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=y CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y # # CPUFreq processor drivers # # CONFIG_X86_ACPI_CPUFREQ is not set # CONFIG_X86_POWERNOW_K6 is not set # CONFIG_X86_POWERNOW_K7 is not set CONFIG_X86_POWERNOW_K8=y CONFIG_X86_POWERNOW_K8_ACPI=y # CONFIG_X86_GX_SUSPMOD is not set # CONFIG_X86_SPEEDSTEP_CENTRINO is not set # CONFIG_X86_SPEEDSTEP_ICH is not set # CONFIG_X86_SPEEDSTEP_SMI is not set # CONFIG_X86_P4_CLOCKMOD is not set # CONFIG_X86_CPUFREQ_NFORCE2 is not set # CONFIG_X86_LONGRUN is not set # CONFIG_X86_LONGHAUL is not set # # shared options # CONFIG_X86_ACPI_CPUFREQ_PROC_INTF=y # CONFIG_X86_SPEEDSTEP_LIB is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y # CONFIG_PCIEPORTBUS is not set # CONFIG_PCI_MSI is not set # CONFIG_PCI_MULTITHREAD_PROBE is not set # CONFIG_PCI_DEBUG is not set CONFIG_HT_IRQ=y CONFIG_ISA_DMA_API=y CONFIG_ISA=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set # # PCCARD (PCMCIA/CardBus) support # # CONFIG_PCCARD is not set # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # # Executable file formats # CONFIG_BINFMT_ELF=y CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_MISC=m # # Networking # CONFIG_NET=y # # Networking options # # CONFIG_NETDEBUG is not set CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_XFRM=y CONFIG_XFRM_USER=y CONFIG_XFRM_SUB_POLICY=y CONFIG_NET_KEY=m CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set CONFIG_IP_FIB_HASH=y # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=y CONFIG_NET_IPGRE=y # CONFIG_ARPD is not set CONFIG_SYN_COOKIES=y CONFIG_INET_AH=y CONFIG_INET_ESP=y CONFIG_INET_IPCOMP=y CONFIG_INET_XFRM_TUNNEL=y CONFIG_INET_TUNNEL=y CONFIG_INET_XFRM_MODE_TRANSPORT=y CONFIG_INET_XFRM_MODE_TUNNEL=y CONFIG_INET_XFRM_MODE_BEET=y CONFIG_INET_DIAG=y CONFIG_INET_TCP_DIAG=y # CONFIG_TCP_CONG_ADVANCED is not set CONFIG_TCP_CONG_CUBIC=y CONFIG_DEFAULT_TCP_CONG="cubic" # # IP: Virtual Server Configuration # # CONFIG_IP_VS is not set CONFIG_IPV6=y CONFIG_IPV6_PRIVACY=y CONFIG_IPV6_ROUTER_PREF=y CONFIG_IPV6_ROUTE_INFO=y CONFIG_INET6_AH=y CONFIG_INET6_ESP=y CONFIG_INET6_IPCOMP=y CONFIG_IPV6_MIP6=y CONFIG_INET6_XFRM_TUNNEL=y CONFIG_INET6_TUNNEL=y CONFIG_INET6_XFRM_MODE_TRANSPORT=y CONFIG_INET6_XFRM_MODE_TUNNEL=y CONFIG_INET6_XFRM_MODE_BEET=y CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=y CONFIG_IPV6_SIT=y CONFIG_IPV6_TUNNEL=m CONFIG_IPV6_MULTIPLE_TABLES=y # CONFIG_IPV6_SUBTREES is not set CONFIG_IPV6_ROUTE_FWMARK=y CONFIG_NETWORK_SECMARK=y CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set # # Core Netfilter Configuration # CONFIG_NETFILTER_NETLINK=y CONFIG_NETFILTER_NETLINK_QUEUE=y CONFIG_NETFILTER_NETLINK_LOG=y CONFIG_NETFILTER_XTABLES=y CONFIG_NETFILTER_XT_TARGET_CLASSIFY=y CONFIG_NETFILTER_XT_TARGET_CONNMARK=y CONFIG_NETFILTER_XT_TARGET_DSCP=y CONFIG_NETFILTER_XT_TARGET_MARK=y CONFIG_NETFILTER_XT_TARGET_NFQUEUE=y CONFIG_NETFILTER_XT_TARGET_NOTRACK=y CONFIG_NETFILTER_XT_TARGET_SECMARK=y CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=y CONFIG_NETFILTER_XT_MATCH_COMMENT=y CONFIG_NETFILTER_XT_MATCH_CONNBYTES=y CONFIG_NETFILTER_XT_MATCH_CONNMARK=y CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y CONFIG_NETFILTER_XT_MATCH_DCCP=y CONFIG_NETFILTER_XT_MATCH_DSCP=y CONFIG_NETFILTER_XT_MATCH_ESP=y CONFIG_NETFILTER_XT_MATCH_HELPER=y CONFIG_NETFILTER_XT_MATCH_LENGTH=y CONFIG_NETFILTER_XT_MATCH_LIMIT=y CONFIG_NETFILTER_XT_MATCH_MAC=y CONFIG_NETFILTER_XT_MATCH_MARK=y CONFIG_NETFILTER_XT_MATCH_POLICY=y CONFIG_NETFILTER_XT_MATCH_MULTIPORT=y CONFIG_NETFILTER_XT_MATCH_PKTTYPE=y CONFIG_NETFILTER_XT_MATCH_QUOTA=y CONFIG_NETFILTER_XT_MATCH_REALM=y CONFIG_NETFILTER_XT_MATCH_SCTP=y CONFIG_NETFILTER_XT_MATCH_STATE=y CONFIG_NETFILTER_XT_MATCH_STATISTIC=y CONFIG_NETFILTER_XT_MATCH_STRING=y CONFIG_NETFILTER_XT_MATCH_TCPMSS=y # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=y CONFIG_IP_NF_CT_ACCT=y CONFIG_IP_NF_CONNTRACK_MARK=y CONFIG_IP_NF_CONNTRACK_SECMARK=y CONFIG_IP_NF_CONNTRACK_EVENTS=y CONFIG_IP_NF_CONNTRACK_NETLINK=y CONFIG_IP_NF_CT_PROTO_SCTP=y CONFIG_IP_NF_FTP=y CONFIG_IP_NF_IRC=y CONFIG_IP_NF_NETBIOS_NS=y CONFIG_IP_NF_TFTP=y CONFIG_IP_NF_AMANDA=y CONFIG_IP_NF_PPTP=y CONFIG_IP_NF_H323=y CONFIG_IP_NF_SIP=y CONFIG_IP_NF_QUEUE=y CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_MATCH_IPRANGE=y CONFIG_IP_NF_MATCH_TOS=y CONFIG_IP_NF_MATCH_RECENT=y CONFIG_IP_NF_MATCH_ECN=y CONFIG_IP_NF_MATCH_AH=y CONFIG_IP_NF_MATCH_TTL=y CONFIG_IP_NF_MATCH_OWNER=y CONFIG_IP_NF_MATCH_ADDRTYPE=y CONFIG_IP_NF_MATCH_HASHLIMIT=y CONFIG_IP_NF_FILTER=y CONFIG_IP_NF_TARGET_REJECT=y CONFIG_IP_NF_TARGET_LOG=y CONFIG_IP_NF_TARGET_ULOG=y CONFIG_IP_NF_TARGET_TCPMSS=y CONFIG_IP_NF_NAT=y CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=y CONFIG_IP_NF_TARGET_REDIRECT=y CONFIG_IP_NF_TARGET_NETMAP=y CONFIG_IP_NF_TARGET_SAME=y CONFIG_IP_NF_NAT_SNMP_BASIC=y CONFIG_IP_NF_NAT_IRC=y CONFIG_IP_NF_NAT_FTP=y CONFIG_IP_NF_NAT_TFTP=y CONFIG_IP_NF_NAT_AMANDA=y CONFIG_IP_NF_NAT_PPTP=y CONFIG_IP_NF_NAT_H323=y CONFIG_IP_NF_NAT_SIP=y CONFIG_IP_NF_MANGLE=y CONFIG_IP_NF_TARGET_TOS=y CONFIG_IP_NF_TARGET_ECN=y CONFIG_IP_NF_TARGET_TTL=y CONFIG_IP_NF_TARGET_CLUSTERIP=y CONFIG_IP_NF_RAW=y CONFIG_IP_NF_ARPTABLES=y CONFIG_IP_NF_ARPFILTER=y CONFIG_IP_NF_ARP_MANGLE=y # # IPv6: Netfilter Configuration (EXPERIMENTAL) # CONFIG_IP6_NF_QUEUE=m CONFIG_IP6_NF_IPTABLES=y CONFIG_IP6_NF_MATCH_RT=y CONFIG_IP6_NF_MATCH_OPTS=y CONFIG_IP6_NF_MATCH_FRAG=y CONFIG_IP6_NF_MATCH_HL=y CONFIG_IP6_NF_MATCH_OWNER=y CONFIG_IP6_NF_MATCH_IPV6HEADER=y CONFIG_IP6_NF_MATCH_AH=y CONFIG_IP6_NF_MATCH_EUI64=y CONFIG_IP6_NF_FILTER=y CONFIG_IP6_NF_TARGET_LOG=y CONFIG_IP6_NF_TARGET_REJECT=y CONFIG_IP6_NF_MANGLE=y CONFIG_IP6_NF_TARGET_HL=y CONFIG_IP6_NF_RAW=y # # DCCP Configuration (EXPERIMENTAL) # CONFIG_IP_DCCP=m CONFIG_INET_DCCP_DIAG=m CONFIG_IP_DCCP_ACKVEC=y # # DCCP CCIDs Configuration (EXPERIMENTAL) # CONFIG_IP_DCCP_CCID2=m # CONFIG_IP_DCCP_CCID2_DEBUG is not set CONFIG_IP_DCCP_CCID3=m CONFIG_IP_DCCP_TFRC_LIB=m # # DCCP Kernel Hacking # # CONFIG_IP_DCCP_DEBUG is not set # # SCTP Configuration (EXPERIMENTAL) # CONFIG_IP_SCTP=m CONFIG_SCTP_DBG_MSG=y CONFIG_SCTP_DBG_OBJCNT=y # CONFIG_SCTP_HMAC_NONE is not set CONFIG_SCTP_HMAC_SHA1=y # CONFIG_SCTP_HMAC_MD5 is not set # # TIPC Configuration (EXPERIMENTAL) # # CONFIG_TIPC is not set # CONFIG_ATM is not set # CONFIG_BRIDGE is not set # CONFIG_VLAN_8021Q is not set # CONFIG_DECNET is not set # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # # QoS and/or fair queueing # CONFIG_NET_SCHED=y CONFIG_NET_SCH_CLK_JIFFIES=y # CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set # CONFIG_NET_SCH_CLK_CPU is not set # # Queueing/Scheduling # CONFIG_NET_SCH_CBQ=y CONFIG_NET_SCH_HTB=y CONFIG_NET_SCH_HFSC=y CONFIG_NET_SCH_PRIO=y CONFIG_NET_SCH_RED=y CONFIG_NET_SCH_SFQ=y CONFIG_NET_SCH_TEQL=y CONFIG_NET_SCH_TBF=y CONFIG_NET_SCH_GRED=y CONFIG_NET_SCH_DSMARK=y CONFIG_NET_SCH_NETEM=m CONFIG_NET_SCH_INGRESS=y # # Classification # CONFIG_NET_CLS=y CONFIG_NET_CLS_BASIC=y CONFIG_NET_CLS_TCINDEX=y CONFIG_NET_CLS_ROUTE4=y CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=y CONFIG_NET_CLS_U32=y CONFIG_CLS_U32_PERF=y CONFIG_CLS_U32_MARK=y CONFIG_NET_CLS_RSVP=y CONFIG_NET_CLS_RSVP6=y CONFIG_NET_EMATCH=y CONFIG_NET_EMATCH_STACK=32 CONFIG_NET_EMATCH_CMP=y CONFIG_NET_EMATCH_NBYTE=y CONFIG_NET_EMATCH_U32=y CONFIG_NET_EMATCH_META=y CONFIG_NET_EMATCH_TEXT=y CONFIG_NET_CLS_ACT=y CONFIG_NET_ACT_POLICE=y CONFIG_NET_ACT_GACT=y CONFIG_GACT_PROB=y CONFIG_NET_ACT_MIRRED=y CONFIG_NET_ACT_IPT=y CONFIG_NET_ACT_PEDIT=y CONFIG_NET_ACT_SIMP=y CONFIG_NET_CLS_IND=y CONFIG_NET_ESTIMATOR=y # # Network testing # CONFIG_NET_PKTGEN=m # CONFIG_HAMRADIO is not set # CONFIG_IRDA is not set CONFIG_BT=m CONFIG_BT_L2CAP=m CONFIG_BT_SCO=m CONFIG_BT_RFCOMM=m CONFIG_BT_RFCOMM_TTY=y CONFIG_BT_BNEP=m CONFIG_BT_BNEP_MC_FILTER=y CONFIG_BT_BNEP_PROTO_FILTER=y CONFIG_BT_HIDP=m # # Bluetooth device drivers # CONFIG_BT_HCIUSB=m CONFIG_BT_HCIUSB_SCO=y CONFIG_BT_HCIUART=m CONFIG_BT_HCIUART_H4=y CONFIG_BT_HCIUART_BCSP=y CONFIG_BT_HCIBCM203X=m CONFIG_BT_HCIBPA10X=m CONFIG_BT_HCIBFUSB=m CONFIG_BT_HCIVHCI=m # CONFIG_IEEE80211 is not set CONFIG_FIB_RULES=y # # Device Drivers # # # Generic Driver Options # # CONFIG_STANDALONE is not set CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=m # CONFIG_DEBUG_DRIVER is not set # CONFIG_SYS_HYPERVISOR is not set # # Connector - unified userspace <-> kernelspace linker # CONFIG_CONNECTOR=m # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m # CONFIG_PARPORT_SERIAL is not set CONFIG_PARPORT_PC_FIFO=y # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_GSC is not set # CONFIG_PARPORT_AX88796 is not set # CONFIG_PARPORT_1284 is not set # # Plug and Play support # CONFIG_PNP=y # CONFIG_PNP_DEBUG is not set # # Protocols # CONFIG_ISAPNP=y # CONFIG_PNPBIOS is not set CONFIG_PNPACPI=y # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_NBD=m # CONFIG_BLK_DEV_SX8 is not set # CONFIG_BLK_DEV_UB is not set CONFIG_BLK_DEV_RAM=m CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024 CONFIG_BLK_DEV_INITRD=y CONFIG_CDROM_PKTCDVD=y CONFIG_CDROM_PKTCDVD_BUFFERS=8 # CONFIG_CDROM_PKTCDVD_WCACHE is not set # CONFIG_ATA_OVER_ETH is not set # # Misc devices # # CONFIG_IBM_ASM is not set # CONFIG_SGI_IOC4 is not set CONFIG_TIFM_CORE=m CONFIG_TIFM_7XX1=m # # ATA/ATAPI/MFM/RLL support # CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_IDE_SATA is not set # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y # CONFIG_IDEDISK_MULTI_MODE is not set CONFIG_BLK_DEV_IDECD=m # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set CONFIG_BLK_DEV_IDESCSI=m # CONFIG_IDE_TASK_IOCTL is not set # # IDE chipset support/bugfixes # CONFIG_IDE_GENERIC=y # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_BLK_DEV_IDEPNP is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y # CONFIG_BLK_DEV_OFFBOARD is not set # CONFIG_BLK_DEV_GENERIC is not set # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y CONFIG_IDEDMA_ONLYDISK=y # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_BLK_DEV_ATIIXP is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_TRIFLEX is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5520 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_CS5535 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_BLK_DEV_HPT366 is not set # CONFIG_BLK_DEV_JMICRON is not set # CONFIG_BLK_DEV_SC1200 is not set # CONFIG_BLK_DEV_PIIX is not set # CONFIG_BLK_DEV_IT821X is not set # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_PDC202XX_OLD is not set # CONFIG_BLK_DEV_PDC202XX_NEW is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set CONFIG_BLK_DEV_VIA82CXXX=y # CONFIG_IDE_ARM is not set # CONFIG_IDE_CHIPSETS is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_IVB is not set CONFIG_IDEDMA_AUTO=y # CONFIG_BLK_DEV_HD is not set # # SCSI device support # # CONFIG_RAID_ATTRS is not set CONFIG_SCSI=y CONFIG_SCSI_NETLINK=y CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=m # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=m # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_CHR_DEV_SG=m # CONFIG_CHR_DEV_SCH is not set # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y # # SCSI Transports # CONFIG_SCSI_SPI_ATTRS=m CONFIG_SCSI_FC_ATTRS=m CONFIG_SCSI_ISCSI_ATTRS=m CONFIG_SCSI_SAS_ATTRS=m # CONFIG_SCSI_SAS_LIBSAS is not set # # SCSI low-level drivers # # CONFIG_ISCSI_TCP is not set # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_3W_9XXX is not set # CONFIG_SCSI_7000FASST is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AHA152X is not set # CONFIG_SCSI_AHA1542 is not set # CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_AIC94XX is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_IN2000 is not set # CONFIG_SCSI_ARCMSR is not set # CONFIG_MEGARAID_NEWGEN is not set # CONFIG_MEGARAID_LEGACY is not set # CONFIG_MEGARAID_SAS is not set # CONFIG_SCSI_HPTIOP is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_DTC3280 is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_GENERIC_NCR5380 is not set # CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set # CONFIG_SCSI_NCR53C406A is not set # CONFIG_SCSI_STEX is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_IPR is not set # CONFIG_SCSI_PAS16 is not set # CONFIG_SCSI_PSI240I is not set # CONFIG_SCSI_QLOGIC_FAS is not set # CONFIG_SCSI_QLOGIC_1280 is not set # CONFIG_SCSI_QLA_FC is not set # CONFIG_SCSI_QLA_ISCSI is not set # CONFIG_SCSI_LPFC is not set # CONFIG_SCSI_SYM53C416 is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_T128 is not set # CONFIG_SCSI_U14_34F is not set # CONFIG_SCSI_ULTRASTOR is not set # CONFIG_SCSI_NSP32 is not set # CONFIG_SCSI_DEBUG is not set # # Serial ATA (prod) and Parallel ATA (experimental) drivers # CONFIG_ATA=y CONFIG_SATA_AHCI=m # CONFIG_SATA_SVW is not set # CONFIG_ATA_PIIX is not set # CONFIG_SATA_MV is not set # CONFIG_SATA_NV is not set # CONFIG_PDC_ADMA is not set # CONFIG_SATA_QSTOR is not set CONFIG_SATA_PROMISE=m CONFIG_SATA_SX4=m # CONFIG_SATA_SIL is not set # CONFIG_SATA_SIL24 is not set # CONFIG_SATA_SIS is not set # CONFIG_SATA_ULI is not set CONFIG_SATA_VIA=m # CONFIG_SATA_VITESSE is not set CONFIG_SATA_INTEL_COMBINED=y # CONFIG_PATA_ALI is not set # CONFIG_PATA_AMD is not set # CONFIG_PATA_ARTOP is not set # CONFIG_PATA_ATIIXP is not set # CONFIG_PATA_CMD64X is not set # CONFIG_PATA_CS5520 is not set # CONFIG_PATA_CS5530 is not set # CONFIG_PATA_CS5535 is not set # CONFIG_PATA_CYPRESS is not set # CONFIG_PATA_EFAR is not set CONFIG_ATA_GENERIC=y # CONFIG_PATA_HPT366 is not set # CONFIG_PATA_HPT37X is not set # CONFIG_PATA_HPT3X2N is not set # CONFIG_PATA_HPT3X3 is not set # CONFIG_PATA_ISAPNP is not set # CONFIG_PATA_IT821X is not set # CONFIG_PATA_JMICRON is not set # CONFIG_PATA_LEGACY is not set # CONFIG_PATA_TRIFLEX is not set # CONFIG_PATA_MPIIX is not set # CONFIG_PATA_OLDPIIX is not set # CONFIG_PATA_NETCELL is not set # CONFIG_PATA_NS87410 is not set # CONFIG_PATA_OPTI is not set # CONFIG_PATA_OPTIDMA is not set # CONFIG_PATA_PDC_OLD is not set # CONFIG_PATA_QDI is not set # CONFIG_PATA_RADISYS is not set # CONFIG_PATA_RZ1000 is not set # CONFIG_PATA_SC1200 is not set # CONFIG_PATA_SERVERWORKS is not set # CONFIG_PATA_PDC2027X is not set # CONFIG_PATA_SIL680 is not set # CONFIG_PATA_SIS is not set CONFIG_PATA_VIA=y # CONFIG_PATA_WINBOND is not set # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # CONFIG_FUSION_SPI is not set # CONFIG_FUSION_FC is not set # CONFIG_FUSION_SAS is not set # # IEEE 1394 (FireWire) support # CONFIG_IEEE1394=m # # Subsystem Options # # CONFIG_IEEE1394_VERBOSEDEBUG is not set CONFIG_IEEE1394_OUI_DB=y CONFIG_IEEE1394_EXTRA_CONFIG_ROMS=y CONFIG_IEEE1394_CONFIG_ROM_IP1394=y # CONFIG_IEEE1394_EXPORT_FULL_API is not set # # Device Drivers # # CONFIG_IEEE1394_PCILYNX is not set CONFIG_IEEE1394_OHCI1394=m # # Protocol Drivers # CONFIG_IEEE1394_VIDEO1394=m CONFIG_IEEE1394_SBP2=m # CONFIG_IEEE1394_SBP2_PHYS_DMA is not set CONFIG_IEEE1394_ETH1394=m CONFIG_IEEE1394_DV1394=m CONFIG_IEEE1394_RAWIO=m # # I2O device support # # CONFIG_I2O is not set # # Network device support # CONFIG_NETDEVICES=y # CONFIG_IFB is not set CONFIG_DUMMY=m # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set CONFIG_TUN=m # CONFIG_NET_SB1000 is not set # # ARCnet devices # # CONFIG_ARCNET is not set # # PHY device support # # # Ethernet (10 or 100Mbit) # # CONFIG_NET_ETHERNET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set # CONFIG_SIS190 is not set # CONFIG_SKGE is not set # CONFIG_SKY2 is not set CONFIG_SK98LIN=m # CONFIG_TIGON3 is not set # CONFIG_BNX2 is not set # CONFIG_QLA3XXX is not set # # Ethernet (10000 Mbit) # # CONFIG_CHELSIO_T1 is not set # CONFIG_IXGB is not set # CONFIG_S2IO is not set # CONFIG_MYRI10GE is not set # # Token Ring devices # # CONFIG_TR is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Wan interfaces # # CONFIG_WAN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set CONFIG_PPP=m # CONFIG_PPP_MULTILINK is not set # CONFIG_PPP_FILTER is not set CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m CONFIG_PPP_MPPE=m CONFIG_PPPOE=m CONFIG_SLIP=m CONFIG_SLIP_COMPRESSED=y CONFIG_SLHC=m CONFIG_SLIP_SMART=y CONFIG_SLIP_MODE_SLIP6=y # CONFIG_NET_FC is not set # CONFIG_SHAPER is not set CONFIG_NETCONSOLE=y CONFIG_NETPOLL=y CONFIG_NETPOLL_RX=y CONFIG_NETPOLL_TRAP=y CONFIG_NET_POLL_CONTROLLER=y # # ISDN subsystem # # CONFIG_ISDN is not set # # Telephony Support # # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # CONFIG_INPUT_FF_MEMLESS is not set # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1280 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=1024 CONFIG_INPUT_JOYDEV=m # CONFIG_INPUT_TSDEV is not set CONFIG_INPUT_EVDEV=m CONFIG_INPUT_EVBUG=m # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set # CONFIG_KEYBOARD_STOWAWAY is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=m # CONFIG_MOUSE_SERIAL is not set # CONFIG_MOUSE_INPORT is not set # CONFIG_MOUSE_LOGIBM is not set # CONFIG_MOUSE_PC110PAD is not set # CONFIG_MOUSE_VSXXXAA is not set CONFIG_INPUT_JOYSTICK=y CONFIG_JOYSTICK_ANALOG=m # CONFIG_JOYSTICK_A3D is not set # CONFIG_JOYSTICK_ADI is not set # CONFIG_JOYSTICK_COBRA is not set # CONFIG_JOYSTICK_GF2K is not set # CONFIG_JOYSTICK_GRIP is not set # CONFIG_JOYSTICK_GRIP_MP is not set # CONFIG_JOYSTICK_GUILLEMOT is not set # CONFIG_JOYSTICK_INTERACT is not set # CONFIG_JOYSTICK_SIDEWINDER is not set # CONFIG_JOYSTICK_TMDC is not set # CONFIG_JOYSTICK_IFORCE is not set # CONFIG_JOYSTICK_WARRIOR is not set # CONFIG_JOYSTICK_MAGELLAN is not set # CONFIG_JOYSTICK_SPACEORB is not set # CONFIG_JOYSTICK_SPACEBALL is not set # CONFIG_JOYSTICK_STINGER is not set # CONFIG_JOYSTICK_TWIDJOY is not set # CONFIG_JOYSTICK_DB9 is not set # CONFIG_JOYSTICK_GAMECON is not set # CONFIG_JOYSTICK_TURBOGRAFX is not set CONFIG_JOYSTICK_JOYDUMP=m # CONFIG_INPUT_TOUCHSCREEN is not set CONFIG_INPUT_MISC=y CONFIG_INPUT_PCSPKR=m # CONFIG_INPUT_WISTRON_BTNS is not set CONFIG_INPUT_UINPUT=m # # Hardware I/O ports # CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=y # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PARKBD is not set # CONFIG_SERIO_PCIPS2 is not set CONFIG_SERIO_LIBPS2=y # CONFIG_SERIO_RAW is not set CONFIG_GAMEPORT=m CONFIG_GAMEPORT_NS558=m # CONFIG_GAMEPORT_L4 is not set # CONFIG_GAMEPORT_EMU10K1 is not set # CONFIG_GAMEPORT_FM801 is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y CONFIG_VT_HW_CONSOLE_BINDING=y # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # CONFIG_SERIAL_8250=m CONFIG_SERIAL_8250_PCI=m CONFIG_SERIAL_8250_PNP=m CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y # CONFIG_SERIAL_8250_MANY_PORTS is not set CONFIG_SERIAL_8250_SHARE_IRQ=y # CONFIG_SERIAL_8250_DETECT_IRQ is not set # CONFIG_SERIAL_8250_RSA is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=m # CONFIG_SERIAL_JSM is not set CONFIG_UNIX98_PTYS=y # CONFIG_LEGACY_PTYS is not set CONFIG_PRINTER=m # CONFIG_LP_CONSOLE is not set # CONFIG_PPDEV is not set # CONFIG_TIPAR is not set # # IPMI # CONFIG_IPMI_HANDLER=m # CONFIG_IPMI_PANIC_EVENT is not set CONFIG_IPMI_DEVICE_INTERFACE=m CONFIG_IPMI_SI=m CONFIG_IPMI_WATCHDOG=m CONFIG_IPMI_POWEROFF=m # # Watchdog Cards # CONFIG_WATCHDOG=y # CONFIG_WATCHDOG_NOWAYOUT is not set # # Watchdog Device Drivers # CONFIG_SOFT_WATCHDOG=y # CONFIG_ACQUIRE_WDT is not set # CONFIG_ADVANTECH_WDT is not set # CONFIG_ALIM1535_WDT is not set # CONFIG_ALIM7101_WDT is not set # CONFIG_SC520_WDT is not set # CONFIG_EUROTECH_WDT is not set # CONFIG_IB700_WDT is not set # CONFIG_IBMASR is not set # CONFIG_WAFER_WDT is not set # CONFIG_I6300ESB_WDT is not set # CONFIG_I8XX_TCO is not set # CONFIG_ITCO_WDT is not set # CONFIG_SC1200_WDT is not set # CONFIG_60XX_WDT is not set # CONFIG_SBC8360_WDT is not set # CONFIG_CPU5_WDT is not set # CONFIG_SMSC37B787_WDT is not set # CONFIG_W83627HF_WDT is not set # CONFIG_W83697HF_WDT is not set # CONFIG_W83877F_WDT is not set # CONFIG_W83977F_WDT is not set # CONFIG_MACHZ_WDT is not set # CONFIG_SBC_EPX_C3_WATCHDOG is not set # # ISA-based Watchdog Cards # # CONFIG_PCWATCHDOG is not set # CONFIG_MIXCOMWD is not set # CONFIG_WDT is not set # # PCI-based Watchdog Cards # # CONFIG_PCIPCWATCHDOG is not set # CONFIG_WDTPCI is not set # # USB-based Watchdog Cards # # CONFIG_USBPCWATCHDOG is not set # CONFIG_HW_RANDOM is not set CONFIG_NVRAM=y CONFIG_RTC=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set CONFIG_AGP=y # CONFIG_AGP_ALI is not set # CONFIG_AGP_ATI is not set # CONFIG_AGP_AMD is not set # CONFIG_AGP_AMD64 is not set # CONFIG_AGP_INTEL is not set # CONFIG_AGP_NVIDIA is not set # CONFIG_AGP_SIS is not set # CONFIG_AGP_SWORKS is not set CONFIG_AGP_VIA=y # CONFIG_AGP_EFFICEON is not set CONFIG_DRM=y # CONFIG_DRM_TDFX is not set # CONFIG_DRM_R128 is not set # CONFIG_DRM_RADEON is not set # CONFIG_DRM_MGA is not set # CONFIG_DRM_SIS is not set # CONFIG_DRM_VIA is not set # CONFIG_DRM_SAVAGE is not set # CONFIG_MWAVE is not set # CONFIG_PC8736x_GPIO is not set # CONFIG_NSC_GPIO is not set # CONFIG_CS5535_GPIO is not set # CONFIG_RAW_DRIVER is not set CONFIG_HPET=y # CONFIG_HPET_RTC_IRQ is not set CONFIG_HPET_MMAP=y CONFIG_HANGCHECK_TIMER=y # # TPM devices # # CONFIG_TCG_TPM is not set # CONFIG_TELCLOCK is not set # # I2C support # CONFIG_I2C=y CONFIG_I2C_CHARDEV=y # # I2C Algorithms # CONFIG_I2C_ALGOBIT=y CONFIG_I2C_ALGOPCF=y CONFIG_I2C_ALGOPCA=y # # I2C Hardware Bus support # # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI1563 is not set # CONFIG_I2C_ALI15X3 is not set # CONFIG_I2C_AMD756 is not set # CONFIG_I2C_AMD8111 is not set # CONFIG_I2C_ELEKTOR is not set # CONFIG_I2C_I801 is not set # CONFIG_I2C_I810 is not set # CONFIG_I2C_PIIX4 is not set CONFIG_I2C_ISA=m # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_OCORES is not set # CONFIG_I2C_PARPORT is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_PROSAVAGE is not set # CONFIG_I2C_SAVAGE4 is not set # CONFIG_SCx200_ACB is not set # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_SIS630 is not set # CONFIG_I2C_SIS96X is not set # CONFIG_I2C_STUB is not set CONFIG_I2C_VIA=m CONFIG_I2C_VIAPRO=m # CONFIG_I2C_VOODOO3 is not set # CONFIG_I2C_PCA_ISA is not set # # Miscellaneous I2C Chip support # # CONFIG_SENSORS_DS1337 is not set # CONFIG_SENSORS_DS1374 is not set CONFIG_SENSORS_EEPROM=m # CONFIG_SENSORS_PCF8574 is not set # CONFIG_SENSORS_PCA9539 is not set # CONFIG_SENSORS_PCF8591 is not set # CONFIG_SENSORS_MAX6875 is not set CONFIG_I2C_DEBUG_CORE=y CONFIG_I2C_DEBUG_ALGO=y CONFIG_I2C_DEBUG_BUS=y CONFIG_I2C_DEBUG_CHIP=y # # SPI support # CONFIG_SPI=y # CONFIG_SPI_DEBUG is not set CONFIG_SPI_MASTER=y # # SPI Master Controller Drivers # # CONFIG_SPI_BITBANG is not set # CONFIG_SPI_BUTTERFLY is not set # # SPI Protocol Masters # # # Dallas's 1-wire bus # # CONFIG_W1 is not set # # Hardware Monitoring support # CONFIG_HWMON=m CONFIG_HWMON_VID=m # CONFIG_SENSORS_ABITUGURU is not set # CONFIG_SENSORS_ADM1021 is not set # CONFIG_SENSORS_ADM1025 is not set # CONFIG_SENSORS_ADM1026 is not set # CONFIG_SENSORS_ADM1031 is not set # CONFIG_SENSORS_ADM9240 is not set CONFIG_SENSORS_K8TEMP=m # CONFIG_SENSORS_ASB100 is not set # CONFIG_SENSORS_ATXP1 is not set # CONFIG_SENSORS_DS1621 is not set # CONFIG_SENSORS_F71805F is not set # CONFIG_SENSORS_FSCHER is not set # CONFIG_SENSORS_FSCPOS is not set # CONFIG_SENSORS_GL518SM is not set # CONFIG_SENSORS_GL520SM is not set # CONFIG_SENSORS_IT87 is not set # CONFIG_SENSORS_LM63 is not set # CONFIG_SENSORS_LM70 is not set CONFIG_SENSORS_LM75=m # CONFIG_SENSORS_LM77 is not set # CONFIG_SENSORS_LM78 is not set # CONFIG_SENSORS_LM80 is not set # CONFIG_SENSORS_LM83 is not set # CONFIG_SENSORS_LM85 is not set # CONFIG_SENSORS_LM87 is not set # CONFIG_SENSORS_LM90 is not set # CONFIG_SENSORS_LM92 is not set # CONFIG_SENSORS_MAX1619 is not set # CONFIG_SENSORS_PC87360 is not set # CONFIG_SENSORS_SIS5595 is not set # CONFIG_SENSORS_SMSC47M1 is not set # CONFIG_SENSORS_SMSC47M192 is not set # CONFIG_SENSORS_SMSC47B397 is not set # CONFIG_SENSORS_VIA686A is not set # CONFIG_SENSORS_VT1211 is not set # CONFIG_SENSORS_VT8231 is not set # CONFIG_SENSORS_W83781D is not set # CONFIG_SENSORS_W83791D is not set # CONFIG_SENSORS_W83792D is not set # CONFIG_SENSORS_W83L785TS is not set CONFIG_SENSORS_W83627HF=m # CONFIG_SENSORS_W83627EHF is not set # CONFIG_SENSORS_HDAPS is not set CONFIG_HWMON_DEBUG_CHIP=y # # Multimedia devices # CONFIG_VIDEO_DEV=m CONFIG_VIDEO_V4L1=y CONFIG_VIDEO_V4L1_COMPAT=y CONFIG_VIDEO_V4L2=y # # Video Capture Adapters # # # Video Capture Adapters # # CONFIG_VIDEO_ADV_DEBUG is not set CONFIG_VIDEO_HELPER_CHIPS_AUTO=y CONFIG_VIDEO_VIVI=m # CONFIG_VIDEO_BT848 is not set # CONFIG_VIDEO_PMS is not set # CONFIG_VIDEO_BWQCAM is not set CONFIG_VIDEO_CQCAM=m # CONFIG_VIDEO_CPIA is not set # CONFIG_VIDEO_CPIA2 is not set # CONFIG_VIDEO_SAA5246A is not set # CONFIG_VIDEO_SAA5249 is not set # CONFIG_TUNER_3036 is not set # CONFIG_VIDEO_STRADIS is not set # CONFIG_VIDEO_ZORAN is not set # CONFIG_VIDEO_SAA7134 is not set # CONFIG_VIDEO_MXB is not set # CONFIG_VIDEO_DPC is not set # CONFIG_VIDEO_HEXIUM_ORION is not set # CONFIG_VIDEO_HEXIUM_GEMINI is not set # CONFIG_VIDEO_CX88 is not set # # V4L USB devices # # CONFIG_VIDEO_PVRUSB2 is not set # CONFIG_VIDEO_EM28XX is not set # CONFIG_USB_VICAM is not set # CONFIG_USB_IBMCAM is not set # CONFIG_USB_KONICAWC is not set # CONFIG_USB_QUICKCAM_MESSENGER is not set # CONFIG_USB_ET61X251 is not set # CONFIG_VIDEO_OVCAMCHIP is not set # CONFIG_USB_W9968CF is not set # CONFIG_USB_OV511 is not set # CONFIG_USB_SE401 is not set # CONFIG_USB_SN9C102 is not set # CONFIG_USB_STV680 is not set # CONFIG_USB_ZC0301 is not set # CONFIG_USB_PWC is not set # # Radio Adapters # # CONFIG_RADIO_CADET is not set # CONFIG_RADIO_RTRACK is not set # CONFIG_RADIO_RTRACK2 is not set # CONFIG_RADIO_AZTECH is not set # CONFIG_RADIO_GEMTEK is not set # CONFIG_RADIO_GEMTEK_PCI is not set # CONFIG_RADIO_MAXIRADIO is not set # CONFIG_RADIO_MAESTRO is not set # CONFIG_RADIO_SF16FMI is not set # CONFIG_RADIO_SF16FMR2 is not set # CONFIG_RADIO_TERRATEC is not set # CONFIG_RADIO_TRUST is not set # CONFIG_RADIO_TYPHOON is not set # CONFIG_RADIO_ZOLTRIX is not set # CONFIG_USB_DSBR is not set # # Digital Video Broadcasting Devices # # CONFIG_DVB is not set CONFIG_VIDEO_BUF=m # CONFIG_USB_DABUSB is not set # # Graphics support # CONFIG_FIRMWARE_EDID=y CONFIG_FB=m # CONFIG_FB_DDC is not set CONFIG_FB_CFB_FILLRECT=m CONFIG_FB_CFB_COPYAREA=m CONFIG_FB_CFB_IMAGEBLIT=m # CONFIG_FB_MACMODES is not set # CONFIG_FB_BACKLIGHT is not set CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y # CONFIG_FB_CIRRUS is not set # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_ARC is not set # CONFIG_FB_VGA16 is not set # CONFIG_FB_HGA is not set # CONFIG_FB_S1D13XXX is not set CONFIG_FB_NVIDIA=m CONFIG_FB_NVIDIA_I2C=y # CONFIG_FB_RIVA is not set # CONFIG_FB_I810 is not set # CONFIG_FB_INTEL is not set # CONFIG_FB_MATROX is not set # CONFIG_FB_RADEON is not set # CONFIG_FB_ATY128 is not set # CONFIG_FB_ATY is not set # CONFIG_FB_SAVAGE is not set # CONFIG_FB_SIS is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_KYRO is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set # CONFIG_FB_CYBLA is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_GEODE is not set # CONFIG_FB_VIRTUAL is not set # # Console display driver support # CONFIG_VGA_CONSOLE=y CONFIG_VGACON_SOFT_SCROLLBACK=y CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64 CONFIG_VIDEO_SELECT=y # CONFIG_MDA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=m # CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set # CONFIG_FONTS is not set CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y # # Logo configuration # # CONFIG_LOGO is not set # CONFIG_BACKLIGHT_LCD_SUPPORT is not set # # Sound # CONFIG_SOUND=m # # Advanced Linux Sound Architecture # CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_RAWMIDI=m CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_PCM_OSS_PLUGINS=y CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_RTCTIMER=m CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y # CONFIG_SND_DYNAMIC_MINORS is not set CONFIG_SND_SUPPORT_OLD_API=y CONFIG_SND_VERBOSE_PROCFS=y # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set # # Generic devices # CONFIG_SND_MPU401_UART=m CONFIG_SND_AC97_CODEC=m CONFIG_SND_AC97_BUS=m CONFIG_SND_DUMMY=m CONFIG_SND_VIRMIDI=m # CONFIG_SND_MTPAV is not set # CONFIG_SND_MTS64 is not set CONFIG_SND_SERIAL_U16550=m CONFIG_SND_MPU401=m # # ISA devices # # CONFIG_SND_ADLIB is not set # CONFIG_SND_AD1816A is not set # CONFIG_SND_AD1848 is not set # CONFIG_SND_ALS100 is not set # CONFIG_SND_AZT2320 is not set # CONFIG_SND_CMI8330 is not set # CONFIG_SND_CS4231 is not set # CONFIG_SND_CS4232 is not set # CONFIG_SND_CS4236 is not set # CONFIG_SND_DT019X is not set # CONFIG_SND_ES968 is not set # CONFIG_SND_ES1688 is not set # CONFIG_SND_ES18XX is not set # CONFIG_SND_GUSCLASSIC is not set # CONFIG_SND_GUSEXTREME is not set # CONFIG_SND_GUSMAX is not set # CONFIG_SND_INTERWAVE is not set # CONFIG_SND_INTERWAVE_STB is not set # CONFIG_SND_OPL3SA2 is not set # CONFIG_SND_OPTI92X_AD1848 is not set # CONFIG_SND_OPTI92X_CS4231 is not set # CONFIG_SND_OPTI93X is not set # CONFIG_SND_MIRO is not set # CONFIG_SND_SB8 is not set # CONFIG_SND_SB16 is not set # CONFIG_SND_SBAWE is not set # CONFIG_SND_SGALAXY is not set # CONFIG_SND_SSCAPE is not set # CONFIG_SND_WAVEFRONT is not set # # PCI devices # # CONFIG_SND_AD1889 is not set # CONFIG_SND_ALS300 is not set # CONFIG_SND_ALS4000 is not set # CONFIG_SND_ALI5451 is not set # CONFIG_SND_ATIIXP is not set # CONFIG_SND_ATIIXP_MODEM is not set # CONFIG_SND_AU8810 is not set # CONFIG_SND_AU8820 is not set # CONFIG_SND_AU8830 is not set # CONFIG_SND_AZT3328 is not set # CONFIG_SND_BT87X is not set # CONFIG_SND_CA0106 is not set # CONFIG_SND_CMIPCI is not set # CONFIG_SND_CS4281 is not set # CONFIG_SND_CS46XX is not set # CONFIG_SND_CS5535AUDIO is not set # CONFIG_SND_DARLA20 is not set # CONFIG_SND_GINA20 is not set # CONFIG_SND_LAYLA20 is not set # CONFIG_SND_DARLA24 is not set # CONFIG_SND_GINA24 is not set # CONFIG_SND_LAYLA24 is not set # CONFIG_SND_MONA is not set # CONFIG_SND_MIA is not set # CONFIG_SND_ECHO3G is not set # CONFIG_SND_INDIGO is not set # CONFIG_SND_INDIGOIO is not set # CONFIG_SND_INDIGODJ is not set # CONFIG_SND_EMU10K1 is not set # CONFIG_SND_EMU10K1X is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set # CONFIG_SND_FM801 is not set # CONFIG_SND_HDA_INTEL is not set # CONFIG_SND_HDSP is not set # CONFIG_SND_HDSPM is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_ICE1724 is not set # CONFIG_SND_INTEL8X0 is not set # CONFIG_SND_INTEL8X0M is not set # CONFIG_SND_KORG1212 is not set # CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_MIXART is not set # CONFIG_SND_NM256 is not set # CONFIG_SND_PCXHR is not set # CONFIG_SND_RIPTIDE is not set # CONFIG_SND_RME32 is not set # CONFIG_SND_RME96 is not set # CONFIG_SND_RME9652 is not set # CONFIG_SND_SONICVIBES is not set # CONFIG_SND_TRIDENT is not set CONFIG_SND_VIA82XX=m CONFIG_SND_VIA82XX_MODEM=m # CONFIG_SND_VX222 is not set # CONFIG_SND_YMFPCI is not set CONFIG_SND_AC97_POWER_SAVE=y # # USB devices # # CONFIG_SND_USB_AUDIO is not set # CONFIG_SND_USB_USX2Y is not set # # Open Sound System # # CONFIG_SOUND_PRIME is not set # # USB support # CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB_ARCH_HAS_EHCI=y CONFIG_USB=y CONFIG_USB_DEBUG=y # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y CONFIG_USB_BANDWIDTH=y CONFIG_USB_DYNAMIC_MINORS=y # CONFIG_USB_SUSPEND is not set # CONFIG_USB_OTG is not set # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=m CONFIG_USB_EHCI_SPLIT_ISO=y CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_USB_EHCI_TT_NEWSCHED=y # CONFIG_USB_ISP116X_HCD is not set # CONFIG_USB_OHCI_HCD is not set CONFIG_USB_UHCI_HCD=m # CONFIG_USB_SL811_HCD is not set # # USB Device Class drivers # CONFIG_USB_ACM=m CONFIG_USB_PRINTER=m # # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' # # # may also be needed; see USB_STORAGE Help for more information # CONFIG_USB_STORAGE=m CONFIG_USB_STORAGE_DEBUG=y CONFIG_USB_STORAGE_DATAFAB=y CONFIG_USB_STORAGE_FREECOM=y CONFIG_USB_STORAGE_ISD200=y CONFIG_USB_STORAGE_DPCM=y CONFIG_USB_STORAGE_USBAT=y CONFIG_USB_STORAGE_SDDR09=y CONFIG_USB_STORAGE_SDDR55=y CONFIG_USB_STORAGE_JUMPSHOT=y CONFIG_USB_STORAGE_ALAUDA=y # CONFIG_USB_STORAGE_KARMA is not set # CONFIG_USB_LIBUSUAL is not set # # USB Input Devices # CONFIG_USB_HID=m CONFIG_USB_HIDINPUT=y # CONFIG_USB_HIDINPUT_POWERBOOK is not set # CONFIG_HID_FF is not set CONFIG_USB_HIDDEV=y # # USB HID Boot Protocol drivers # # CONFIG_USB_KBD is not set # CONFIG_USB_MOUSE is not set # CONFIG_USB_AIPTEK is not set # CONFIG_USB_WACOM is not set # CONFIG_USB_ACECAD is not set # CONFIG_USB_KBTAB is not set # CONFIG_USB_POWERMATE is not set # CONFIG_USB_TOUCHSCREEN is not set # CONFIG_USB_YEALINK is not set # CONFIG_USB_XPAD is not set # CONFIG_USB_ATI_REMOTE is not set # CONFIG_USB_ATI_REMOTE2 is not set # CONFIG_USB_KEYSPAN_REMOTE is not set # CONFIG_USB_APPLETOUCH is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # CONFIG_USB_MICROTEK is not set # # USB Network Adapters # # CONFIG_USB_CATC is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set CONFIG_USB_USBNET=m CONFIG_USB_NET_CDCETHER=m # CONFIG_USB_NET_GL620A is not set CONFIG_USB_NET_NET1080=m # CONFIG_USB_NET_PLUSB is not set # CONFIG_USB_NET_MCS7830 is not set # CONFIG_USB_NET_RNDIS_HOST is not set CONFIG_USB_NET_CDC_SUBSET=m # CONFIG_USB_ALI_M5632 is not set # CONFIG_USB_AN2720 is not set CONFIG_USB_BELKIN=y CONFIG_USB_ARMLINUX=y # CONFIG_USB_EPSON2888 is not set CONFIG_USB_NET_ZAURUS=m CONFIG_USB_MON=y # # USB port drivers # # CONFIG_USB_USS720 is not set # # USB Serial Converter support # CONFIG_USB_SERIAL=m CONFIG_USB_SERIAL_GENERIC=y CONFIG_USB_SERIAL_AIRCABLE=m # CONFIG_USB_SERIAL_AIRPRIME is not set # CONFIG_USB_SERIAL_ARK3116 is not set # CONFIG_USB_SERIAL_BELKIN is not set # CONFIG_USB_SERIAL_WHITEHEAT is not set # CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set # CONFIG_USB_SERIAL_CP2101 is not set # CONFIG_USB_SERIAL_CYPRESS_M8 is not set # CONFIG_USB_SERIAL_EMPEG is not set # CONFIG_USB_SERIAL_FTDI_SIO is not set # CONFIG_USB_SERIAL_FUNSOFT is not set # CONFIG_USB_SERIAL_VISOR is not set # CONFIG_USB_SERIAL_IPAQ is not set # CONFIG_USB_SERIAL_IR is not set # CONFIG_USB_SERIAL_EDGEPORT is not set # CONFIG_USB_SERIAL_EDGEPORT_TI is not set # CONFIG_USB_SERIAL_GARMIN is not set # CONFIG_USB_SERIAL_IPW is not set # CONFIG_USB_SERIAL_KEYSPAN_PDA is not set # CONFIG_USB_SERIAL_KEYSPAN is not set # CONFIG_USB_SERIAL_KLSI is not set # CONFIG_USB_SERIAL_KOBIL_SCT is not set # CONFIG_USB_SERIAL_MCT_U232 is not set # CONFIG_USB_SERIAL_MOS7720 is not set # CONFIG_USB_SERIAL_MOS7840 is not set # CONFIG_USB_SERIAL_NAVMAN is not set # CONFIG_USB_SERIAL_PL2303 is not set # CONFIG_USB_SERIAL_HP4X is not set # CONFIG_USB_SERIAL_SAFE is not set # CONFIG_USB_SERIAL_SIERRAWIRELESS is not set # CONFIG_USB_SERIAL_TI is not set # CONFIG_USB_SERIAL_CYBERJACK is not set # CONFIG_USB_SERIAL_XIRCOM is not set CONFIG_USB_SERIAL_OPTION=m # CONFIG_USB_SERIAL_OMNINET is not set # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_ADUTUX is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_LED is not set # CONFIG_USB_CYPRESS_CY7C63 is not set # CONFIG_USB_CYTHERM is not set # CONFIG_USB_PHIDGET is not set # CONFIG_USB_IDMOUSE is not set # CONFIG_USB_FTDI_ELAN is not set # CONFIG_USB_APPLEDISPLAY is not set # CONFIG_USB_SISUSBVGA is not set # CONFIG_USB_LD is not set # CONFIG_USB_TRANCEVIBRATOR is not set # CONFIG_USB_TEST is not set # # USB DSL modem support # # # USB Gadget Support # # CONFIG_USB_GADGET is not set # # MMC/SD Card support # CONFIG_MMC=m # CONFIG_MMC_DEBUG is not set CONFIG_MMC_BLOCK=m CONFIG_MMC_SDHCI=m CONFIG_MMC_WBSD=m CONFIG_MMC_TIFM_SD=m # # LED devices # # CONFIG_NEW_LEDS is not set # # LED drivers # # # LED Triggers # # # InfiniBand support # # CONFIG_INFINIBAND is not set # # EDAC - error detection and reporting (RAS) (EXPERIMENTAL) # CONFIG_EDAC=y # # Reporting subsystems # # CONFIG_EDAC_DEBUG is not set CONFIG_EDAC_MM_EDAC=y # CONFIG_EDAC_AMD76X is not set # CONFIG_EDAC_E7XXX is not set # CONFIG_EDAC_E752X is not set # CONFIG_EDAC_I82875P is not set # CONFIG_EDAC_I82860 is not set # CONFIG_EDAC_R82600 is not set CONFIG_EDAC_POLL=y # # Real Time Clock # # CONFIG_RTC_CLASS is not set # # DMA Engine support # CONFIG_DMA_ENGINE=y # # DMA Clients # CONFIG_NET_DMA=y # # DMA Devices # CONFIG_INTEL_IOATDMA=y # # File systems # CONFIG_EXT2_FS=y # CONFIG_EXT2_FS_XATTR is not set # CONFIG_EXT2_FS_XIP is not set CONFIG_EXT3_FS=y # CONFIG_EXT3_FS_XATTR is not set # CONFIG_EXT4DEV_FS is not set CONFIG_JBD=y CONFIG_JBD_DEBUG=y # CONFIG_REISERFS_FS is not set # CONFIG_JFS_FS is not set CONFIG_FS_POSIX_ACL=y # CONFIG_XFS_FS is not set # CONFIG_GFS2_FS is not set # CONFIG_OCFS2_FS is not set CONFIG_MINIX_FS=m # CONFIG_ROMFS_FS is not set CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y CONFIG_QUOTA=y # CONFIG_QFMT_V1 is not set # CONFIG_QFMT_V2 is not set CONFIG_QUOTACTL=y CONFIG_DNOTIFY=y CONFIG_AUTOFS_FS=m CONFIG_AUTOFS4_FS=m # CONFIG_FUSE_FS is not set # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_ZISOFS_FS=y CONFIG_UDF_FS=y CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=y CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=y CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" CONFIG_NTFS_FS=y CONFIG_NTFS_DEBUG=y CONFIG_NTFS_RW=y # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_SYSCTL=y CONFIG_SYSFS=y CONFIG_TMPFS=y # CONFIG_TMPFS_POSIX_ACL is not set # CONFIG_HUGETLBFS is not set # CONFIG_HUGETLB_PAGE is not set CONFIG_RAMFS=y CONFIG_CONFIGFS_FS=y # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set # # Network File Systems # CONFIG_NFS_FS=y CONFIG_NFS_V3=y # CONFIG_NFS_V3_ACL is not set CONFIG_NFS_V4=y # CONFIG_NFS_DIRECTIO is not set CONFIG_NFSD=m CONFIG_NFSD_V3=y # CONFIG_NFSD_V3_ACL is not set CONFIG_NFSD_V4=y CONFIG_NFSD_TCP=y CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=m CONFIG_NFS_COMMON=y CONFIG_SUNRPC=y CONFIG_SUNRPC_GSS=y CONFIG_RPCSEC_GSS_KRB5=y CONFIG_RPCSEC_GSS_SPKM3=m CONFIG_SMB_FS=m CONFIG_SMB_NLS_DEFAULT=y CONFIG_SMB_NLS_REMOTE="cp850" CONFIG_CIFS=m CONFIG_CIFS_STATS=y # CONFIG_CIFS_STATS2 is not set CONFIG_CIFS_WEAK_PW_HASH=y CONFIG_CIFS_XATTR=y CONFIG_CIFS_POSIX=y # CONFIG_CIFS_DEBUG2 is not set CONFIG_CIFS_EXPERIMENTAL=y # CONFIG_CIFS_UPCALL is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # CONFIG_9P_FS is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set # CONFIG_OSF_PARTITION is not set # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set # CONFIG_MAC_PARTITION is not set CONFIG_MSDOS_PARTITION=y # CONFIG_BSD_DISKLABEL is not set # CONFIG_MINIX_SUBPARTITION is not set # CONFIG_SOLARIS_X86_PARTITION is not set # CONFIG_UNIXWARE_DISKLABEL is not set CONFIG_LDM_PARTITION=y CONFIG_LDM_DEBUG=y # CONFIG_SGI_PARTITION is not set # CONFIG_ULTRIX_PARTITION is not set # CONFIG_SUN_PARTITION is not set # CONFIG_KARMA_PARTITION is not set # CONFIG_EFI_PARTITION is not set # # Native Language Support # CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso-8859-1" CONFIG_NLS_CODEPAGE_437=y # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set CONFIG_NLS_CODEPAGE_850=y CONFIG_NLS_CODEPAGE_852=y # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ASCII=m CONFIG_NLS_ISO8859_1=y CONFIG_NLS_ISO8859_2=y # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_UTF8=y # # Distributed Lock Manager # CONFIG_DLM=m # CONFIG_DLM_DEBUG is not set # # Instrumentation Support # # CONFIG_PROFILING is not set # CONFIG_KPROBES is not set # # Kernel hacking # CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_PRINTK_TIME=y # CONFIG_ENABLE_MUST_CHECK is not set CONFIG_MAGIC_SYSRQ=y CONFIG_UNUSED_SYMBOLS=y CONFIG_DEBUG_KERNEL=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_DETECT_SOFTLOCKUP=y # CONFIG_SCHEDSTATS is not set # CONFIG_DEBUG_SLAB is not set CONFIG_DEBUG_PREEMPT=y # CONFIG_DEBUG_RT_MUTEXES is not set # CONFIG_RT_MUTEX_TESTER is not set # CONFIG_DEBUG_SPINLOCK is not set CONFIG_DEBUG_MUTEXES=y # CONFIG_DEBUG_RWSEMS is not set # CONFIG_DEBUG_LOCK_ALLOC is not set # CONFIG_PROVE_LOCKING is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set # CONFIG_DEBUG_KOBJECT is not set # CONFIG_DEBUG_HIGHMEM is not set CONFIG_DEBUG_BUGVERBOSE=y # CONFIG_DEBUG_INFO is not set CONFIG_DEBUG_FS=y # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_LIST is not set CONFIG_FRAME_POINTER=y CONFIG_UNWIND_INFO=y CONFIG_STACK_UNWIND=y CONFIG_FORCED_INLINING=y # CONFIG_HEADERS_CHECK is not set # CONFIG_RCU_TORTURE_TEST is not set CONFIG_EARLY_PRINTK=y # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUG_PAGEALLOC is not set CONFIG_DEBUG_RODATA=y # CONFIG_4KSTACKS is not set CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y CONFIG_DOUBLEFAULT=y # # Security options # # CONFIG_KEYS is not set # CONFIG_SECURITY is not set # # Cryptographic options # CONFIG_CRYPTO=y CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_BLKCIPHER=y CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_SHA1=y CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_WP512=m CONFIG_CRYPTO_TGR192=m CONFIG_CRYPTO_ECB=m CONFIG_CRYPTO_CBC=y CONFIG_CRYPTO_DES=y CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_TWOFISH_COMMON=m CONFIG_CRYPTO_TWOFISH_586=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_AES_586=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_TEA=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_KHAZAD=m CONFIG_CRYPTO_ANUBIS=m CONFIG_CRYPTO_DEFLATE=y CONFIG_CRYPTO_MICHAEL_MIC=m CONFIG_CRYPTO_CRC32C=m CONFIG_CRYPTO_TEST=m # # Hardware crypto devices # CONFIG_CRYPTO_DEV_PADLOCK=y CONFIG_CRYPTO_DEV_PADLOCK_AES=y CONFIG_CRYPTO_DEV_PADLOCK_SHA=m # # Library routines # CONFIG_CRC_CCITT=m CONFIG_CRC16=m CONFIG_CRC32=m CONFIG_LIBCRC32C=m CONFIG_AUDIT_GENERIC=y CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y CONFIG_TEXTSEARCH=y CONFIG_TEXTSEARCH_KMP=y CONFIG_TEXTSEARCH_BM=y CONFIG_TEXTSEARCH_FSM=y CONFIG_PLIST=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_X86_BIOS_REBOOT=y CONFIG_KTIME_SCALAR=y [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 152+ messages in thread
* [PATCH] !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB 2006-10-25 20:13 ` Linux 2.6.19-rc3: !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB Athanasius @ 2006-10-25 22:17 ` Randy Dunlap 2006-10-25 22:27 ` David Brownell 0 siblings, 1 reply; 152+ messages in thread From: Randy Dunlap @ 2006-10-25 22:17 UTC (permalink / raw) To: Athanasius, toralf.foerster, gregkh, akpm, netdev, lud Cc: Linus Torvalds, linux-kernel, David Brownell, Roman Zippel From: Randy Dunlap <randy.dunlap@oracle.com> USB network drivers that use mii_*() interfaces should cause those interfaces to be built. Or depend on them, but this is what all drivers/net/ drivers do. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> --- drivers/usb/net/Kconfig | 3 +++ 1 file changed, 3 insertions(+) --- linux-2619-rc3-pv.orig/drivers/usb/net/Kconfig +++ linux-2619-rc3-pv/drivers/usb/net/Kconfig @@ -84,6 +84,7 @@ config USB_PEGASUS config USB_RTL8150 tristate "USB RTL8150 based ethernet device support (EXPERIMENTAL)" depends on EXPERIMENTAL + select MII help Say Y here if you have RTL8150 based usb-ethernet adapter. Send me <petkan@users.sourceforge.net> any comments you may have. @@ -94,6 +95,7 @@ config USB_RTL8150 config USB_USBNET tristate "Multi-purpose USB Networking Framework" + select MII ---help--- This driver supports several kinds of network links over USB, with "minidrivers" built around a common network driver core @@ -210,6 +212,7 @@ config USB_NET_PLUSB config USB_NET_MCS7830 tristate "MosChip MCS7830 based Ethernet adapters" depends on USB_USBNET + select MII help Choose this option if you're using a 10/100 Ethernet USB2 adapter based on the MosChip 7830 controller. This includes --- ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [PATCH] !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB 2006-10-25 22:17 ` [PATCH] " Randy Dunlap @ 2006-10-25 22:27 ` David Brownell 0 siblings, 0 replies; 152+ messages in thread From: David Brownell @ 2006-10-25 22:27 UTC (permalink / raw) To: toralf.foerster, randy.dunlap, netdev, linux-usb-devel, link, greg, akpm Cc: zippel, torvalds, linux-kernel, dbrownell > @@ -94,6 +95,7 @@ config USB_RTL8150 > > config USB_USBNET > tristate "Multi-purpose USB Networking Framework" > + select MII > ---help--- > This driver supports several kinds of network links over USB, > with "minidrivers" built around a common network driver core The other parts are right, this isn't. Instead, "usbnet.c" should #ifdef the relevant ethtool hooks according to CONFIG_MII ... since it's completely legit to use usbnet with peripherals that don't need MII. ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [PATCH] !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB @ 2006-10-25 22:27 ` David Brownell 0 siblings, 0 replies; 152+ messages in thread From: David Brownell @ 2006-10-25 22:27 UTC (permalink / raw) To: toralf.foerster, randy.dunlap, netdev, linux-usb-devel, link, greg, akpm Cc: zippel, torvalds, linux-kernel, dbrownell > @@ -94,6 +95,7 @@ config USB_RTL8150 > > config USB_USBNET > tristate "Multi-purpose USB Networking Framework" > + select MII > ---help--- > This driver supports several kinds of network links over USB, > with "minidrivers" built around a common network driver core The other parts are right, this isn't. Instead, "usbnet.c" should #ifdef the relevant ethtool hooks according to CONFIG_MII ... since it's completely legit to use usbnet with peripherals that don't need MII. ^ permalink raw reply [flat|nested] 152+ messages in thread
* [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled 2006-10-25 22:27 ` David Brownell (?) @ 2006-10-25 23:58 ` Randy Dunlap 2006-10-26 2:22 ` David Brownell ` (2 more replies) -1 siblings, 3 replies; 152+ messages in thread From: Randy Dunlap @ 2006-10-25 23:58 UTC (permalink / raw) To: David Brownell Cc: toralf.foerster, netdev, linux-usb-devel, link, greg, akpm, zippel, torvalds, linux-kernel, dbrownell On Wed, 25 Oct 2006 15:27:09 -0700 David Brownell wrote: > Instead, "usbnet.c" should #ifdef the relevant ethtool hooks > according to CONFIG_MII ... since it's completely legit to > use usbnet with peripherals that don't need MII. --- From: Randy Dunlap <randy.dunlap@oracle.com> usbnet driver should use mii_*() interfaces if they are available in the kernel (config enabled) but usbnet does not require or depend on these interfaces. Build tested with CONFIG_MII=y, m, n. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> --- drivers/usb/net/usbnet.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) --- linux-2619-rc3-pv.orig/drivers/usb/net/usbnet.c +++ linux-2619-rc3-pv/drivers/usb/net/usbnet.c @@ -47,6 +47,12 @@ #define DRIVER_VERSION "22-Aug-2005" +#if defined(CONFIG_MII) || defined(CONFIG_MII_MODULE) +#define HAVE_MII 1 +#else +#define HAVE_MII 0 +#endif + /*-------------------------------------------------------------------------*/ @@ -676,7 +682,10 @@ int usbnet_get_settings (struct net_devi if (!dev->mii.mdio_read) return -EOPNOTSUPP; +#if HAVE_MII return mii_ethtool_gset(&dev->mii, cmd); +#endif + return -EOPNOTSUPP; } EXPORT_SYMBOL_GPL(usbnet_get_settings); @@ -688,7 +697,11 @@ int usbnet_set_settings (struct net_devi if (!dev->mii.mdio_write) return -EOPNOTSUPP; +#if HAVE_MII retval = mii_ethtool_sset(&dev->mii, cmd); +#else + retval = -EOPNOTSUPP; +#endif /* link speed/duplex might have changed */ if (dev->driver_info->link_reset) @@ -721,9 +734,11 @@ u32 usbnet_get_link (struct net_device * if (dev->driver_info->check_connect) return dev->driver_info->check_connect (dev) == 0; +#if HAVE_MII /* if the device has mii operations, use those */ if (dev->mii.mdio_read) return mii_link_ok(&dev->mii); +#endif /* Otherwise, say we're up (to avoid breaking scripts) */ return 1; @@ -753,7 +768,10 @@ int usbnet_nway_reset(struct net_device if (!dev->mii.mdio_write) return -EOPNOTSUPP; +#if HAVE_MII return mii_nway_restart(&dev->mii); +#endif + return -EOPNOTSUPP; } EXPORT_SYMBOL_GPL(usbnet_nway_reset); ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled 2006-10-25 23:58 ` [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled Randy Dunlap @ 2006-10-26 2:22 ` David Brownell 2006-11-02 7:15 ` Greg KH 2006-10-26 15:46 ` [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled Adrian Bunk 2006-10-28 11:21 ` Christoph Hellwig 2 siblings, 1 reply; 152+ messages in thread From: David Brownell @ 2006-10-26 2:22 UTC (permalink / raw) To: Randy Dunlap Cc: toralf.foerster, netdev, linux-usb-devel, link, greg, akpm, zippel, torvalds, linux-kernel On Wednesday 25 October 2006 4:58 pm, Randy Dunlap wrote: > On Wed, 25 Oct 2006 15:27:09 -0700 David Brownell wrote: > > > Instead, "usbnet.c" should #ifdef the relevant ethtool hooks > > according to CONFIG_MII ... since it's completely legit to > > use usbnet with peripherals that don't need MII. I had in mind something simpler -- #ifdeffing the entire functions, as in this patch. It looks more complicated than it is, because "diff" gets confused by moving two functions earlier in the file. (Thanks for starting this, Randy ... these two patches should be merged before RC4 ships.) - Dave The usbnet infrastructure must not reference MII symbols unless they're provided in the kernel being built. This extends also to the ethtool hooks that reference those symbols. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Index: g26/drivers/usb/net/usbnet.c =================================================================== --- g26.orig/drivers/usb/net/usbnet.c 2006-10-24 18:29:28.000000000 -0700 +++ g26/drivers/usb/net/usbnet.c 2006-10-25 19:07:16.000000000 -0700 @@ -669,6 +669,9 @@ done: * they'll probably want to use this base set. */ +#if defined(CONFIG_MII) || defined(CONFIG_MII_MODULE) +#define HAVE_MII + int usbnet_get_settings (struct net_device *net, struct ethtool_cmd *cmd) { struct usbnet *dev = netdev_priv(net); @@ -699,20 +702,6 @@ int usbnet_set_settings (struct net_devi } EXPORT_SYMBOL_GPL(usbnet_set_settings); - -void usbnet_get_drvinfo (struct net_device *net, struct ethtool_drvinfo *info) -{ - struct usbnet *dev = netdev_priv(net); - - /* REVISIT don't always return "usbnet" */ - strncpy (info->driver, driver_name, sizeof info->driver); - strncpy (info->version, DRIVER_VERSION, sizeof info->version); - strncpy (info->fw_version, dev->driver_info->description, - sizeof info->fw_version); - usb_make_path (dev->udev, info->bus_info, sizeof info->bus_info); -} -EXPORT_SYMBOL_GPL(usbnet_get_drvinfo); - u32 usbnet_get_link (struct net_device *net) { struct usbnet *dev = netdev_priv(net); @@ -730,40 +719,57 @@ u32 usbnet_get_link (struct net_device * } EXPORT_SYMBOL_GPL(usbnet_get_link); -u32 usbnet_get_msglevel (struct net_device *net) +int usbnet_nway_reset(struct net_device *net) { struct usbnet *dev = netdev_priv(net); - return dev->msg_enable; + if (!dev->mii.mdio_write) + return -EOPNOTSUPP; + + return mii_nway_restart(&dev->mii); } -EXPORT_SYMBOL_GPL(usbnet_get_msglevel); +EXPORT_SYMBOL_GPL(usbnet_nway_reset); -void usbnet_set_msglevel (struct net_device *net, u32 level) +#endif /* HAVE_MII */ + +void usbnet_get_drvinfo (struct net_device *net, struct ethtool_drvinfo *info) { struct usbnet *dev = netdev_priv(net); - dev->msg_enable = level; + /* REVISIT don't always return "usbnet" */ + strncpy (info->driver, driver_name, sizeof info->driver); + strncpy (info->version, DRIVER_VERSION, sizeof info->version); + strncpy (info->fw_version, dev->driver_info->description, + sizeof info->fw_version); + usb_make_path (dev->udev, info->bus_info, sizeof info->bus_info); } -EXPORT_SYMBOL_GPL(usbnet_set_msglevel); +EXPORT_SYMBOL_GPL(usbnet_get_drvinfo); -int usbnet_nway_reset(struct net_device *net) +u32 usbnet_get_msglevel (struct net_device *net) { struct usbnet *dev = netdev_priv(net); - if (!dev->mii.mdio_write) - return -EOPNOTSUPP; + return dev->msg_enable; +} +EXPORT_SYMBOL_GPL(usbnet_get_msglevel); - return mii_nway_restart(&dev->mii); +void usbnet_set_msglevel (struct net_device *net, u32 level) +{ + struct usbnet *dev = netdev_priv(net); + + dev->msg_enable = level; } -EXPORT_SYMBOL_GPL(usbnet_nway_reset); +EXPORT_SYMBOL_GPL(usbnet_set_msglevel); /* drivers may override default ethtool_ops in their bind() routine */ static struct ethtool_ops usbnet_ethtool_ops = { +#ifdef HAVE_MII .get_settings = usbnet_get_settings, .set_settings = usbnet_set_settings, - .get_drvinfo = usbnet_get_drvinfo, .get_link = usbnet_get_link, .nway_reset = usbnet_nway_reset, +#endif + .get_drvinfo = usbnet_get_drvinfo, .get_msglevel = usbnet_get_msglevel, .set_msglevel = usbnet_set_msglevel, }; ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled 2006-10-26 2:22 ` David Brownell @ 2006-11-02 7:15 ` Greg KH 2006-11-02 20:29 ` David Brownell 0 siblings, 1 reply; 152+ messages in thread From: Greg KH @ 2006-11-02 7:15 UTC (permalink / raw) To: David Brownell Cc: Randy Dunlap, toralf.foerster, netdev, linux-usb-devel, link, akpm, zippel, torvalds, linux-kernel On Wed, Oct 25, 2006 at 07:22:08PM -0700, David Brownell wrote: > On Wednesday 25 October 2006 4:58 pm, Randy Dunlap wrote: > > On Wed, 25 Oct 2006 15:27:09 -0700 David Brownell wrote: > > > > > Instead, "usbnet.c" should #ifdef the relevant ethtool hooks > > > according to CONFIG_MII ... since it's completely legit to > > > use usbnet with peripherals that don't need MII. > > I had in mind something simpler -- #ifdeffing the entire functions, > as in this patch. It looks more complicated than it is, because > "diff" gets confused by moving two functions earlier in the file. > > (Thanks for starting this, Randy ... these two patches should be merged > before RC4 ships.) Argh, there were just too many different versions of these patches floating around. Can you resend the final versions please? thanks, greg k-h ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled 2006-11-02 7:15 ` Greg KH @ 2006-11-02 20:29 ` David Brownell 2006-11-03 2:27 ` Adrian Bunk 0 siblings, 1 reply; 152+ messages in thread From: David Brownell @ 2006-11-02 20:29 UTC (permalink / raw) To: Greg KH Cc: Randy Dunlap, toralf.foerster, netdev, linux-usb-devel, link, akpm, zippel, torvalds, linux-kernel On Wednesday 01 November 2006 11:15 pm, Greg KH wrote: > Argh, there were just too many different versions of these patches > floating around. Can you resend the final versions please? This should replace BOTH of Randy's patches. It addresses all the issues I've heard raised, and resolves the regresssion introduced when adding the mcs7830 minidriver. - Dave ============ CUT HERE Fix mcs7830 patch The recent mcs7830 update to make the MII support sharable goofed various pre-existing configurations in two ways: - it made the usbnet infrastructure reference MII symbols even when they're not needed in the kernel being built - it didn't enable MII along with the mcs7830 minidriver This patch fixes these two problems. However, there does seem to be a Kconfig reverse dependency bug in that MII gets wrongly enabled in some cases (like USBNET=y and USBNET_MII=n); I think I've noticed that same problem in other situations too. So the result can mean kernels being bloated by stuff that's needlessly enabled ... better than wrongly being disabled, but contributing to bloat. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Index: at91/drivers/usb/net/Kconfig =================================================================== --- at91.orig/drivers/usb/net/Kconfig 2006-11-02 10:58:49.000000000 -0800 +++ at91/drivers/usb/net/Kconfig 2006-11-02 12:10:13.000000000 -0800 @@ -92,8 +92,13 @@ config USB_RTL8150 To compile this driver as a module, choose M here: the module will be called rtl8150. +config USB_USBNET_MII + tristate + default n + config USB_USBNET tristate "Multi-purpose USB Networking Framework" + select MII if USBNET_MII != n ---help--- This driver supports several kinds of network links over USB, with "minidrivers" built around a common network driver core @@ -129,7 +134,7 @@ config USB_NET_AX8817X tristate "ASIX AX88xxx Based USB 2.0 Ethernet Adapters" depends on USB_USBNET && NET_ETHERNET select CRC32 - select MII + select USB_USBNET_MII default y help This option adds support for ASIX AX88xxx based USB 2.0 @@ -210,6 +215,7 @@ config USB_NET_PLUSB config USB_NET_MCS7830 tristate "MosChip MCS7830 based Ethernet adapters" depends on USB_USBNET + select USB_USBNET_MII help Choose this option if you're using a 10/100 Ethernet USB2 adapter based on the MosChip 7830 controller. This includes Index: at91/drivers/usb/net/usbnet.c =================================================================== --- at91.orig/drivers/usb/net/usbnet.c 2006-11-02 10:58:49.000000000 -0800 +++ at91/drivers/usb/net/usbnet.c 2006-11-02 11:09:29.000000000 -0800 @@ -669,6 +669,9 @@ done: * they'll probably want to use this base set. */ +#if defined(CONFIG_MII) || defined(CONFIG_MII_MODULE) +#define HAVE_MII + int usbnet_get_settings (struct net_device *net, struct ethtool_cmd *cmd) { struct usbnet *dev = netdev_priv(net); @@ -699,20 +702,6 @@ int usbnet_set_settings (struct net_devi } EXPORT_SYMBOL_GPL(usbnet_set_settings); - -void usbnet_get_drvinfo (struct net_device *net, struct ethtool_drvinfo *info) -{ - struct usbnet *dev = netdev_priv(net); - - /* REVISIT don't always return "usbnet" */ - strncpy (info->driver, driver_name, sizeof info->driver); - strncpy (info->version, DRIVER_VERSION, sizeof info->version); - strncpy (info->fw_version, dev->driver_info->description, - sizeof info->fw_version); - usb_make_path (dev->udev, info->bus_info, sizeof info->bus_info); -} -EXPORT_SYMBOL_GPL(usbnet_get_drvinfo); - u32 usbnet_get_link (struct net_device *net) { struct usbnet *dev = netdev_priv(net); @@ -730,40 +719,57 @@ u32 usbnet_get_link (struct net_device * } EXPORT_SYMBOL_GPL(usbnet_get_link); -u32 usbnet_get_msglevel (struct net_device *net) +int usbnet_nway_reset(struct net_device *net) { struct usbnet *dev = netdev_priv(net); - return dev->msg_enable; + if (!dev->mii.mdio_write) + return -EOPNOTSUPP; + + return mii_nway_restart(&dev->mii); } -EXPORT_SYMBOL_GPL(usbnet_get_msglevel); +EXPORT_SYMBOL_GPL(usbnet_nway_reset); -void usbnet_set_msglevel (struct net_device *net, u32 level) +#endif /* HAVE_MII */ + +void usbnet_get_drvinfo (struct net_device *net, struct ethtool_drvinfo *info) { struct usbnet *dev = netdev_priv(net); - dev->msg_enable = level; + /* REVISIT don't always return "usbnet" */ + strncpy (info->driver, driver_name, sizeof info->driver); + strncpy (info->version, DRIVER_VERSION, sizeof info->version); + strncpy (info->fw_version, dev->driver_info->description, + sizeof info->fw_version); + usb_make_path (dev->udev, info->bus_info, sizeof info->bus_info); } -EXPORT_SYMBOL_GPL(usbnet_set_msglevel); +EXPORT_SYMBOL_GPL(usbnet_get_drvinfo); -int usbnet_nway_reset(struct net_device *net) +u32 usbnet_get_msglevel (struct net_device *net) { struct usbnet *dev = netdev_priv(net); - if (!dev->mii.mdio_write) - return -EOPNOTSUPP; + return dev->msg_enable; +} +EXPORT_SYMBOL_GPL(usbnet_get_msglevel); - return mii_nway_restart(&dev->mii); +void usbnet_set_msglevel (struct net_device *net, u32 level) +{ + struct usbnet *dev = netdev_priv(net); + + dev->msg_enable = level; } -EXPORT_SYMBOL_GPL(usbnet_nway_reset); +EXPORT_SYMBOL_GPL(usbnet_set_msglevel); /* drivers may override default ethtool_ops in their bind() routine */ static struct ethtool_ops usbnet_ethtool_ops = { +#ifdef HAVE_MII .get_settings = usbnet_get_settings, .set_settings = usbnet_set_settings, - .get_drvinfo = usbnet_get_drvinfo, .get_link = usbnet_get_link, .nway_reset = usbnet_nway_reset, +#endif + .get_drvinfo = usbnet_get_drvinfo, .get_msglevel = usbnet_get_msglevel, .set_msglevel = usbnet_set_msglevel, }; ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled 2006-11-02 20:29 ` David Brownell @ 2006-11-03 2:27 ` Adrian Bunk 2006-11-03 2:47 ` David Brownell 0 siblings, 1 reply; 152+ messages in thread From: Adrian Bunk @ 2006-11-03 2:27 UTC (permalink / raw) To: David Brownell Cc: Greg KH, Randy Dunlap, toralf.foerster, netdev, linux-usb-devel, link, akpm, zippel, torvalds, linux-kernel On Thu, Nov 02, 2006 at 12:29:12PM -0800, David Brownell wrote: > On Wednesday 01 November 2006 11:15 pm, Greg KH wrote: > > > Argh, there were just too many different versions of these patches > > floating around. Can you resend the final versions please? > > This should replace BOTH of Randy's patches. It addresses all the > issues I've heard raised, and resolves the regresssion introduced > when adding the mcs7830 minidriver. It seems to lack the "select MII" at the USB_RTL8150 option that was in Randy's first patch? > - Dave >... > --- at91.orig/drivers/usb/net/Kconfig 2006-11-02 10:58:49.000000000 -0800 > +++ at91/drivers/usb/net/Kconfig 2006-11-02 12:10:13.000000000 -0800 > @@ -92,8 +92,13 @@ config USB_RTL8150 > To compile this driver as a module, choose M here: the > module will be called rtl8150. > > +config USB_USBNET_MII > + tristate > + default n > + > config USB_USBNET > tristate "Multi-purpose USB Networking Framework" > + select MII if USBNET_MII != n > ---help--- > This driver supports several kinds of network links over USB, > with "minidrivers" built around a common network driver core > @@ -129,7 +134,7 @@ config USB_NET_AX8817X > tristate "ASIX AX88xxx Based USB 2.0 Ethernet Adapters" > depends on USB_USBNET && NET_ETHERNET > select CRC32 > - select MII > + select USB_USBNET_MII > default y > help > This option adds support for ASIX AX88xxx based USB 2.0 > @@ -210,6 +215,7 @@ config USB_NET_PLUSB > config USB_NET_MCS7830 > tristate "MosChip MCS7830 based Ethernet adapters" > depends on USB_USBNET > + select USB_USBNET_MII > help > Choose this option if you're using a 10/100 Ethernet USB2 > adapter based on the MosChip 7830 controller. This includes > Index: at91/drivers/usb/net/usbnet.c > =================================================================== > --- at91.orig/drivers/usb/net/usbnet.c 2006-11-02 10:58:49.000000000 -0800 > +++ at91/drivers/usb/net/usbnet.c 2006-11-02 11:09:29.000000000 -0800 >... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled 2006-11-03 2:27 ` Adrian Bunk @ 2006-11-03 2:47 ` David Brownell 2006-11-03 2:58 ` Randy.Dunlap 2006-11-04 2:51 ` [2.6 patch] USB_RTL8150 must select MII Adrian Bunk 0 siblings, 2 replies; 152+ messages in thread From: David Brownell @ 2006-11-03 2:47 UTC (permalink / raw) To: Adrian Bunk Cc: Greg KH, Randy Dunlap, toralf.foerster, netdev, linux-usb-devel, link, akpm, zippel, torvalds, linux-kernel On Thursday 02 November 2006 6:27 pm, Adrian Bunk wrote: > It seems to lack the "select MII" at the USB_RTL8150 option that was in > Randy's first patch? I was just addressing the usbnet issues ... that driver doesn't use the usbnet framework. - Dave ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled 2006-11-03 2:47 ` David Brownell @ 2006-11-03 2:58 ` Randy.Dunlap 2006-11-04 2:51 ` [2.6 patch] USB_RTL8150 must select MII Adrian Bunk 1 sibling, 0 replies; 152+ messages in thread From: Randy.Dunlap @ 2006-11-03 2:58 UTC (permalink / raw) To: David Brownell Cc: Adrian Bunk, Greg KH, Randy Dunlap, toralf.foerster, netdev, linux-usb-devel, link, akpm, zippel, torvalds, linux-kernel On Thu, 2 Nov 2006, David Brownell wrote: > On Thursday 02 November 2006 6:27 pm, Adrian Bunk wrote: > > > It seems to lack the "select MII" at the USB_RTL8150 option that was in > > Randy's first patch? > > I was just addressing the usbnet issues ... that driver doesn't > use the usbnet framework. and Randy is away for a few days with very limited net access. -- ~Randy ^ permalink raw reply [flat|nested] 152+ messages in thread
* [2.6 patch] USB_RTL8150 must select MII 2006-11-03 2:47 ` David Brownell 2006-11-03 2:58 ` Randy.Dunlap @ 2006-11-04 2:51 ` Adrian Bunk 1 sibling, 0 replies; 152+ messages in thread From: Adrian Bunk @ 2006-11-04 2:51 UTC (permalink / raw) To: David Brownell Cc: Greg KH, Randy Dunlap, toralf.foerster, netdev, linux-usb-devel, link, akpm, zippel, torvalds, linux-kernel On Thu, Nov 02, 2006 at 06:47:15PM -0800, David Brownell wrote: > On Thursday 02 November 2006 6:27 pm, Adrian Bunk wrote: > > > It seems to lack the "select MII" at the USB_RTL8150 option that was in > > Randy's first patch? > > I was just addressing the usbnet issues ... that driver doesn't > use the usbnet framework. OK, the patch for this driver is below. > - Dave cu Adrian <-- snip --> USB_RTL8150 must select MII to avoid link errors. Stolen from a patch by Randy Dunlap. Signed-off-by: Adrian Bunk <bunk@stusta.de> --- linux-2619-rc3-pv.orig/drivers/usb/net/Kconfig +++ linux-2619-rc3-pv/drivers/usb/net/Kconfig @@ -84,6 +84,7 @@ config USB_PEGASUS config USB_RTL8150 tristate "USB RTL8150 based ethernet device support (EXPERIMENTAL)" depends on EXPERIMENTAL + select MII help Say Y here if you have RTL8150 based usb-ethernet adapter. Send me <petkan@users.sourceforge.net> any comments you may have. ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled 2006-10-25 23:58 ` [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled Randy Dunlap 2006-10-26 2:22 ` David Brownell @ 2006-10-26 15:46 ` Adrian Bunk 2006-10-26 15:51 ` Randy.Dunlap 2006-10-28 11:21 ` Christoph Hellwig 2 siblings, 1 reply; 152+ messages in thread From: Adrian Bunk @ 2006-10-26 15:46 UTC (permalink / raw) To: Randy Dunlap Cc: David Brownell, toralf.foerster, netdev, linux-usb-devel, link, greg, akpm, zippel, torvalds, linux-kernel, dbrownell, Arnd Bergmann On Wed, Oct 25, 2006 at 04:58:58PM -0700, Randy Dunlap wrote: >... > Build tested with CONFIG_MII=y, m, n. >... > --- linux-2619-rc3-pv.orig/drivers/usb/net/usbnet.c > +++ linux-2619-rc3-pv/drivers/usb/net/usbnet.c > @@ -47,6 +47,12 @@ > > #define DRIVER_VERSION "22-Aug-2005" > > +#if defined(CONFIG_MII) || defined(CONFIG_MII_MODULE) > +#define HAVE_MII 1 > +#else > +#define HAVE_MII 0 > +#endif >... I'm too lame to test it, but I bet this will break with CONFIG_USB_USBNET=y, CONFIG_MII=m, and you'll actually need #if defined(CONFIG_MII) || (defined(CONFIG_MII_MODULE) && defined(MODULE)) And then there's the question whether this amount of #ifdef's is actually worth avoiding the "select MII"... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled 2006-10-26 15:46 ` [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled Adrian Bunk @ 2006-10-26 15:51 ` Randy.Dunlap 0 siblings, 0 replies; 152+ messages in thread From: Randy.Dunlap @ 2006-10-26 15:51 UTC (permalink / raw) To: Adrian Bunk Cc: David Brownell, toralf.foerster, netdev, linux-usb-devel, link, greg, akpm, zippel, torvalds, linux-kernel, dbrownell, Arnd Bergmann Adrian Bunk wrote: > On Wed, Oct 25, 2006 at 04:58:58PM -0700, Randy Dunlap wrote: >> ... >> Build tested with CONFIG_MII=y, m, n. >> ... >> --- linux-2619-rc3-pv.orig/drivers/usb/net/usbnet.c >> +++ linux-2619-rc3-pv/drivers/usb/net/usbnet.c >> @@ -47,6 +47,12 @@ >> >> #define DRIVER_VERSION "22-Aug-2005" >> >> +#if defined(CONFIG_MII) || defined(CONFIG_MII_MODULE) >> +#define HAVE_MII 1 >> +#else >> +#define HAVE_MII 0 >> +#endif >> ... > > I'm too lame to test it, but I bet this will break with > CONFIG_USB_USBNET=y, CONFIG_MII=m, and you'll actually need > > #if defined(CONFIG_MII) || (defined(CONFIG_MII_MODULE) && defined(MODULE)) > > And then there's the question whether this amount of #ifdef's is > actually worth avoiding the "select MII"... Thanks, but that's OK, David posted a different patch for it. -- ~Randy ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled 2006-10-25 23:58 ` [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled Randy Dunlap 2006-10-26 2:22 ` David Brownell 2006-10-26 15:46 ` [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled Adrian Bunk @ 2006-10-28 11:21 ` Christoph Hellwig 2006-10-28 21:10 ` David Brownell 2 siblings, 1 reply; 152+ messages in thread From: Christoph Hellwig @ 2006-10-28 11:21 UTC (permalink / raw) To: Randy Dunlap Cc: David Brownell, toralf.foerster, netdev, linux-usb-devel, link, greg, akpm, zippel, torvalds, linux-kernel, dbrownell On Wed, Oct 25, 2006 at 04:58:58PM -0700, Randy Dunlap wrote: > On Wed, 25 Oct 2006 15:27:09 -0700 David Brownell wrote: > > > Instead, "usbnet.c" should #ifdef the relevant ethtool hooks > > according to CONFIG_MII ... since it's completely legit to > > use usbnet with peripherals that don't need MII. > > --- > From: Randy Dunlap <randy.dunlap@oracle.com> > > usbnet driver should use mii_*() interfaces if they are available > in the kernel (config enabled) but usbnet does not require or depend > on these interfaces. > > Build tested with CONFIG_MII=y, m, n. This is really awkward and against what we do in any other driver. Lots of PCI ethernet drivers use the MII code but have non-MII variants, and I'd expect usb code to do the same. If you really need to squeeze the last bytes out of usbnet for some embedded thing add a CONFIG_USB_NET_MII opention and explain in the help text which devices require it. Otherwise a normal user has no way to find out why his mii-requiring usb device randomly stopped working. > > Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> > --- > drivers/usb/net/usbnet.c | 18 ++++++++++++++++++ > 1 file changed, 18 insertions(+) > > --- linux-2619-rc3-pv.orig/drivers/usb/net/usbnet.c > +++ linux-2619-rc3-pv/drivers/usb/net/usbnet.c > @@ -47,6 +47,12 @@ > > #define DRIVER_VERSION "22-Aug-2005" > > +#if defined(CONFIG_MII) || defined(CONFIG_MII_MODULE) > +#define HAVE_MII 1 > +#else > +#define HAVE_MII 0 > +#endif > + > > /*-------------------------------------------------------------------------*/ > > @@ -676,7 +682,10 @@ int usbnet_get_settings (struct net_devi > if (!dev->mii.mdio_read) > return -EOPNOTSUPP; > > +#if HAVE_MII > return mii_ethtool_gset(&dev->mii, cmd); > +#endif > + return -EOPNOTSUPP; > } > EXPORT_SYMBOL_GPL(usbnet_get_settings); > > @@ -688,7 +697,11 @@ int usbnet_set_settings (struct net_devi > if (!dev->mii.mdio_write) > return -EOPNOTSUPP; > > +#if HAVE_MII > retval = mii_ethtool_sset(&dev->mii, cmd); > +#else > + retval = -EOPNOTSUPP; > +#endif > > /* link speed/duplex might have changed */ > if (dev->driver_info->link_reset) > @@ -721,9 +734,11 @@ u32 usbnet_get_link (struct net_device * > if (dev->driver_info->check_connect) > return dev->driver_info->check_connect (dev) == 0; > > +#if HAVE_MII > /* if the device has mii operations, use those */ > if (dev->mii.mdio_read) > return mii_link_ok(&dev->mii); > +#endif > > /* Otherwise, say we're up (to avoid breaking scripts) */ > return 1; > @@ -753,7 +768,10 @@ int usbnet_nway_reset(struct net_device > if (!dev->mii.mdio_write) > return -EOPNOTSUPP; > > +#if HAVE_MII > return mii_nway_restart(&dev->mii); > +#endif > + return -EOPNOTSUPP; > } > EXPORT_SYMBOL_GPL(usbnet_nway_reset); > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ---end quoted text--- ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled 2006-10-28 11:21 ` Christoph Hellwig @ 2006-10-28 21:10 ` David Brownell 2006-10-28 21:13 ` Christoph Hellwig 2006-10-28 21:39 ` Adrian Bunk 0 siblings, 2 replies; 152+ messages in thread From: David Brownell @ 2006-10-28 21:10 UTC (permalink / raw) To: Christoph Hellwig Cc: Randy Dunlap, toralf.foerster, netdev, linux-usb-devel, link, greg, akpm, zippel, torvalds, linux-kernel On Saturday 28 October 2006 4:21 am, Christoph Hellwig wrote: > This is really awkward and against what we do in any other driver. Awkward, yes -- which is why I posted the non-awkward version, which is repeated below. (No thanks to "diff" for making the patch ugly though; the resulting code is clean and non-awkward, moving that function helped.) Against what other drivers do? Since "usbnet.c" is infrastructure code, not a driver, your comment can't apply. Infrastructure uses conditional compilation routinely in such cases. But remember that the actual drivers follow the standard convention ("select MII") given Randy's patch #1 of 2. - Dave ------------------------- The usbnet infrastructure must not reference MII symbols unless they're provided in the kernel being built. This extends also to the ethtool hooks that reference those symbols. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Index: g26/drivers/usb/net/usbnet.c =================================================================== --- g26.orig/drivers/usb/net/usbnet.c 2006-10-24 18:29:28.000000000 -0700 +++ g26/drivers/usb/net/usbnet.c 2006-10-25 19:07:16.000000000 -0700 @@ -669,6 +669,9 @@ done: * they'll probably want to use this base set. */ +#if defined(CONFIG_MII) || defined(CONFIG_MII_MODULE) +#define HAVE_MII + int usbnet_get_settings (struct net_device *net, struct ethtool_cmd *cmd) { struct usbnet *dev = netdev_priv(net); @@ -699,20 +702,6 @@ int usbnet_set_settings (struct net_devi } EXPORT_SYMBOL_GPL(usbnet_set_settings); - -void usbnet_get_drvinfo (struct net_device *net, struct ethtool_drvinfo *info) -{ - struct usbnet *dev = netdev_priv(net); - - /* REVISIT don't always return "usbnet" */ - strncpy (info->driver, driver_name, sizeof info->driver); - strncpy (info->version, DRIVER_VERSION, sizeof info->version); - strncpy (info->fw_version, dev->driver_info->description, - sizeof info->fw_version); - usb_make_path (dev->udev, info->bus_info, sizeof info->bus_info); -} -EXPORT_SYMBOL_GPL(usbnet_get_drvinfo); - u32 usbnet_get_link (struct net_device *net) { struct usbnet *dev = netdev_priv(net); @@ -730,40 +719,57 @@ u32 usbnet_get_link (struct net_device * } EXPORT_SYMBOL_GPL(usbnet_get_link); -u32 usbnet_get_msglevel (struct net_device *net) +int usbnet_nway_reset(struct net_device *net) { struct usbnet *dev = netdev_priv(net); - return dev->msg_enable; + if (!dev->mii.mdio_write) + return -EOPNOTSUPP; + + return mii_nway_restart(&dev->mii); } -EXPORT_SYMBOL_GPL(usbnet_get_msglevel); +EXPORT_SYMBOL_GPL(usbnet_nway_reset); -void usbnet_set_msglevel (struct net_device *net, u32 level) +#endif /* HAVE_MII */ + +void usbnet_get_drvinfo (struct net_device *net, struct ethtool_drvinfo *info) { struct usbnet *dev = netdev_priv(net); - dev->msg_enable = level; + /* REVISIT don't always return "usbnet" */ + strncpy (info->driver, driver_name, sizeof info->driver); + strncpy (info->version, DRIVER_VERSION, sizeof info->version); + strncpy (info->fw_version, dev->driver_info->description, + sizeof info->fw_version); + usb_make_path (dev->udev, info->bus_info, sizeof info->bus_info); } -EXPORT_SYMBOL_GPL(usbnet_set_msglevel); +EXPORT_SYMBOL_GPL(usbnet_get_drvinfo); -int usbnet_nway_reset(struct net_device *net) +u32 usbnet_get_msglevel (struct net_device *net) { struct usbnet *dev = netdev_priv(net); - if (!dev->mii.mdio_write) - return -EOPNOTSUPP; + return dev->msg_enable; +} +EXPORT_SYMBOL_GPL(usbnet_get_msglevel); - return mii_nway_restart(&dev->mii); +void usbnet_set_msglevel (struct net_device *net, u32 level) +{ + struct usbnet *dev = netdev_priv(net); + + dev->msg_enable = level; } -EXPORT_SYMBOL_GPL(usbnet_nway_reset); +EXPORT_SYMBOL_GPL(usbnet_set_msglevel); /* drivers may override default ethtool_ops in their bind() routine */ static struct ethtool_ops usbnet_ethtool_ops = { +#ifdef HAVE_MII .get_settings = usbnet_get_settings, .set_settings = usbnet_set_settings, - .get_drvinfo = usbnet_get_drvinfo, .get_link = usbnet_get_link, .nway_reset = usbnet_nway_reset, +#endif + .get_drvinfo = usbnet_get_drvinfo, .get_msglevel = usbnet_get_msglevel, .set_msglevel = usbnet_set_msglevel, }; ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled 2006-10-28 21:10 ` David Brownell @ 2006-10-28 21:13 ` Christoph Hellwig 2006-10-28 22:30 ` David Brownell 2006-10-28 21:39 ` Adrian Bunk 1 sibling, 1 reply; 152+ messages in thread From: Christoph Hellwig @ 2006-10-28 21:13 UTC (permalink / raw) To: David Brownell Cc: Christoph Hellwig, Randy Dunlap, toralf.foerster, netdev, linux-usb-devel, link, greg, akpm, zippel, torvalds, linux-kernel On Sat, Oct 28, 2006 at 02:10:09PM -0700, David Brownell wrote: > On Saturday 28 October 2006 4:21 am, Christoph Hellwig wrote: > > > This is really awkward and against what we do in any other driver. > > Awkward, yes -- which is why I posted the non-awkward version, > which is repeated below. (No thanks to "diff" for making the > patch ugly though; the resulting code is clean and non-awkward, > moving that function helped.) > > Against what other drivers do? Since "usbnet.c" is infrastructure > code, not a driver, your comment can't apply. Infrastructure uses > conditional compilation routinely in such cases. > > But remember that the actual drivers follow the standard convention > ("select MII") given Randy's patch #1 of 2. Ah sorry - I missed that. I still don't quite like the approach. What about simply putting the mii using functions into usbnet-mii.c and let makefile doing all the work? This would require a second set of ethtool ops, but I'd actually consider that a cleanup, as it makes clear which one we're using and allows to kill all the checks for non-mii hardware in the methods. ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled 2006-10-28 21:13 ` Christoph Hellwig @ 2006-10-28 22:30 ` David Brownell 0 siblings, 0 replies; 152+ messages in thread From: David Brownell @ 2006-10-28 22:30 UTC (permalink / raw) To: Christoph Hellwig Cc: akpm, greg, link, linux-kernel, netdev, Randy Dunlap, toralf.foerster, torvalds, zippel On Saturday 28 October 2006 2:13 pm, Christoph Hellwig wrote: > > I still don't quite like the approach. What about simply putting > the mii using functions into usbnet-mii.c and let makefile doing > all the work? This would require a second set of ethtool ops, > but I'd actually consider that a cleanup, as it makes clear which > one we're using and allows to kill all the checks for non-mii > hardware in the methods. Feel free to do such a patch yourself, so long as the MII doesn't go into a separate module. You'll have to also modify the two Ethernet adapters currently using that usbnet core code (and MII). That'd still feel like needless complexity to me, though. So unless you're keen on doing that quickly, I'd say to just merge the two existing patches and be done with it. - Dave ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled 2006-10-28 21:10 ` David Brownell 2006-10-28 21:13 ` Christoph Hellwig @ 2006-10-28 21:39 ` Adrian Bunk 2006-10-31 17:40 ` [linux-usb-devel] " David Brownell 1 sibling, 1 reply; 152+ messages in thread From: Adrian Bunk @ 2006-10-28 21:39 UTC (permalink / raw) To: David Brownell Cc: Christoph Hellwig, Randy Dunlap, toralf.foerster, netdev, linux-usb-devel, link, greg, akpm, zippel, torvalds, linux-kernel On Sat, Oct 28, 2006 at 02:10:09PM -0700, David Brownell wrote: > On Saturday 28 October 2006 4:21 am, Christoph Hellwig wrote: > > > This is really awkward and against what we do in any other driver. > > Awkward, yes -- which is why I posted the non-awkward version, > which is repeated below. (No thanks to "diff" for making the > patch ugly though; the resulting code is clean and non-awkward, > moving that function helped.) >... > --- g26.orig/drivers/usb/net/usbnet.c 2006-10-24 18:29:28.000000000 -0700 > +++ g26/drivers/usb/net/usbnet.c 2006-10-25 19:07:16.000000000 -0700 > @@ -669,6 +669,9 @@ done: > * they'll probably want to use this base set. > */ > > +#if defined(CONFIG_MII) || defined(CONFIG_MII_MODULE) > +#define HAVE_MII >... This seems to cause a CONFIG_USB_USBNET=y, CONFIG_MII=m breakage (as already described earlier in this thread)? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [linux-usb-devel] [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled 2006-10-28 21:39 ` Adrian Bunk @ 2006-10-31 17:40 ` David Brownell 2006-10-31 18:07 ` Adrian Bunk 0 siblings, 1 reply; 152+ messages in thread From: David Brownell @ 2006-10-31 17:40 UTC (permalink / raw) To: linux-usb-devel Cc: Adrian Bunk, Randy Dunlap, akpm, zippel, netdev, linux-kernel, link, Christoph Hellwig, torvalds, greg, toralf.foerster > > +#if defined(CONFIG_MII) || defined(CONFIG_MII_MODULE) > > +#define HAVE_MII > >... > > This seems to cause a CONFIG_USB_USBNET=y, CONFIG_MII=m breakage > (as already described earlier in this thread)? Well, "alluded to" not described. Fixable by the equivalent of config USB_USBNET ... depends on MII if MII != n except that Kconfig doesn't comprehend conditionals like that. ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [linux-usb-devel] [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled 2006-10-31 17:40 ` [linux-usb-devel] " David Brownell @ 2006-10-31 18:07 ` Adrian Bunk 2006-10-31 19:36 ` David Brownell 0 siblings, 1 reply; 152+ messages in thread From: Adrian Bunk @ 2006-10-31 18:07 UTC (permalink / raw) To: David Brownell Cc: linux-usb-devel, Randy Dunlap, akpm, zippel, netdev, linux-kernel, link, Christoph Hellwig, torvalds, greg, toralf.foerster On Tue, Oct 31, 2006 at 10:40:15AM -0700, David Brownell wrote: > > > > +#if defined(CONFIG_MII) || defined(CONFIG_MII_MODULE) > > > +#define HAVE_MII > > >... > > > > This seems to cause a CONFIG_USB_USBNET=y, CONFIG_MII=m breakage > > (as already described earlier in this thread)? > > Well, "alluded to" not described. Fixable by the equivalent of > > config USB_USBNET > ... > depends on MII if MII != n > > except that Kconfig doesn't comprehend conditionals like that. You can express this in Kconfig: depends MII || MII=n But my suggestion was: #if defined(CONFIG_MII) || (defined(CONFIG_MII_MODULE) && defined(MODULE)) Or simply select MII ... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [linux-usb-devel] [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled 2006-10-31 18:07 ` Adrian Bunk @ 2006-10-31 19:36 ` David Brownell 2006-11-01 1:23 ` Adrian Bunk 0 siblings, 1 reply; 152+ messages in thread From: David Brownell @ 2006-10-31 19:36 UTC (permalink / raw) To: Adrian Bunk Cc: linux-usb-devel, Randy Dunlap, akpm, zippel, netdev, linux-kernel, link, Christoph Hellwig, torvalds, greg, toralf.foerster > > ... > > depends on MII if MII != n > > > > except that Kconfig doesn't comprehend conditionals like that. > > You can express this in Kconfig: > depends MII || MII=n Except that: Warning! Found recursive dependency: USB_USBNET USB_NET_AX8817X MII USB_USBNET I think this is another case where Kconfig gets in the way and forces introduction of a pseudovariable. I'll give that a try. > But my suggestion was: > #if defined(CONFIG_MII) || (defined(CONFIG_MII_MODULE) && defined(MODULE)) > > Or simply select MII ... Nope; those both prevent completely legit configurations. MII is not required, except for those two adapter options. ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [linux-usb-devel] [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled 2006-10-31 19:36 ` David Brownell @ 2006-11-01 1:23 ` Adrian Bunk 2006-11-02 20:19 ` David Brownell 0 siblings, 1 reply; 152+ messages in thread From: Adrian Bunk @ 2006-11-01 1:23 UTC (permalink / raw) To: David Brownell Cc: linux-usb-devel, Randy Dunlap, akpm, zippel, netdev, linux-kernel, link, Christoph Hellwig, torvalds, greg, toralf.foerster On Tue, Oct 31, 2006 at 11:36:52AM -0800, David Brownell wrote: > > > > ... > > > depends on MII if MII != n > > > > > > except that Kconfig doesn't comprehend conditionals like that. > > > > You can express this in Kconfig: > > depends MII || MII=n > > Except that: > > Warning! Found recursive dependency: USB_USBNET USB_NET_AX8817X MII USB_USBNET > > I think this is another case where Kconfig gets in the way and forces > introduction of a pseudovariable. I'll give that a try. > > > But my suggestion was: > > #if defined(CONFIG_MII) || (defined(CONFIG_MII_MODULE) && defined(MODULE)) > > > > Or simply select MII ... > > Nope; those both prevent completely legit configurations. > MII is not required, except for those two adapter options. What should work (with the USB_NET_MCS7830 part from Randy's patch removed) together with your patch and the #if defined(CONFIG_MII) || (defined(CONFIG_MII_MODULE) && defined(MODULE)) is: config USB_USBNET tristate "Multi-purpose USB Networking Framework" select MII if USB_NET_AX8817X!=n || USB_NET_MCS7830!=n ---help--- ... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [linux-usb-devel] [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled 2006-11-01 1:23 ` Adrian Bunk @ 2006-11-02 20:19 ` David Brownell 0 siblings, 0 replies; 152+ messages in thread From: David Brownell @ 2006-11-02 20:19 UTC (permalink / raw) To: Adrian Bunk Cc: linux-usb-devel, Randy Dunlap, akpm, zippel, netdev, linux-kernel, link, Christoph Hellwig, torvalds, greg, toralf.foerster On Tuesday 31 October 2006 5:23 pm, Adrian Bunk wrote: > select MII if USB_NET_AX8817X!=n || USB_NET_MCS7830!=n Thing is, I'm seeing that get morphed inside Kconfig to "select MII" in some cases ... the "if x != n" gets ignored, MII can't be deselected. That looks to me like a Kconfig dependency engine bug, so I'm just noting it here rather than fixing it. I guess it's not quite enough of a Prolog engine ... ;) - Dave ^ permalink raw reply [flat|nested] 152+ messages in thread
* [PATCH 1/2] !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB 2006-10-25 22:27 ` David Brownell @ 2006-10-25 23:59 ` Randy Dunlap -1 siblings, 0 replies; 152+ messages in thread From: Randy Dunlap @ 2006-10-25 23:59 UTC (permalink / raw) To: David Brownell Cc: toralf.foerster, netdev, linux-usb-devel, link, greg, akpm, zippel, torvalds, linux-kernel, dbrownell On Wed, 25 Oct 2006 15:27:09 -0700 David Brownell wrote: > The other parts are right, this isn't. > > Instead, "usbnet.c" should #ifdef the relevant ethtool hooks > according to CONFIG_MII ... since it's completely legit to > use usbnet with peripherals that don't need MII. Ugh. OK. How's this? (2 patches) (oh, OP mentioned CONFIG_PHYLIB but it's actually CONFIG_MII AFAIK) --- From: Randy Dunlap <randy.dunlap@oracle.com> pegasus and mcs7830 drivers use MII interfaces and should select MII in the same way that drivers/net/ drivers do. However, the MII config symbol should not be in the 10/100 Ethernet menu, so that other drivers can use (enable) it or so that users can enable it without needing to enable 10/100 Ethernet. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> --- drivers/net/Kconfig | 15 +++++++-------- drivers/usb/net/Kconfig | 2 ++ 2 files changed, 9 insertions(+), 8 deletions(-) --- linux-2619-rc3-pv.orig/drivers/usb/net/Kconfig +++ linux-2619-rc3-pv/drivers/usb/net/Kconfig @@ -84,6 +84,7 @@ config USB_PEGASUS config USB_RTL8150 tristate "USB RTL8150 based ethernet device support (EXPERIMENTAL)" depends on EXPERIMENTAL + select MII help Say Y here if you have RTL8150 based usb-ethernet adapter. Send me <petkan@users.sourceforge.net> any comments you may have. @@ -210,6 +211,7 @@ config USB_NET_PLUSB config USB_NET_MCS7830 tristate "MosChip MCS7830 based Ethernet adapters" depends on USB_USBNET + select MII help Choose this option if you're using a 10/100 Ethernet USB2 adapter based on the MosChip 7830 controller. This includes --- linux-2619-rc3-pv.orig/drivers/net/Kconfig +++ linux-2619-rc3-pv/drivers/net/Kconfig @@ -145,6 +145,13 @@ config NET_SB1000 source "drivers/net/arcnet/Kconfig" +config MII + tristate "Generic Media Independent Interface device support" + help + Most ethernet controllers have MII transceiver either as an external + or internal device. It is safe to say Y or M here even if your + ethernet card lacks MII. + source "drivers/net/phy/Kconfig" # @@ -180,14 +187,6 @@ config NET_ETHERNET kernel: saying N will just cause the configurator to skip all the questions about Ethernet network cards. If unsure, say N. -config MII - tristate "Generic Media Independent Interface device support" - depends on NET_ETHERNET - help - Most ethernet controllers have MII transceiver either as an external - or internal device. It is safe to say Y or M here even if your - ethernet card lack MII. - source "drivers/net/arm/Kconfig" config MACE ^ permalink raw reply [flat|nested] 152+ messages in thread
* [PATCH 1/2] !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB @ 2006-10-25 23:59 ` Randy Dunlap 0 siblings, 0 replies; 152+ messages in thread From: Randy Dunlap @ 2006-10-25 23:59 UTC (permalink / raw) To: David Brownell Cc: toralf.foerster, netdev, linux-usb-devel, link, greg, akpm, zippel, torvalds, linux-kernel, dbrownell On Wed, 25 Oct 2006 15:27:09 -0700 David Brownell wrote: > The other parts are right, this isn't. > > Instead, "usbnet.c" should #ifdef the relevant ethtool hooks > according to CONFIG_MII ... since it's completely legit to > use usbnet with peripherals that don't need MII. Ugh. OK. How's this? (2 patches) (oh, OP mentioned CONFIG_PHYLIB but it's actually CONFIG_MII AFAIK) --- From: Randy Dunlap <randy.dunlap@oracle.com> pegasus and mcs7830 drivers use MII interfaces and should select MII in the same way that drivers/net/ drivers do. However, the MII config symbol should not be in the 10/100 Ethernet menu, so that other drivers can use (enable) it or so that users can enable it without needing to enable 10/100 Ethernet. Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> --- drivers/net/Kconfig | 15 +++++++-------- drivers/usb/net/Kconfig | 2 ++ 2 files changed, 9 insertions(+), 8 deletions(-) --- linux-2619-rc3-pv.orig/drivers/usb/net/Kconfig +++ linux-2619-rc3-pv/drivers/usb/net/Kconfig @@ -84,6 +84,7 @@ config USB_PEGASUS config USB_RTL8150 tristate "USB RTL8150 based ethernet device support (EXPERIMENTAL)" depends on EXPERIMENTAL + select MII help Say Y here if you have RTL8150 based usb-ethernet adapter. Send me <petkan@users.sourceforge.net> any comments you may have. @@ -210,6 +211,7 @@ config USB_NET_PLUSB config USB_NET_MCS7830 tristate "MosChip MCS7830 based Ethernet adapters" depends on USB_USBNET + select MII help Choose this option if you're using a 10/100 Ethernet USB2 adapter based on the MosChip 7830 controller. This includes --- linux-2619-rc3-pv.orig/drivers/net/Kconfig +++ linux-2619-rc3-pv/drivers/net/Kconfig @@ -145,6 +145,13 @@ config NET_SB1000 source "drivers/net/arcnet/Kconfig" +config MII + tristate "Generic Media Independent Interface device support" + help + Most ethernet controllers have MII transceiver either as an external + or internal device. It is safe to say Y or M here even if your + ethernet card lacks MII. + source "drivers/net/phy/Kconfig" # @@ -180,14 +187,6 @@ config NET_ETHERNET kernel: saying N will just cause the configurator to skip all the questions about Ethernet network cards. If unsure, say N. -config MII - tristate "Generic Media Independent Interface device support" - depends on NET_ETHERNET - help - Most ethernet controllers have MII transceiver either as an external - or internal device. It is safe to say Y or M here even if your - ethernet card lack MII. - source "drivers/net/arm/Kconfig" config MACE ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [PATCH 1/2] !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB 2006-10-25 23:59 ` Randy Dunlap (?) @ 2006-10-26 2:24 ` David Brownell 2006-10-26 5:05 ` Randy.Dunlap -1 siblings, 1 reply; 152+ messages in thread From: David Brownell @ 2006-10-26 2:24 UTC (permalink / raw) To: Randy Dunlap Cc: toralf.foerster, netdev, linux-usb-devel, link, greg, akpm, zippel, torvalds, linux-kernel, dbrownell On Wednesday 25 October 2006 4:59 pm, Randy Dunlap wrote: > On Wed, 25 Oct 2006 15:27:09 -0700 David Brownell wrote: > > > The other parts are right, this isn't. > > > > Instead, "usbnet.c" should #ifdef the relevant ethtool hooks > > according to CONFIG_MII ... since it's completely legit to > > use usbnet with peripherals that don't need MII. > > Ugh. OK. How's this? (2 patches) Looks about right, but ... > However, the MII config symbol should not be in the 10/100 Ethernet > menu, so that other drivers can use (enable) it or so that users > can enable it without needing to enable 10/100 Ethernet. ... MII should still depend on ETHERNET, right? Just not limited to 10/100 Ethernet. > --- linux-2619-rc3-pv.orig/drivers/net/Kconfig > +++ linux-2619-rc3-pv/drivers/net/Kconfig > @@ -145,6 +145,13 @@ config NET_SB1000 > > source "drivers/net/arcnet/Kconfig" > > +config MII > + tristate "Generic Media Independent Interface device support" > + help > + Most ethernet controllers have MII transceiver either as an external > + or internal device. It is safe to say Y or M here even if your > + ethernet card lacks MII. > + > source "drivers/net/phy/Kconfig" > > # > @@ -180,14 +187,6 @@ config NET_ETHERNET > kernel: saying N will just cause the configurator to skip all > the questions about Ethernet network cards. If unsure, say N. > > -config MII > - tristate "Generic Media Independent Interface device support" > - depends on NET_ETHERNET > - help > - Most ethernet controllers have MII transceiver either as an external > - or internal device. It is safe to say Y or M here even if your > - ethernet card lack MII. > - > source "drivers/net/arm/Kconfig" > > config MACE > ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [PATCH 1/2] !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB 2006-10-26 2:24 ` David Brownell @ 2006-10-26 5:05 ` Randy.Dunlap 2006-10-26 5:24 ` David Brownell 0 siblings, 1 reply; 152+ messages in thread From: Randy.Dunlap @ 2006-10-26 5:05 UTC (permalink / raw) To: David Brownell Cc: toralf.foerster, netdev, linux-usb-devel, link, greg, akpm, zippel, torvalds, linux-kernel, dbrownell David Brownell wrote: > On Wednesday 25 October 2006 4:59 pm, Randy Dunlap wrote: >> On Wed, 25 Oct 2006 15:27:09 -0700 David Brownell wrote: >> >>> The other parts are right, this isn't. >>> >>> Instead, "usbnet.c" should #ifdef the relevant ethtool hooks >>> according to CONFIG_MII ... since it's completely legit to >>> use usbnet with peripherals that don't need MII. >> Ugh. OK. How's this? (2 patches) > > Looks about right, but ... > > >> However, the MII config symbol should not be in the 10/100 Ethernet >> menu, so that other drivers can use (enable) it or so that users >> can enable it without needing to enable 10/100 Ethernet. > > ... MII should still depend on ETHERNET, right? > Just not limited to 10/100 Ethernet. There is no such config symbol. NET_ETHERNET means 10/100 ethernet. Gigabit ethernet doesn't use the ETHERNET symbol (and doesn't use this flavor of MII IIRC). And all of this config space is surrounded by: # All the following symbols are dependent on NETDEVICES - do not repeat # that for each of the symbols. if NETDEVICES so it is actually config MII depends on NETDEVICES What do you suggest? >> --- linux-2619-rc3-pv.orig/drivers/net/Kconfig >> +++ linux-2619-rc3-pv/drivers/net/Kconfig >> @@ -145,6 +145,13 @@ config NET_SB1000 >> >> source "drivers/net/arcnet/Kconfig" >> >> +config MII >> + tristate "Generic Media Independent Interface device support" >> + help >> + Most ethernet controllers have MII transceiver either as an external >> + or internal device. It is safe to say Y or M here even if your >> + ethernet card lacks MII. >> + >> source "drivers/net/phy/Kconfig" >> >> # >> @@ -180,14 +187,6 @@ config NET_ETHERNET >> kernel: saying N will just cause the configurator to skip all >> the questions about Ethernet network cards. If unsure, say N. >> >> -config MII >> - tristate "Generic Media Independent Interface device support" >> - depends on NET_ETHERNET >> - help >> - Most ethernet controllers have MII transceiver either as an external >> - or internal device. It is safe to say Y or M here even if your >> - ethernet card lack MII. >> - >> source "drivers/net/arm/Kconfig" >> >> config MACE >> -- ~Randy ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [PATCH 1/2] !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB 2006-10-26 5:05 ` Randy.Dunlap @ 2006-10-26 5:24 ` David Brownell 0 siblings, 0 replies; 152+ messages in thread From: David Brownell @ 2006-10-26 5:24 UTC (permalink / raw) To: Randy.Dunlap Cc: toralf.foerster, netdev, linux-usb-devel, link, greg, akpm, zippel, torvalds, linux-kernel, dbrownell On Wednesday 25 October 2006 10:05 pm, Randy.Dunlap wrote: > > > > ... MII should still depend on ETHERNET, right? > > Just not limited to 10/100 Ethernet. > > There is no such config symbol. NET_ETHERNET means 10/100 ethernet. > Gigabit ethernet doesn't use the ETHERNET symbol (and doesn't use > this flavor of MII IIRC). Ah, you're right -- sorry. Only Kconfig and net/ipv4/arp.c even look for that config symbol. - Dave ^ permalink raw reply [flat|nested] 152+ messages in thread
* 2.6.19-rc3: known unfixed regressions (v2) 2006-10-23 23:22 Linux 2.6.19-rc3 Linus Torvalds 2006-10-24 2:24 ` Gene Heskett @ 2006-10-26 22:45 ` Adrian Bunk 2006-10-24 20:21 ` Adrian Bunk ` (5 subsequent siblings) 7 siblings, 0 replies; 152+ messages in thread From: Adrian Bunk @ 2006-10-26 22:45 UTC (permalink / raw) To: Linus Torvalds, Andrew Morton Cc: Linux Kernel Mailing List, Pavel Machek, Greg KH, linux-pci, Stephen Hemminger, Philipp Zabel, rmk, Martin Lorenz, len.brown, linux-acpi, linux-pm, Michael S. Tsirkin, Thierry Vignaud, jgarzik, linux-ide, Alex Romosan, Jens Axboe, Komuro, Thomas Gleixner, Benjamin Herrenschmidt, Stefan Richter, linux1394-devel, Christian, Mark Langsdorf, davej This email lists some known regressions in 2.6.19-rc3 compared to 2.6.18 that are not yet fixed Linus' tree. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject : swsusp initialized after SATA (CONFIG_PCI_MULTITHREAD_PROBE) References : http://lkml.org/lkml/2006/10/14/31 Submitter : Pavel Machek <pavel@ucw.cz> Status : unknown Subject : MSI errors during boot (CONFIG_PCI_MULTITHREAD_PROBE) References : http://lkml.org/lkml/2006/10/16/291 Submitter : Stephen Hemminger <shemminger@osdl.org> Handled-By : Greg KH <greg@kroah.com> Status : Greg is working on a fix Subject : arm: Oops in __wake_up_common during htc magician resume References : http://lkml.org/lkml/2006/10/25/73 Submitter : Philipp Zabel <philipp.zabel@gmail.com> Status : unknown Subject : X60s: BUG()s, lose ACPI events after suspend/resume References : http://lkml.org/lkml/2006/10/10/39 Submitter : Martin Lorenz <martin@lorenz.eu.org> Status : unknown Subject : T60 stops triggering any ACPI events References : http://lkml.org/lkml/2006/10/4/425 http://lkml.org/lkml/2006/10/16/262 http://bugzilla.kernel.org/show_bug.cgi?id=7408 Submitter : "Michael S. Tsirkin" <mst@mellanox.co.il> Status : unknown Subject : sata-via doesn't detect anymore disks attached to VIA vt6421 References : http://bugzilla.kernel.org/show_bug.cgi?id=7255 Submitter : Thierry Vignaud <tvignaud@mandriva.com> Status : unknown Subject : unable to rip cd References : http://lkml.org/lkml/2006/10/13/100 Submitter : Alex Romosan <romosan@sycorax.lbl.gov> Status : unknown Subject : SMP kernel can not generate ISA irq properly References : http://lkml.org/lkml/2006/10/22/15 Submitter : Komuro <komurojun-mbn@nifty.com> Handled-By : Thomas Gleixner <tglx@linutronix.de> Status : Thomas will investigate Subject : ohci1394 on PPC_PMAC: pci_set_power_state() failure and breaking suspend References : http://lkml.org/lkml/2006/10/24/13 Submitter : Benjamin Herrenschmidt <benh@kernel.crashing.org> Caused-By : Stefan Richter <stefanr@s5r6.in-berlin.de> commit ea6104c22468239083857fa07425c312b1ecb424 Handled-By : Stefan Richter <stefanr@s5r6.in-berlin.de> Status : Stefan Richter: looking for an answer when to ignore the return code of pci_set_power_state Subject : cpufreq not working on AMD K8 References : http://lkml.org/lkml/2006/10/10/114 Submitter : Christian <christiand59@web.de> Handled-By : Mark Langsdorf <mark.langsdorf@amd.com> Status : Mark is investigating ^ permalink raw reply [flat|nested] 152+ messages in thread
* 2.6.19-rc3: known unfixed regressions (v2) @ 2006-10-26 22:45 ` Adrian Bunk 0 siblings, 0 replies; 152+ messages in thread From: Adrian Bunk @ 2006-10-26 22:45 UTC (permalink / raw) To: Linus Torvalds, Andrew Morton Cc: Linux Kernel Mailing List, Pavel Machek, Greg KH, linux-pci, Stephen Hemminger, Philipp Zabel, rmk, Martin Lorenz, len.brown, linux-acpi, linux-pm, Michael S. Tsirkin, Thierry Vignaud, jgarzik, linux-ide, Alex Romosan, Jens Axboe, Komuro, Thomas Gleixner, Benjamin Herrenschmidt, Stefan Richter, linux1394-devel, Christian, Mark Langsdorf, davej, cpufreq This email lists some known regressions in 2.6.19-rc3 compared to 2.6.18 that are not yet fixed Linus' tree. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject : swsusp initialized after SATA (CONFIG_PCI_MULTITHREAD_PROBE) References : http://lkml.org/lkml/2006/10/14/31 Submitter : Pavel Machek <pavel@ucw.cz> Status : unknown Subject : MSI errors during boot (CONFIG_PCI_MULTITHREAD_PROBE) References : http://lkml.org/lkml/2006/10/16/291 Submitter : Stephen Hemminger <shemminger@osdl.org> Handled-By : Greg KH <greg@kroah.com> Status : Greg is working on a fix Subject : arm: Oops in __wake_up_common during htc magician resume References : http://lkml.org/lkml/2006/10/25/73 Submitter : Philipp Zabel <philipp.zabel@gmail.com> Status : unknown Subject : X60s: BUG()s, lose ACPI events after suspend/resume References : http://lkml.org/lkml/2006/10/10/39 Submitter : Martin Lorenz <martin@lorenz.eu.org> Status : unknown Subject : T60 stops triggering any ACPI events References : http://lkml.org/lkml/2006/10/4/425 http://lkml.org/lkml/2006/10/16/262 http://bugzilla.kernel.org/show_bug.cgi?id=7408 Submitter : "Michael S. Tsirkin" <mst@mellanox.co.il> Status : unknown Subject : sata-via doesn't detect anymore disks attached to VIA vt6421 References : http://bugzilla.kernel.org/show_bug.cgi?id=7255 Submitter : Thierry Vignaud <tvignaud@mandriva.com> Status : unknown Subject : unable to rip cd References : http://lkml.org/lkml/2006/10/13/100 Submitter : Alex Romosan <romosan@sycorax.lbl.gov> Status : unknown Subject : SMP kernel can not generate ISA irq properly References : http://lkml.org/lkml/2006/10/22/15 Submitter : Komuro <komurojun-mbn@nifty.com> Handled-By : Thomas Gleixner <tglx@linutronix.de> Status : Thomas will investigate Subject : ohci1394 on PPC_PMAC: pci_set_power_state() failure and breaking suspend References : http://lkml.org/lkml/2006/10/24/13 Submitter : Benjamin Herrenschmidt <benh@kernel.crashing.org> Caused-By : Stefan Richter <stefanr@s5r6.in-berlin.de> commit ea6104c22468239083857fa07425c312b1ecb424 Handled-By : Stefan Richter <stefanr@s5r6.in-berlin.de> Status : Stefan Richter: looking for an answer when to ignore the return code of pci_set_power_state Subject : cpufreq not working on AMD K8 References : http://lkml.org/lkml/2006/10/10/114 Submitter : Christian <christiand59@web.de> Handled-By : Mark Langsdorf <mark.langsdorf@amd.com> Status : Mark is investigating ^ permalink raw reply [flat|nested] 152+ messages in thread
* 2.6.19-rc3: known unfixed regressions (v2) @ 2006-10-26 22:45 ` Adrian Bunk 0 siblings, 0 replies; 152+ messages in thread From: Adrian Bunk @ 2006-10-26 22:45 UTC (permalink / raw) To: Linus Torvalds, Andrew Morton Cc: Linux Kernel Mailing List, Pavel Machek, Greg KH, linux-pci, Stephen Hemminger, Philipp Zabel, rmk, Martin Lorenz, len.brown, linux-acpi, linux-pm, Michael S. Tsirkin, Thierry Vignaud, jgarzik, linux-ide, Alex Romosan, Jens Axboe, Komuro, Thomas Gleixner, Benjamin Herrenschmidt, Stefan Richter, linux1394-devel, Christian, Mark Langsdorf, davej, cpufreq@ This email lists some known regressions in 2.6.19-rc3 compared to 2.6.18 that are not yet fixed Linus' tree. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject : swsusp initialized after SATA (CONFIG_PCI_MULTITHREAD_PROBE) References : http://lkml.org/lkml/2006/10/14/31 Submitter : Pavel Machek <pavel@ucw.cz> Status : unknown Subject : MSI errors during boot (CONFIG_PCI_MULTITHREAD_PROBE) References : http://lkml.org/lkml/2006/10/16/291 Submitter : Stephen Hemminger <shemminger@osdl.org> Handled-By : Greg KH <greg@kroah.com> Status : Greg is working on a fix Subject : arm: Oops in __wake_up_common during htc magician resume References : http://lkml.org/lkml/2006/10/25/73 Submitter : Philipp Zabel <philipp.zabel@gmail.com> Status : unknown Subject : X60s: BUG()s, lose ACPI events after suspend/resume References : http://lkml.org/lkml/2006/10/10/39 Submitter : Martin Lorenz <martin@lorenz.eu.org> Status : unknown Subject : T60 stops triggering any ACPI events References : http://lkml.org/lkml/2006/10/4/425 http://lkml.org/lkml/2006/10/16/262 http://bugzilla.kernel.org/show_bug.cgi?id=7408 Submitter : "Michael S. Tsirkin" <mst@mellanox.co.il> Status : unknown Subject : sata-via doesn't detect anymore disks attached to VIA vt6421 References : http://bugzilla.kernel.org/show_bug.cgi?id=7255 Submitter : Thierry Vignaud <tvignaud@mandriva.com> Status : unknown Subject : unable to rip cd References : http://lkml.org/lkml/2006/10/13/100 Submitter : Alex Romosan <romosan@sycorax.lbl.gov> Status : unknown Subject : SMP kernel can not generate ISA irq properly References : http://lkml.org/lkml/2006/10/22/15 Submitter : Komuro <komurojun-mbn@nifty.com> Handled-By : Thomas Gleixner <tglx@linutronix.de> Status : Thomas will investigate Subject : ohci1394 on PPC_PMAC: pci_set_power_state() failure and breaking suspend References : http://lkml.org/lkml/2006/10/24/13 Submitter : Benjamin Herrenschmidt <benh@kernel.crashing.org> Caused-By : Stefan Richter <stefanr@s5r6.in-berlin.de> commit ea6104c22468239083857fa07425c312b1ecb424 Handled-By : Stefan Richter <stefanr@s5r6.in-berlin.de> Status : Stefan Richter: looking for an answer when to ignore the return code of pci_set_power_state Subject : cpufreq not working on AMD K8 References : http://lkml.org/lkml/2006/10/10/114 Submitter : Christian <christiand59@web.de> Handled-By : Mark Langsdorf <mark.langsdorf@amd.com> Status : Mark is investigating ^ permalink raw reply [flat|nested] 152+ messages in thread
* [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN 2006-10-26 22:45 ` Adrian Bunk (?) (?) @ 2006-10-27 1:02 ` Adrian Bunk 2006-10-27 1:20 ` Matthew Wilcox -1 siblings, 1 reply; 152+ messages in thread From: Adrian Bunk @ 2006-10-27 1:02 UTC (permalink / raw) To: Linus Torvalds, Andrew Morton Cc: Linux Kernel Mailing List, Pavel Machek, Greg KH, linux-pci, Stephen Hemminger On Fri, Oct 27, 2006 at 12:45:41AM +0200, Adrian Bunk wrote: >... > Subject : swsusp initialized after SATA (CONFIG_PCI_MULTITHREAD_PROBE) > References : http://lkml.org/lkml/2006/10/14/31 > Submitter : Pavel Machek <pavel@ucw.cz> > Status : unknown > > > Subject : MSI errors during boot (CONFIG_PCI_MULTITHREAD_PROBE) > References : http://lkml.org/lkml/2006/10/16/291 > Submitter : Stephen Hemminger <shemminger@osdl.org> > Handled-By : Greg KH <greg@kroah.com> > Status : Greg is working on a fix >... PCI_MULTITHREAD_PROBE is an interesting feature, but in it's current state it seems to be more of a trap for users who accidentally enable it. This patch lets PCI_MULTITHREAD_PROBE depend on BROKEN for 2.6.19. The intention is to get this patch reversed in -mm as soon as it's in Linus' tree, and reverse it for 2.6.20 or 2.6.21 after the fallout of in-kernel problems PCI_MULTITHREAD_PROBE causes got fixed. Signed-off-by: Adrian Bunk <bunk@stusta.de> --- linux-2.6/drivers/pci/Kconfig.old 2006-10-27 02:40:02.000000000 +0200 +++ linux-2.6/drivers/pci/Kconfig 2006-10-27 02:58:25.000000000 +0200 @@ -19,7 +19,7 @@ config PCI_MULTITHREAD_PROBE bool "PCI Multi-threaded probe (EXPERIMENTAL)" - depends on PCI && EXPERIMENTAL + depends on PCI && EXPERIMENTAL && BROKEN help Say Y here if you want the PCI core to spawn a new thread for every PCI device that is probed. This can cause a huge ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN 2006-10-27 1:02 ` [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN Adrian Bunk @ 2006-10-27 1:20 ` Matthew Wilcox 2006-10-27 1:28 ` Andrew Morton 2006-10-27 8:27 ` Pavel Machek 0 siblings, 2 replies; 152+ messages in thread From: Matthew Wilcox @ 2006-10-27 1:20 UTC (permalink / raw) To: Adrian Bunk Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List, Pavel Machek, Greg KH, linux-pci, Stephen Hemminger On Fri, Oct 27, 2006 at 03:02:52AM +0200, Adrian Bunk wrote: > PCI_MULTITHREAD_PROBE is an interesting feature, but in it's current > state it seems to be more of a trap for users who accidentally > enable it. > > This patch lets PCI_MULTITHREAD_PROBE depend on BROKEN for 2.6.19. > > The intention is to get this patch reversed in -mm as soon as it's in > Linus' tree, and reverse it for 2.6.20 or 2.6.21 after the fallout of > in-kernel problems PCI_MULTITHREAD_PROBE causes got fixed. People who enable features clearly marked as EXPERIMENTAL deserve what they get, IMO. ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN 2006-10-27 1:20 ` Matthew Wilcox @ 2006-10-27 1:28 ` Andrew Morton 2006-10-27 2:11 ` Stephen Hemminger 2006-10-27 8:27 ` Pavel Machek 1 sibling, 1 reply; 152+ messages in thread From: Andrew Morton @ 2006-10-27 1:28 UTC (permalink / raw) To: Matthew Wilcox Cc: Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List, Pavel Machek, Greg KH, linux-pci, Stephen Hemminger On Thu, 26 Oct 2006 19:20:58 -0600 Matthew Wilcox <matthew@wil.cx> wrote: > On Fri, Oct 27, 2006 at 03:02:52AM +0200, Adrian Bunk wrote: > > PCI_MULTITHREAD_PROBE is an interesting feature, but in it's current > > state it seems to be more of a trap for users who accidentally > > enable it. > > > > This patch lets PCI_MULTITHREAD_PROBE depend on BROKEN for 2.6.19. > > > > The intention is to get this patch reversed in -mm as soon as it's in > > Linus' tree, and reverse it for 2.6.20 or 2.6.21 after the fallout of > > in-kernel problems PCI_MULTITHREAD_PROBE causes got fixed. > > People who enable features clearly marked as EXPERIMENTAL deserve what > they get, IMO. It's not the impact on "people" which is of concern - it's the impact on kernel developers - specifically those who spend time looking at bug reports :( ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN 2006-10-27 1:28 ` Andrew Morton @ 2006-10-27 2:11 ` Stephen Hemminger 2006-10-27 17:07 ` Greg KH 0 siblings, 1 reply; 152+ messages in thread From: Stephen Hemminger @ 2006-10-27 2:11 UTC (permalink / raw) To: Andrew Morton Cc: Matthew Wilcox, Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List, Pavel Machek, Greg KH, linux-pci On Thu, 26 Oct 2006 18:28:38 -0700 Andrew Morton <akpm@osdl.org> wrote: > On Thu, 26 Oct 2006 19:20:58 -0600 > Matthew Wilcox <matthew@wil.cx> wrote: > > > On Fri, Oct 27, 2006 at 03:02:52AM +0200, Adrian Bunk wrote: > > > PCI_MULTITHREAD_PROBE is an interesting feature, but in it's current > > > state it seems to be more of a trap for users who accidentally > > > enable it. > > > > > > This patch lets PCI_MULTITHREAD_PROBE depend on BROKEN for 2.6.19. > > > > > > The intention is to get this patch reversed in -mm as soon as it's in > > > Linus' tree, and reverse it for 2.6.20 or 2.6.21 after the fallout of > > > in-kernel problems PCI_MULTITHREAD_PROBE causes got fixed. > > > > People who enable features clearly marked as EXPERIMENTAL deserve what > > they get, IMO. > > It's not the impact on "people" which is of concern - it's the impact on > kernel developers - specifically those who spend time looking at bug > reports :( Either it is broken and should be removed, or is barely working and should be fixed. If Greg wants to take bug reports then it can stay. ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN 2006-10-27 2:11 ` Stephen Hemminger @ 2006-10-27 17:07 ` Greg KH 2006-10-27 17:22 ` Pavel Machek ` (2 more replies) 0 siblings, 3 replies; 152+ messages in thread From: Greg KH @ 2006-10-27 17:07 UTC (permalink / raw) To: Stephen Hemminger Cc: Andrew Morton, Matthew Wilcox, Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List, Pavel Machek, linux-pci On Thu, Oct 26, 2006 at 07:11:31PM -0700, Stephen Hemminger wrote: > On Thu, 26 Oct 2006 18:28:38 -0700 > Andrew Morton <akpm@osdl.org> wrote: > > > On Thu, 26 Oct 2006 19:20:58 -0600 > > Matthew Wilcox <matthew@wil.cx> wrote: > > > > > On Fri, Oct 27, 2006 at 03:02:52AM +0200, Adrian Bunk wrote: > > > > PCI_MULTITHREAD_PROBE is an interesting feature, but in it's current > > > > state it seems to be more of a trap for users who accidentally > > > > enable it. > > > > > > > > This patch lets PCI_MULTITHREAD_PROBE depend on BROKEN for 2.6.19. > > > > > > > > The intention is to get this patch reversed in -mm as soon as it's in > > > > Linus' tree, and reverse it for 2.6.20 or 2.6.21 after the fallout of > > > > in-kernel problems PCI_MULTITHREAD_PROBE causes got fixed. > > > > > > People who enable features clearly marked as EXPERIMENTAL deserve what > > > they get, IMO. > > > > It's not the impact on "people" which is of concern - it's the impact on > > kernel developers - specifically those who spend time looking at bug > > reports :( > > Either it is broken and should be removed, or is barely working and > should be fixed. If Greg wants to take bug reports then it can stay. I want to keep taking bug reports. I've found only 1 real bug from all of this. The pci MSI initialization issue. It's on my queue of things to fix. Andrew has also sent me another "interesting" patch about making sure devices are found by the time we hit another init level which I'll see about adding too. But that MSI bug was a real bug, which is good to have found. It's also found other real bugs in other subsystems that could easily be hit by other users. So no, this should not be marked BROKEN. It's a very experimental feature, as the help text says. If you can think of any harsher language to put in that text, please let me know. And yes, there also has been a proposed change to the driver core to fix up how the multi-thread stuff works that looks very good, but it's down in my queue that I'm trying to catch up on right now. So consider this a NAK for this change. thanks, greg k-h ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN 2006-10-27 17:07 ` Greg KH @ 2006-10-27 17:22 ` Pavel Machek 2006-10-27 18:39 ` Andrew Morton 2006-10-27 22:23 ` [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN Adrian Bunk 2006-10-27 22:57 ` Alan Cox 2 siblings, 1 reply; 152+ messages in thread From: Pavel Machek @ 2006-10-27 17:22 UTC (permalink / raw) To: Greg KH Cc: Stephen Hemminger, Andrew Morton, Matthew Wilcox, Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List, linux-pci Hi! > > > > > PCI_MULTITHREAD_PROBE is an interesting feature, but in it's current > > > > > state it seems to be more of a trap for users who accidentally > > > > > enable it. > > > > > > > > > > This patch lets PCI_MULTITHREAD_PROBE depend on BROKEN for 2.6.19. > > > > > > > > > > The intention is to get this patch reversed in -mm as soon as it's in > > > > > Linus' tree, and reverse it for 2.6.20 or 2.6.21 after the fallout of > > > > > in-kernel problems PCI_MULTITHREAD_PROBE causes got fixed. > > > > > > > > People who enable features clearly marked as EXPERIMENTAL deserve what > > > > they get, IMO. > > > > > > It's not the impact on "people" which is of concern - it's the impact on > > > kernel developers - specifically those who spend time looking at bug > > > reports :( > > > > Either it is broken and should be removed, or is barely working and > > should be fixed. If Greg wants to take bug reports then it can stay. > > I want to keep taking bug reports. > > I've found only 1 real bug from all of this. The pci MSI initialization > issue. It's on my queue of things to fix. Andrew has also sent me > another "interesting" patch about making sure devices are found by the > time we hit another init level which I'll see about adding too. And the swsusp vs. SATA issue? Currently, SATA can be initialized after swsusp, leading to swsusp not finding its image and failing... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN 2006-10-27 17:22 ` Pavel Machek @ 2006-10-27 18:39 ` Andrew Morton 2006-10-27 18:41 ` vmlinux.lds: consolidate initcall sections Andrew Morton 0 siblings, 1 reply; 152+ messages in thread From: Andrew Morton @ 2006-10-27 18:39 UTC (permalink / raw) To: Pavel Machek Cc: Greg KH, Stephen Hemminger, Matthew Wilcox, Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List, linux-pci On Fri, 27 Oct 2006 19:22:19 +0200 Pavel Machek <pavel@ucw.cz> wrote: > > I've found only 1 real bug from all of this. The pci MSI initialization > > issue. It's on my queue of things to fix. Andrew has also sent me > > another "interesting" patch about making sure devices are found by the > > time we hit another init level which I'll see about adding too. > > And the swsusp vs. SATA issue? Currently, SATA can be initialized > after swsusp, leading to swsusp not finding its image and failing... How can sata be initialised after swsusp? Are they each using correctly prioritised initcall levels? If so then the problem is presumably that sata initialisation is started before swsusp initialisation, but sata completes _after_ swsusp initialisation has run. In which case the as-yet-untested drivers-wait-for-threaded-probes-between-initcall-levels.patch should fix this. Greg, I think I'll send vmlinuxlds-consolidate-initcall-sections.patch into Linus for 2.6.19, make things easier for everyone. I'll send both patches. Please test ;) ^ permalink raw reply [flat|nested] 152+ messages in thread
* vmlinux.lds: consolidate initcall sections 2006-10-27 18:39 ` Andrew Morton @ 2006-10-27 18:41 ` Andrew Morton 2006-10-27 18:42 ` [patch] drivers: wait for threaded probes between initcall levels Andrew Morton ` (2 more replies) 0 siblings, 3 replies; 152+ messages in thread From: Andrew Morton @ 2006-10-27 18:41 UTC (permalink / raw) To: Pavel Machek, Greg KH, Stephen Hemminger, Matthew Wilcox, Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List, linux-pci From: Andrew Morton <akpm@osdl.org> Add a vmlinux.lds.h helper macro for defining the eight-level initcall table, teach all the architectures to use it. This is a prerequisite for a patch which performs initcall synchronisation for multithreaded-probing. Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@osdl.org> --- arch/alpha/kernel/vmlinux.lds.S | 8 +------- arch/arm/kernel/vmlinux.lds.S | 8 +------- arch/frv/kernel/vmlinux.lds.S | 8 +------- arch/h8300/kernel/vmlinux.lds.S | 8 +------- arch/i386/kernel/vmlinux.lds.S | 8 +------- arch/ia64/kernel/vmlinux.lds.S | 8 +------- arch/m32r/kernel/vmlinux.lds.S | 8 +------- arch/m68knommu/kernel/vmlinux.lds.S | 8 +------- arch/mips/kernel/vmlinux.lds.S | 8 +------- arch/parisc/kernel/vmlinux.lds.S | 8 +------- arch/powerpc/kernel/vmlinux.lds.S | 8 +------- arch/ppc/kernel/vmlinux.lds.S | 8 +------- arch/s390/kernel/vmlinux.lds.S | 8 +------- arch/sh/kernel/vmlinux.lds.S | 8 +------- arch/sh64/kernel/vmlinux.lds.S | 8 +------- arch/sparc/kernel/vmlinux.lds.S | 8 +------- arch/sparc64/kernel/vmlinux.lds.S | 8 +------- arch/v850/kernel/vmlinux.lds.S | 8 +------- arch/x86_64/kernel/vmlinux.lds.S | 8 +------- arch/xtensa/kernel/vmlinux.lds.S | 8 +------- include/asm-generic/vmlinux.lds.h | 10 ++++++++++ 21 files changed, 30 insertions(+), 140 deletions(-) diff -puN arch/alpha/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/alpha/kernel/vmlinux.lds.S --- a/arch/alpha/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections +++ a/arch/alpha/kernel/vmlinux.lds.S @@ -48,13 +48,7 @@ SECTIONS . = ALIGN(8); __initcall_start = .; .initcall.init : { - *(.initcall1.init) - *(.initcall2.init) - *(.initcall3.init) - *(.initcall4.init) - *(.initcall5.init) - *(.initcall6.init) - *(.initcall7.init) + INITCALLS } __initcall_end = .; diff -puN arch/arm/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/arm/kernel/vmlinux.lds.S --- a/arch/arm/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections +++ a/arch/arm/kernel/vmlinux.lds.S @@ -45,13 +45,7 @@ SECTIONS *(.early_param.init) __early_end = .; __initcall_start = .; - *(.initcall1.init) - *(.initcall2.init) - *(.initcall3.init) - *(.initcall4.init) - *(.initcall5.init) - *(.initcall6.init) - *(.initcall7.init) + INITCALLS __initcall_end = .; __con_initcall_start = .; *(.con_initcall.init) diff -puN arch/arm26/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/arm26/kernel/vmlinux.lds.S diff -puN arch/frv/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/frv/kernel/vmlinux.lds.S --- a/arch/frv/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections +++ a/arch/frv/kernel/vmlinux.lds.S @@ -44,13 +44,7 @@ SECTIONS __initcall_start = .; .initcall.init : { - *(.initcall1.init) - *(.initcall2.init) - *(.initcall3.init) - *(.initcall4.init) - *(.initcall5.init) - *(.initcall6.init) - *(.initcall7.init) + INITCALLS } __initcall_end = .; __con_initcall_start = .; diff -puN arch/h8300/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/h8300/kernel/vmlinux.lds.S --- a/arch/h8300/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections +++ a/arch/h8300/kernel/vmlinux.lds.S @@ -118,13 +118,7 @@ SECTIONS . = ALIGN(0x4) ; ___setup_end = .; ___initcall_start = .; - *(.initcall1.init) - *(.initcall2.init) - *(.initcall3.init) - *(.initcall4.init) - *(.initcall5.init) - *(.initcall6.init) - *(.initcall7.init) + INITCALLS ___initcall_end = .; ___con_initcall_start = .; *(.con_initcall.init) diff -puN arch/i386/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/i386/kernel/vmlinux.lds.S --- a/arch/i386/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections +++ a/arch/i386/kernel/vmlinux.lds.S @@ -126,13 +126,7 @@ SECTIONS __setup_end = .; __initcall_start = .; .initcall.init : AT(ADDR(.initcall.init) - LOAD_OFFSET) { - *(.initcall1.init) - *(.initcall2.init) - *(.initcall3.init) - *(.initcall4.init) - *(.initcall5.init) - *(.initcall6.init) - *(.initcall7.init) + INITCALLS } __initcall_end = .; __con_initcall_start = .; diff -puN arch/ia64/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/ia64/kernel/vmlinux.lds.S --- a/arch/ia64/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections +++ a/arch/ia64/kernel/vmlinux.lds.S @@ -128,13 +128,7 @@ SECTIONS .initcall.init : AT(ADDR(.initcall.init) - LOAD_OFFSET) { __initcall_start = .; - *(.initcall1.init) - *(.initcall2.init) - *(.initcall3.init) - *(.initcall4.init) - *(.initcall5.init) - *(.initcall6.init) - *(.initcall7.init) + INITCALLS __initcall_end = .; } diff -puN arch/m32r/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/m32r/kernel/vmlinux.lds.S --- a/arch/m32r/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections +++ a/arch/m32r/kernel/vmlinux.lds.S @@ -83,13 +83,7 @@ SECTIONS __setup_end = .; __initcall_start = .; .initcall.init : { - *(.initcall1.init) - *(.initcall2.init) - *(.initcall3.init) - *(.initcall4.init) - *(.initcall5.init) - *(.initcall6.init) - *(.initcall7.init) + INITCALLS } __initcall_end = .; __con_initcall_start = .; diff -puN arch/m68k/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/m68k/kernel/vmlinux.lds.S diff -puN arch/m68knommu/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/m68knommu/kernel/vmlinux.lds.S --- a/arch/m68knommu/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections +++ a/arch/m68knommu/kernel/vmlinux.lds.S @@ -140,13 +140,7 @@ SECTIONS { *(.init.setup) __setup_end = .; __initcall_start = .; - *(.initcall1.init) - *(.initcall2.init) - *(.initcall3.init) - *(.initcall4.init) - *(.initcall5.init) - *(.initcall6.init) - *(.initcall7.init) + INITCALLS __initcall_end = .; __con_initcall_start = .; *(.con_initcall.init) diff -puN arch/mips/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/mips/kernel/vmlinux.lds.S --- a/arch/mips/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections +++ a/arch/mips/kernel/vmlinux.lds.S @@ -91,13 +91,7 @@ SECTIONS __initcall_start = .; .initcall.init : { - *(.initcall1.init) - *(.initcall2.init) - *(.initcall3.init) - *(.initcall4.init) - *(.initcall5.init) - *(.initcall6.init) - *(.initcall7.init) + INITCALLS } __initcall_end = .; diff -puN arch/parisc/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/parisc/kernel/vmlinux.lds.S --- a/arch/parisc/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections +++ a/arch/parisc/kernel/vmlinux.lds.S @@ -153,13 +153,7 @@ SECTIONS __setup_end = .; __initcall_start = .; .initcall.init : { - *(.initcall1.init) - *(.initcall2.init) - *(.initcall3.init) - *(.initcall4.init) - *(.initcall5.init) - *(.initcall6.init) - *(.initcall7.init) + INITCALLS } __initcall_end = .; __con_initcall_start = .; diff -puN arch/powerpc/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/powerpc/kernel/vmlinux.lds.S --- a/arch/powerpc/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections +++ a/arch/powerpc/kernel/vmlinux.lds.S @@ -108,13 +108,7 @@ SECTIONS .initcall.init : { __initcall_start = .; - *(.initcall1.init) - *(.initcall2.init) - *(.initcall3.init) - *(.initcall4.init) - *(.initcall5.init) - *(.initcall6.init) - *(.initcall7.init) + INITCALLS __initcall_end = .; } diff -puN arch/ppc/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/ppc/kernel/vmlinux.lds.S --- a/arch/ppc/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections +++ a/arch/ppc/kernel/vmlinux.lds.S @@ -115,13 +115,7 @@ SECTIONS __setup_end = .; __initcall_start = .; .initcall.init : { - *(.initcall1.init) - *(.initcall2.init) - *(.initcall3.init) - *(.initcall4.init) - *(.initcall5.init) - *(.initcall6.init) - *(.initcall7.init) + INITCALLS } __initcall_end = .; diff -puN arch/s390/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/s390/kernel/vmlinux.lds.S --- a/arch/s390/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections +++ a/arch/s390/kernel/vmlinux.lds.S @@ -83,13 +83,7 @@ SECTIONS __setup_end = .; __initcall_start = .; .initcall.init : { - *(.initcall1.init) - *(.initcall2.init) - *(.initcall3.init) - *(.initcall4.init) - *(.initcall5.init) - *(.initcall6.init) - *(.initcall7.init) + INITCALLS } __initcall_end = .; __con_initcall_start = .; diff -puN arch/sh/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/sh/kernel/vmlinux.lds.S --- a/arch/sh/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections +++ a/arch/sh/kernel/vmlinux.lds.S @@ -76,13 +76,7 @@ SECTIONS __setup_end = .; __initcall_start = .; .initcall.init : { - *(.initcall1.init) - *(.initcall2.init) - *(.initcall3.init) - *(.initcall4.init) - *(.initcall5.init) - *(.initcall6.init) - *(.initcall7.init) + INITCALLS } __initcall_end = .; __con_initcall_start = .; diff -puN arch/sh64/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/sh64/kernel/vmlinux.lds.S --- a/arch/sh64/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections +++ a/arch/sh64/kernel/vmlinux.lds.S @@ -108,13 +108,7 @@ SECTIONS __setup_end = .; __initcall_start = .; .initcall.init : C_PHYS(.initcall.init) { - *(.initcall1.init) - *(.initcall2.init) - *(.initcall3.init) - *(.initcall4.init) - *(.initcall5.init) - *(.initcall6.init) - *(.initcall7.init) + INITCALLS } __initcall_end = .; __con_initcall_start = .; diff -puN arch/sparc/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/sparc/kernel/vmlinux.lds.S --- a/arch/sparc/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections +++ a/arch/sparc/kernel/vmlinux.lds.S @@ -49,13 +49,7 @@ SECTIONS __setup_end = .; __initcall_start = .; .initcall.init : { - *(.initcall1.init) - *(.initcall2.init) - *(.initcall3.init) - *(.initcall4.init) - *(.initcall5.init) - *(.initcall6.init) - *(.initcall7.init) + INITCALLS } __initcall_end = .; __con_initcall_start = .; diff -puN arch/sparc64/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/sparc64/kernel/vmlinux.lds.S --- a/arch/sparc64/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections +++ a/arch/sparc64/kernel/vmlinux.lds.S @@ -57,13 +57,7 @@ SECTIONS __setup_end = .; __initcall_start = .; .initcall.init : { - *(.initcall1.init) - *(.initcall2.init) - *(.initcall3.init) - *(.initcall4.init) - *(.initcall5.init) - *(.initcall6.init) - *(.initcall7.init) + INITCALLS } __initcall_end = .; __con_initcall_start = .; diff -puN arch/um/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/um/kernel/vmlinux.lds.S diff -puN arch/v850/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/v850/kernel/vmlinux.lds.S --- a/arch/v850/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections +++ a/arch/v850/kernel/vmlinux.lds.S @@ -140,13 +140,7 @@ ___setup_end = . ; \ ___initcall_start = . ; \ *(.initcall.init) \ - *(.initcall1.init) \ - *(.initcall2.init) \ - *(.initcall3.init) \ - *(.initcall4.init) \ - *(.initcall5.init) \ - *(.initcall6.init) \ - *(.initcall7.init) \ + INITCALLS \ . = ALIGN (4) ; \ ___initcall_end = . ; \ ___con_initcall_start = .; \ diff -puN arch/x86_64/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/x86_64/kernel/vmlinux.lds.S --- a/arch/x86_64/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections +++ a/arch/x86_64/kernel/vmlinux.lds.S @@ -175,13 +175,7 @@ SECTIONS __setup_end = .; __initcall_start = .; .initcall.init : AT(ADDR(.initcall.init) - LOAD_OFFSET) { - *(.initcall1.init) - *(.initcall2.init) - *(.initcall3.init) - *(.initcall4.init) - *(.initcall5.init) - *(.initcall6.init) - *(.initcall7.init) + INITCALLS } __initcall_end = .; __con_initcall_start = .; diff -puN arch/xtensa/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections arch/xtensa/kernel/vmlinux.lds.S --- a/arch/xtensa/kernel/vmlinux.lds.S~vmlinuxlds-consolidate-initcall-sections +++ a/arch/xtensa/kernel/vmlinux.lds.S @@ -184,13 +184,7 @@ SECTIONS __initcall_start = .; .initcall.init : { - *(.initcall1.init) - *(.initcall2.init) - *(.initcall3.init) - *(.initcall4.init) - *(.initcall5.init) - *(.initcall6.init) - *(.initcall7.init) + INITCALLS } __initcall_end = .; diff -puN include/asm-generic/vmlinux.lds.h~vmlinuxlds-consolidate-initcall-sections include/asm-generic/vmlinux.lds.h --- a/include/asm-generic/vmlinux.lds.h~vmlinuxlds-consolidate-initcall-sections +++ a/include/asm-generic/vmlinux.lds.h @@ -213,3 +213,13 @@ #define NOTES \ .notes : { *(.note.*) } :note + +#define INITCALLS \ + *(.initcall1.init) \ + *(.initcall2.init) \ + *(.initcall3.init) \ + *(.initcall4.init) \ + *(.initcall5.init) \ + *(.initcall6.init) \ + *(.initcall7.init) + _ ^ permalink raw reply [flat|nested] 152+ messages in thread
* [patch] drivers: wait for threaded probes between initcall levels 2006-10-27 18:41 ` vmlinux.lds: consolidate initcall sections Andrew Morton @ 2006-10-27 18:42 ` Andrew Morton 2006-10-27 18:47 ` Stephen Hemminger 2006-10-27 22:59 ` Alan Cox 2006-10-27 19:31 ` vmlinux.lds: consolidate initcall sections Haavard Skinnemoen 2006-10-27 19:44 ` Matthew Wilcox 2 siblings, 2 replies; 152+ messages in thread From: Andrew Morton @ 2006-10-27 18:42 UTC (permalink / raw) To: Pavel Machek, Greg KH, Stephen Hemminger, Matthew Wilcox, Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List, linux-pci From: Andrew Morton <akpm@osdl.org> The multithreaded-probing code has a problem: after one initcall level (eg, core_initcall) has been processed, we will then start processing the next level (postcore_initcall) while the kernel threads which are handling core_initcall are still executing. This breaks the guarantees which the layered initcalls previously gave us. IOW, we want to be multithreaded _within_ an initcall level, but not between different levels. Fix that up by causing the probing code to wait for all outstanding probes at one level to complete before we start processing the next level. Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@osdl.org> --- drivers/base/dd.c | 30 ++++++++++++++++++++++++++++ include/asm-generic/vmlinux.lds.h | 9 +++++++- include/linux/init.h | 28 +++++++++++++++++--------- 3 files changed, 57 insertions(+), 10 deletions(-) diff -puN drivers/base/dd.c~drivers-wait-for-threaded-probes-between-initcall-levels drivers/base/dd.c --- a/drivers/base/dd.c~drivers-wait-for-threaded-probes-between-initcall-levels +++ a/drivers/base/dd.c @@ -18,6 +18,7 @@ #include <linux/device.h> #include <linux/module.h> #include <linux/kthread.h> +#include <linux/wait.h> #include "base.h" #include "power/power.h" @@ -70,6 +71,8 @@ struct stupid_thread_structure { }; static atomic_t probe_count = ATOMIC_INIT(0); +static DECLARE_WAIT_QUEUE_HEAD(probe_waitqueue); + static int really_probe(void *void_data) { struct stupid_thread_structure *data = void_data; @@ -121,6 +124,7 @@ probe_failed: done: kfree(data); atomic_dec(&probe_count); + wake_up(&probe_waitqueue); return ret; } @@ -337,6 +341,32 @@ void driver_detach(struct device_driver } } +#ifdef CONFIG_PCI_MULTITHREAD_PROBE +static int __init wait_for_probes(void) +{ + DEFINE_WAIT(wait); + + printk(KERN_INFO "%s: waiting for %d threads\n", __FUNCTION__, + atomic_read(&probe_count)); + if (!atomic_read(&probe_count)) + return 0; + while (atomic_read(&probe_count)) { + prepare_to_wait(&probe_waitqueue, &wait, TASK_UNINTERRUPTIBLE); + if (atomic_read(&probe_count)) + schedule(); + } + finish_wait(&probe_waitqueue, &wait); + return 0; +} + +core_initcall_sync(wait_for_probes); +postcore_initcall_sync(wait_for_probes); +arch_initcall_sync(wait_for_probes); +subsys_initcall_sync(wait_for_probes); +fs_initcall_sync(wait_for_probes); +device_initcall_sync(wait_for_probes); +late_initcall_sync(wait_for_probes); +#endif EXPORT_SYMBOL_GPL(device_bind_driver); EXPORT_SYMBOL_GPL(device_release_driver); diff -puN include/asm-generic/vmlinux.lds.h~drivers-wait-for-threaded-probes-between-initcall-levels include/asm-generic/vmlinux.lds.h --- a/include/asm-generic/vmlinux.lds.h~drivers-wait-for-threaded-probes-between-initcall-levels +++ a/include/asm-generic/vmlinux.lds.h @@ -216,10 +216,17 @@ #define INITCALLS \ *(.initcall1.init) \ + *(.initcall1s.init) \ *(.initcall2.init) \ + *(.initcall2s.init) \ *(.initcall3.init) \ + *(.initcall3s.init) \ *(.initcall4.init) \ + *(.initcall4s.init) \ *(.initcall5.init) \ + *(.initcall5s.init) \ *(.initcall6.init) \ - *(.initcall7.init) + *(.initcall6s.init) \ + *(.initcall7.init) \ + *(.initcall7s.init) diff -puN include/linux/init.h~drivers-wait-for-threaded-probes-between-initcall-levels include/linux/init.h --- a/include/linux/init.h~drivers-wait-for-threaded-probes-between-initcall-levels +++ a/include/linux/init.h @@ -84,19 +84,29 @@ extern void setup_arch(char **); * by link order. * For backwards compatibility, initcall() puts the call in * the device init subsection. + * + * The `id' arg to __define_initcall() is needed so that multiple initcalls + * can point at the same handler without causing duplicate-symbol build errors. */ -#define __define_initcall(level,fn) \ - static initcall_t __initcall_##fn __attribute_used__ \ +#define __define_initcall(level,fn,id) \ + static initcall_t __initcall_##fn##id __attribute_used__ \ __attribute__((__section__(".initcall" level ".init"))) = fn -#define core_initcall(fn) __define_initcall("1",fn) -#define postcore_initcall(fn) __define_initcall("2",fn) -#define arch_initcall(fn) __define_initcall("3",fn) -#define subsys_initcall(fn) __define_initcall("4",fn) -#define fs_initcall(fn) __define_initcall("5",fn) -#define device_initcall(fn) __define_initcall("6",fn) -#define late_initcall(fn) __define_initcall("7",fn) +#define core_initcall(fn) __define_initcall("1",fn,1) +#define core_initcall_sync(fn) __define_initcall("1s",fn,1s) +#define postcore_initcall(fn) __define_initcall("2",fn,2) +#define postcore_initcall_sync(fn) __define_initcall("2s",fn,2s) +#define arch_initcall(fn) __define_initcall("3",fn,3) +#define arch_initcall_sync(fn) __define_initcall("3s",fn,3s) +#define subsys_initcall(fn) __define_initcall("4",fn,4) +#define subsys_initcall_sync(fn) __define_initcall("4s",fn,4s) +#define fs_initcall(fn) __define_initcall("5",fn,5) +#define fs_initcall_sync(fn) __define_initcall("5s",fn,5s) +#define device_initcall(fn) __define_initcall("6",fn,6) +#define device_initcall_sync(fn) __define_initcall("6s",fn,6s) +#define late_initcall(fn) __define_initcall("7",fn,7) +#define late_initcall_sync(fn) __define_initcall("7s",fn,7s) #define __initcall(fn) device_initcall(fn) _ ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels 2006-10-27 18:42 ` [patch] drivers: wait for threaded probes between initcall levels Andrew Morton @ 2006-10-27 18:47 ` Stephen Hemminger 2006-10-27 20:15 ` Andrew Morton 2006-10-27 22:59 ` Alan Cox 1 sibling, 1 reply; 152+ messages in thread From: Stephen Hemminger @ 2006-10-27 18:47 UTC (permalink / raw) To: Andrew Morton Cc: Pavel Machek, Greg KH, Matthew Wilcox, Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List, linux-pci On Fri, 27 Oct 2006 11:42:37 -0700 Andrew Morton <akpm@osdl.org> wrote: > From: Andrew Morton <akpm@osdl.org> > > The multithreaded-probing code has a problem: after one initcall level (eg, > core_initcall) has been processed, we will then start processing the next > level (postcore_initcall) while the kernel threads which are handling > core_initcall are still executing. This breaks the guarantees which the > layered initcalls previously gave us. > > IOW, we want to be multithreaded _within_ an initcall level, but not between > different levels. > > Fix that up by causing the probing code to wait for all outstanding probes at > one level to complete before we start processing the next level. > > Cc: Greg KH <greg@kroah.com> > Signed-off-by: Andrew Morton <akpm@osdl.org> > --- > This looks like a good place to use a counting semaphore. -- Stephen Hemminger <shemminger@osdl.org> ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels 2006-10-27 18:47 ` Stephen Hemminger @ 2006-10-27 20:15 ` Andrew Morton 2006-10-27 20:42 ` Linus Torvalds 0 siblings, 1 reply; 152+ messages in thread From: Andrew Morton @ 2006-10-27 20:15 UTC (permalink / raw) To: Stephen Hemminger Cc: Pavel Machek, Greg KH, Matthew Wilcox, Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List, linux-pci On Fri, 27 Oct 2006 11:47:29 -0700 Stephen Hemminger <shemminger@osdl.org> wrote: > On Fri, 27 Oct 2006 11:42:37 -0700 > Andrew Morton <akpm@osdl.org> wrote: > > > From: Andrew Morton <akpm@osdl.org> > > > > The multithreaded-probing code has a problem: after one initcall level (eg, > > core_initcall) has been processed, we will then start processing the next > > level (postcore_initcall) while the kernel threads which are handling > > core_initcall are still executing. This breaks the guarantees which the > > layered initcalls previously gave us. > > > > IOW, we want to be multithreaded _within_ an initcall level, but not between > > different levels. > > > > Fix that up by causing the probing code to wait for all outstanding probes at > > one level to complete before we start processing the next level. > > > > Cc: Greg KH <greg@kroah.com> > > Signed-off-by: Andrew Morton <akpm@osdl.org> > > --- > > > > This looks like a good place to use a counting semaphore. > I couldn't work out a way of doing that. I guess one could a) count the number of threads which are going to be started, b) start them all, c) do an up() when each thread ends and d) handle errors somehow. ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels 2006-10-27 20:15 ` Andrew Morton @ 2006-10-27 20:42 ` Linus Torvalds 2006-10-27 20:48 ` Linus Torvalds 0 siblings, 1 reply; 152+ messages in thread From: Linus Torvalds @ 2006-10-27 20:42 UTC (permalink / raw) To: Andrew Morton Cc: Stephen Hemminger, Pavel Machek, Greg KH, Matthew Wilcox, Adrian Bunk, Linux Kernel Mailing List, linux-pci On Fri, 27 Oct 2006, Andrew Morton wrote: > > I couldn't work out a way of doing that. I guess one could a) count the > number of threads which are going to be started, b) start them all, c) do > an up() when each thread ends and d) handle errors somehow. No. First off, you want to _limit_ the maximum number of parallelism anyway (memory pressure and sanity), so you want to use the counting semaphore for that too. The easiest way to do it would probably be something like this: #define PARALLELISM (10) static struct semaphore outstanding; struct thread_exec { int (*fn)(void *); void *arg; struct completion completion; }; static void allow_parallel(int n) { while (--n >= 0) up(&outstanding); } static void wait_for_parallel(int n) { while (--n >= 0) down(&outstanding); } static int do_in_parallel(void *arg) { struct thread_exec *p = arg; int (*fn)(void *) = p->fn; void *arg = p->arg; int retval; /* Tell the caller we are done with the arguments */ complete(&p->completion); /* Do the actual work in parallel */ retval = p->fn(p->arg); /* * And then tell the rest of the world that we've * got one less parallel thing outstanding.. */ up(&outstanding); return retval; } static void execute_in_parallel(int (*fn)(void *), void *arg) { struct thread_exec arg = { .fn = fn, .arg = arg }; /* Make sure we can have more outstanding parallel work */ down(&outstanding); arg.fn = fn; arg.arg = arg; init_completion(&arg.completion); kernel_thread(do_in_parallel, &arg); /* We need to wait until our "arg" is safe */ wait_for_completion(&arg.completion) } The above is ENTIRELY UNTESTED, but the point of it is that it should now allow you to do something like this: /* Set up how many parallel threads we can run */ allow_parallel(PARALLELISM); ... /* * Run an arbitrary number of threads with that * parallelism. */ for (i = 0; i < ... ; i++) execute_in_parallel(fnarray[i].function, fnarray[i].argument); ... /* And wait for all of them to complete */ wait_for_parallel(PARALLELISM); and this is totally generic (ie this is useful for initcalls or anything else). Note also how you can set up the parallelism (and wait for it) totally independently (ie that can be done at some earlier stage, and the "execute_in_parallel()" can just be executed in any random situation in between - as many times as you like. It will always honor the parallelism. By setting PARALLELISM to 1, you basically only ever allow one outstanding call at any time (ie it becomes serial), so you don't even have to make this a config option, you could do it as a runtime setup thing. Hmm? (And I repeat: the above code is untested, and was written in the email client. It has never seen a compiler, and not gotten a _whole_ lot of thinking). Linus ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels 2006-10-27 20:42 ` Linus Torvalds @ 2006-10-27 20:48 ` Linus Torvalds 2006-10-28 1:11 ` Greg KH 0 siblings, 1 reply; 152+ messages in thread From: Linus Torvalds @ 2006-10-27 20:48 UTC (permalink / raw) To: Andrew Morton Cc: Stephen Hemminger, Pavel Machek, Greg KH, Matthew Wilcox, Adrian Bunk, Linux Kernel Mailing List, linux-pci On Fri, 27 Oct 2006, Linus Torvalds wrote: > > static int do_in_parallel(void *arg) > { > struct thread_exec *p = arg; > int (*fn)(void *) = p->fn; > void *arg = p->arg; > int retval; > > /* Tell the caller we are done with the arguments */ > complete(&p->completion); > > /* Do the actual work in parallel */ > retval = p->fn(p->arg); Duh. The whole reason I copied them was to _not_ do that. That last line should obviously be retval = fn(arg); because "p" may gone after we've done the "complete()". > (And I repeat: the above code is untested, and was written in the email > client. It has never seen a compiler, and not gotten a _whole_ lot of > thinking). .. This hasn't changed, I just looked through the code once and found that obvious bug. Linus ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels 2006-10-27 20:48 ` Linus Torvalds @ 2006-10-28 1:11 ` Greg KH 2006-10-28 1:50 ` Linus Torvalds 0 siblings, 1 reply; 152+ messages in thread From: Greg KH @ 2006-10-28 1:11 UTC (permalink / raw) To: Linus Torvalds Cc: Andrew Morton, Stephen Hemminger, Pavel Machek, Matthew Wilcox, Adrian Bunk, Linux Kernel Mailing List, linux-pci On Fri, Oct 27, 2006 at 01:48:54PM -0700, Linus Torvalds wrote: > > > On Fri, 27 Oct 2006, Linus Torvalds wrote: > > > > > static int do_in_parallel(void *arg) > > { > > struct thread_exec *p = arg; > > int (*fn)(void *) = p->fn; > > void *arg = p->arg; > > int retval; > > > > /* Tell the caller we are done with the arguments */ > > complete(&p->completion); > > > > /* Do the actual work in parallel */ > > retval = p->fn(p->arg); > > Duh. The whole reason I copied them was to _not_ do that. That last line > should obviously be > > retval = fn(arg); > > because "p" may gone after we've done the "complete()". > > > (And I repeat: the above code is untested, and was written in the email > > client. It has never seen a compiler, and not gotten a _whole_ lot of > > thinking). > > .. This hasn't changed, I just looked through the code once and found that > obvious bug. Heh, ok, I'll take this idea, and Andrew's patch, and rework things for the next round of 2.6.20-rc kernels, and mark the current stuff as BROKEN for now. thanks, greg k-h ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels 2006-10-28 1:11 ` Greg KH @ 2006-10-28 1:50 ` Linus Torvalds 0 siblings, 0 replies; 152+ messages in thread From: Linus Torvalds @ 2006-10-28 1:50 UTC (permalink / raw) To: Greg KH Cc: Andrew Morton, Stephen Hemminger, Pavel Machek, Matthew Wilcox, Adrian Bunk, Linux Kernel Mailing List, linux-pci On Fri, 27 Oct 2006, Greg KH wrote: > > Heh, ok, I'll take this idea, and Andrew's patch, and rework things for > the next round of 2.6.20-rc kernels, and mark the current stuff as > BROKEN for now. My interface stuff is kind of designed for: - keep the current "init" sequence as-is for now - keep the _actual_ PCI probing non-parallel, so that we actually do all the bus _discovery_ in a repeatable and sane order. - use the new "execute_in_parallel()" interface for things that actually _sleep_. For example, all the PCI IDE _driver_ attachement should be done synchronously, but perhaps the code that tries to see if there are actual disks (ie the stuff that has timeouts etc) can use the parallel execution. - module loading would do a "allow_parallel(1)" and "wait_for_parallel(1)" thing when calling the module init function (so that a module could use "execute_in_parallel()" whether compiled in or not, and each "init level" at boot would also do this (with some bigger number, like 10), so that for drivers etc that want to do async stuff, they can do so in parallel (but they'd still have done the actual hard device find/init serially - keeping the link order relevant for things like IDE controller discovery) How does this sound? There's really no reason to parallelise the actual PCI config cycles and probing and stuff. It's only when some driver knows that it might have to do some longer-running thing that it might want to execute a thread in parallel with other things - but it still needs to be done in a controlled situation, so that when "driver_init()" stops and "filesystem_init()" starts, we must wait for all the driver-init parallel tasks to finish (since "filesystem_init()" is allowed to depend on them). Hmm? Linus ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels 2006-10-27 18:42 ` [patch] drivers: wait for threaded probes between initcall levels Andrew Morton 2006-10-27 18:47 ` Stephen Hemminger @ 2006-10-27 22:59 ` Alan Cox 2006-10-27 23:06 ` Andrew Morton 2006-10-27 23:12 ` Olaf Hering 1 sibling, 2 replies; 152+ messages in thread From: Alan Cox @ 2006-10-27 22:59 UTC (permalink / raw) To: Andrew Morton Cc: Pavel Machek, Greg KH, Stephen Hemminger, Matthew Wilcox, Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List, linux-pci Ar Gwe, 2006-10-27 am 11:42 -0700, ysgrifennodd Andrew Morton: > IOW, we want to be multithreaded _within_ an initcall level, but not between > different levels. Thats actually insufficient. We have link ordered init sequences in large numbers of driver subtrees (ATA, watchdog, etc). We'll need several more initcall layers to fix that. Alan ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels 2006-10-27 22:59 ` Alan Cox @ 2006-10-27 23:06 ` Andrew Morton 2006-10-28 5:09 ` Grant Grundler 2006-10-30 9:44 ` Cornelia Huck 2006-10-27 23:12 ` Olaf Hering 1 sibling, 2 replies; 152+ messages in thread From: Andrew Morton @ 2006-10-27 23:06 UTC (permalink / raw) To: Alan Cox Cc: Pavel Machek, Greg KH, Stephen Hemminger, Matthew Wilcox, Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List, linux-pci On Fri, 27 Oct 2006 23:59:30 +0100 Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: > Ar Gwe, 2006-10-27 am 11:42 -0700, ysgrifennodd Andrew Morton: > > IOW, we want to be multithreaded _within_ an initcall level, but not between > > different levels. > > Thats actually insufficient. We have link ordered init sequences in > large numbers of driver subtrees (ATA, watchdog, etc). We'll need > several more initcall layers to fix that. > It would be nice to express those dependencies in some clearer and less fragile manner than link order. I guess finer-grained initcall levels would do that, but it doesn't scale very well. But whatever. I think multithreaded probing just doesn't pass the benefit-versus-hassle test, sorry. Make it dependent on CONFIG_GREGKH ;) ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels 2006-10-27 23:06 ` Andrew Morton @ 2006-10-28 5:09 ` Grant Grundler 2006-10-28 5:19 ` Andrew Morton 2006-10-30 9:44 ` Cornelia Huck 1 sibling, 1 reply; 152+ messages in thread From: Grant Grundler @ 2006-10-28 5:09 UTC (permalink / raw) To: Andrew Morton Cc: Alan Cox, Pavel Machek, Greg KH, Stephen Hemminger, Matthew Wilcox, Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List, linux-pci On Fri, Oct 27, 2006 at 04:06:26PM -0700, Andrew Morton wrote: > On Fri, 27 Oct 2006 23:59:30 +0100 > Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: > > > Ar Gwe, 2006-10-27 am 11:42 -0700, ysgrifennodd Andrew Morton: > > > IOW, we want to be multithreaded _within_ an initcall level, but not between > > > different levels. > > > > Thats actually insufficient. We have link ordered init sequences in > > large numbers of driver subtrees (ATA, watchdog, etc). We'll need > > several more initcall layers to fix that. > > > > It would be nice to express those dependencies in some clearer and less > fragile manner than link order. I guess finer-grained initcall levels > would do that, but it doesn't scale very well. Would making use of depmod data be a step in the right direction? ie nic driver calls extern function (e.g. pci_enable_device()) and therefore must depend on module which provides that function. My guess is this probably isn't 100% sufficient to replace all initcall levels. But likely sufficient within a given initcall level. My main concern are circular dependencies (which are rare). > But whatever. I think multithreaded probing just doesn't pass the > benefit-versus-hassle test, sorry. Make it dependent on CONFIG_GREGKH ;) Isn't already? :) I thought parallel PCI and SCSI probing on system with multiple NICs and "SCSI" storage requires udev to create devices with consistent naming. thanks, grant ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels 2006-10-28 5:09 ` Grant Grundler @ 2006-10-28 5:19 ` Andrew Morton 2006-10-28 5:32 ` Andrew Morton 2006-10-28 6:08 ` Grant Grundler 0 siblings, 2 replies; 152+ messages in thread From: Andrew Morton @ 2006-10-28 5:19 UTC (permalink / raw) To: Grant Grundler Cc: Alan Cox, Pavel Machek, Greg KH, Stephen Hemminger, Matthew Wilcox, Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List, linux-pci On Fri, 27 Oct 2006 23:09:05 -0600 Grant Grundler <grundler@parisc-linux.org> wrote: > On Fri, Oct 27, 2006 at 04:06:26PM -0700, Andrew Morton wrote: > > On Fri, 27 Oct 2006 23:59:30 +0100 > > Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: > > > > > Ar Gwe, 2006-10-27 am 11:42 -0700, ysgrifennodd Andrew Morton: > > > > IOW, we want to be multithreaded _within_ an initcall level, but not between > > > > different levels. > > > > > > Thats actually insufficient. We have link ordered init sequences in > > > large numbers of driver subtrees (ATA, watchdog, etc). We'll need > > > several more initcall layers to fix that. > > > > > > > It would be nice to express those dependencies in some clearer and less > > fragile manner than link order. I guess finer-grained initcall levels > > would do that, but it doesn't scale very well. > > Would making use of depmod data be a step in the right direction? Nope. The linkage-order problem is by definition applicable to linked-into-vmlinux code, not to modules. > ie nic driver calls extern function (e.g. pci_enable_device()) > and therefore must depend on module which provides that function. > > My guess is this probably isn't 100% sufficient to replace all initcall > levels. But likely sufficient within a given initcall level. > My main concern are circular dependencies (which are rare). The simplest implementation of "A needs B to have run" is for A to simply call B, and B arranges to not allow itself to be run more than once. But that doesn't work in the case "A needs B to be run, but only if B is present". Resolving this one would require something like a fancy "synchronisation object" against which dependers and dependees can register interest, and a core engine which takes care of the case where a depender registers against something which no dependees have registered. The mind boggles. > > But whatever. I think multithreaded probing just doesn't pass the > > benefit-versus-hassle test, sorry. Make it dependent on CONFIG_GREGKH ;) > > Isn't already? :) > > I thought parallel PCI and SCSI probing on system with multiple NICs and > "SCSI" storage requires udev to create devices with consistent naming. For some reason people get upset when we rename all their devices. They're a humourless lot. ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels 2006-10-28 5:19 ` Andrew Morton @ 2006-10-28 5:32 ` Andrew Morton 2006-10-28 6:08 ` Grant Grundler 1 sibling, 0 replies; 152+ messages in thread From: Andrew Morton @ 2006-10-28 5:32 UTC (permalink / raw) To: Grant Grundler, Alan Cox, Pavel Machek, Greg KH, Stephen Hemminger, Matthew Wilcox, Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List, linux-pci On Fri, 27 Oct 2006 22:19:25 -0700 Andrew Morton <akpm@osdl.org> wrote: > The simplest implementation of "A needs B to have run" is for A to simply > call B, and B arranges to not allow itself to be run more than once. > > But that doesn't work in the case "A needs B to be run, but only if B is > present". Resolving this one would require something like a fancy > "synchronisation object" against which dependers and dependees can register > interest, and a core engine which takes care of the case where a depender > registers against something which no dependees have registered. otoh, we could stick with the simple "A calls B" solution, and A also provides an attribute-weak implementation of B to cover the "A needs B but only if B is present" problems. Had to say, really - one would need to study some specific problem cases. ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels 2006-10-28 5:19 ` Andrew Morton 2006-10-28 5:32 ` Andrew Morton @ 2006-10-28 6:08 ` Grant Grundler 2006-10-28 20:48 ` Stefan Richter 1 sibling, 1 reply; 152+ messages in thread From: Grant Grundler @ 2006-10-28 6:08 UTC (permalink / raw) To: Andrew Morton Cc: Grant Grundler, Alan Cox, Pavel Machek, Greg KH, Stephen Hemminger, Matthew Wilcox, Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List, linux-pci On Fri, Oct 27, 2006 at 10:19:25PM -0700, Andrew Morton wrote: > > > It would be nice to express those dependencies in some clearer and less > > > fragile manner than link order. I guess finer-grained initcall levels > > > would do that, but it doesn't scale very well. > > > > Would making use of depmod data be a step in the right direction? > > Nope. The linkage-order problem is by definition applicable to > linked-into-vmlinux code, not to modules. But wouldn't the same concept apply to non-module symbols that are tagged with EXPORT_SYMBOL()? Maybe I'm just showing my ignorance about kernel linking here... > > ie nic driver calls extern function (e.g. pci_enable_device()) > > and therefore must depend on module which provides that function. > > > > My guess is this probably isn't 100% sufficient to replace all initcall > > levels. But likely sufficient within a given initcall level. > > My main concern are circular dependencies (which are rare). > > The simplest implementation of "A needs B to have run" is for A to simply > call B, and B arranges to not allow itself to be run more than once. Yes. we already have code like this in the kernel. e.g. superio support in drivers/parisc. > But that doesn't work in the case "A needs B to be run, but only if B is > present". I was thinking of "A is present and calls into module B, therefore B needs to init first". In this case, A won't care if B is really present or not. A depends on B to figure that out at runtime. If B is not configured into the kernel, A won't ever call B since the "function" will be a NOP. (e.g. #ifndef CONFIG_B/#define b_service() /* NOP */ /#endif) > Resolving this one would require something like a fancy > "synchronisation object" against which dependers and dependees can register > interest, and a core engine which takes care of the case where a depender > registers against something which no dependees have registered. I guess I was wondering if the kernel link step could use symbol information in a similar way the kernel module autoloader uses depmod info. But other parts of the kernel might not be as modular as most of the IO subsystems are. I'm not looking for ways to make the process more complicated for the people maintaining code. Keeping the registrations of dependencies up-to-date manually would just be another PITA. ... > > I thought parallel PCI and SCSI probing on system with multiple NICs and > > "SCSI" storage requires udev to create devices with consistent naming. > > For some reason people get upset when we rename all their devices. They're > a humourless lot. Hey! I resemble that remark! ;) (yeah, I've been a victim of that problem way too many times.) thanks, grant ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels 2006-10-28 6:08 ` Grant Grundler @ 2006-10-28 20:48 ` Stefan Richter 2006-10-28 23:34 ` Alan Cox 0 siblings, 1 reply; 152+ messages in thread From: Stefan Richter @ 2006-10-28 20:48 UTC (permalink / raw) To: Grant Grundler Cc: Andrew Morton, Alan Cox, Pavel Machek, Greg KH, Stephen Hemminger, Matthew Wilcox, Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List, linux-pci Grant Grundler wrote: > On Fri, Oct 27, 2006 at 10:19:25PM -0700, Andrew Morton wrote: >>> I thought parallel PCI and SCSI probing on system with multiple NICs and >>> "SCSI" storage requires udev to create devices with consistent naming. >> For some reason people get upset when we rename all their devices. They're >> a humourless lot. > > Hey! I resemble that remark! ;) > > (yeah, I've been a victim of that problem way too many times.) I hear network interfaces can be selected by their MACs, which are globally unique and persistent. Most SCSI hardware has globally unique and persistent unit properties too, and udev indeed uses them these days. -- Stefan Richter -=====-=-==- =-=- ===-- http://arcgraph.de/sr/ ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels 2006-10-28 20:48 ` Stefan Richter @ 2006-10-28 23:34 ` Alan Cox 2006-10-29 2:01 ` Randy Dunlap 0 siblings, 1 reply; 152+ messages in thread From: Alan Cox @ 2006-10-28 23:34 UTC (permalink / raw) To: Stefan Richter Cc: Grant Grundler, Andrew Morton, Pavel Machek, Greg KH, Stephen Hemminger, Matthew Wilcox, Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List, linux-pci Ar Sad, 2006-10-28 am 22:48 +0200, ysgrifennodd Stefan Richter: > I hear network interfaces can be selected by their MACs, which are > globally unique and persistent. Most SCSI hardware has globally unique > and persistent unit properties too, and udev indeed uses them these days. You hear incorrectly. The MAC address is only required to be *machine unique*, please see the 802.1/2 specification documents for more detail. Distinguishing by card MAC is a hack that works on some systems only. SCSI is also unreliable for serial numbers because of USB, brain-dead raid controllers and other devices that fake the same ident for many devices. There is another ugly too - many driver/library layers "know" that during boot the code is not re-entered so has no locking. Before you can go multi-probe you also have to fix all the locking in the drivers that have boot time specific functionality (eg IDE). Alan ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels 2006-10-28 23:34 ` Alan Cox @ 2006-10-29 2:01 ` Randy Dunlap 0 siblings, 0 replies; 152+ messages in thread From: Randy Dunlap @ 2006-10-29 2:01 UTC (permalink / raw) To: Alan Cox Cc: Stefan Richter, Grant Grundler, Andrew Morton, Pavel Machek, Greg KH, Stephen Hemminger, Matthew Wilcox, Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List, linux-pci On Sun, 29 Oct 2006 00:34:57 +0100 Alan Cox wrote: > Ar Sad, 2006-10-28 am 22:48 +0200, ysgrifennodd Stefan Richter: > > I hear network interfaces can be selected by their MACs, which are > > globally unique and persistent. Most SCSI hardware has globally unique > > and persistent unit properties too, and udev indeed uses them these days. > > You hear incorrectly. The MAC address is only required to be *machine > unique*, please see the 802.1/2 specification documents for more detail. > Distinguishing by card MAC is a hack that works on some systems only. I would have expected "most" instead of "some", but you have different experiences than I do. What spec requires a MAC address to be machine-unique? IEEE "makes it possible for organizations to employ unique individual LAN MAC addresses, group addresses, and protocol identifiers." IEEE 802 goes on to say: "The concept of universal addressing is based on the idea that all potential members of a network need to have a unique identifier (if they are going to coexist in the network). The advantage of a universal address is that a station with such an address can be attached to any LAN in the world with an assurance that the address is unique." and then "recommended" (but not required): "The recommended approach is for each device associated with a distinct point of attachment to a LAN to have its own unique MAC address. Typically, therefore, a LAN adapter card (or, e.g., an equivalent chip or set of chips on a motherboard) should have one unique MAC address for each LAN attachment that it can support at a given time. and then this part seems contrary to the machine-unique quality that you mentioned (I guess--don't know--that this is what Sun used to do ?): "NOTE—It is recognized that an alternative approach has gained currency in some LAN implementations, in which the device is interpreted as a complete computer system, which can have multiple attachments to different LANs. Under this interpretation, a single LAN MAC address is used to identify all of the system’s points of attachment to the LANs in question. This approach, unlike the recommended one, does not automatically meet the requirements of IEEE Std 802.1D-1998 MAC bridging." > SCSI is also unreliable for serial numbers because of USB, brain-dead > raid controllers and other devices that fake the same ident for many > devices. > > There is another ugly too - many driver/library layers "know" that > during boot the code is not re-entered so has no locking. Before you can > go multi-probe you also have to fix all the locking in the drivers that > have boot time specific functionality (eg IDE). --- ~Randy ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels 2006-10-27 23:06 ` Andrew Morton 2006-10-28 5:09 ` Grant Grundler @ 2006-10-30 9:44 ` Cornelia Huck 2006-10-30 10:48 ` Alan Cox 1 sibling, 1 reply; 152+ messages in thread From: Cornelia Huck @ 2006-10-30 9:44 UTC (permalink / raw) To: Andrew Morton Cc: Alan Cox, Pavel Machek, Greg KH, Stephen Hemminger, Matthew Wilcox, Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List, linux-pci On Fri, 27 Oct 2006 16:06:26 -0700, Andrew Morton <akpm@osdl.org> wrote: > On Fri, 27 Oct 2006 23:59:30 +0100 > Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: > > > Ar Gwe, 2006-10-27 am 11:42 -0700, ysgrifennodd Andrew Morton: > > > IOW, we want to be multithreaded _within_ an initcall level, but not between > > > different levels. > > > > Thats actually insufficient. We have link ordered init sequences in > > large numbers of driver subtrees (ATA, watchdog, etc). We'll need > > several more initcall layers to fix that. > > > > It would be nice to express those dependencies in some clearer and less > fragile manner than link order. I guess finer-grained initcall levels > would do that, but it doesn't scale very well. Would it be sufficient just to make the busses wait until all their devices are through with their setup? This is what the ccw bus on s390 does: - Increase counter for device and start device recognition for it - Continue for next device - When async device recognition (and probable enablement) is finished, register device and decrease counter - ccw bus init function waits till counter has dropped to 0 This has worked fine for us since 2.5. OTOH, s390 doesn't have such a diverse set as hardware as a PC :) -- Cornelia Huck Linux for zSeries Developer Tel.: +49-7031-16-4837, Mail: cornelia.huck@de.ibm.com ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels 2006-10-30 9:44 ` Cornelia Huck @ 2006-10-30 10:48 ` Alan Cox 2006-10-30 12:29 ` Matthew Wilcox 0 siblings, 1 reply; 152+ messages in thread From: Alan Cox @ 2006-10-30 10:48 UTC (permalink / raw) To: Cornelia Huck Cc: Andrew Morton, Pavel Machek, Greg KH, Stephen Hemminger, Matthew Wilcox, Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List, linux-pci Ar Llu, 2006-10-30 am 10:44 +0100, ysgrifennodd Cornelia Huck: > Would it be sufficient just to make the busses wait until all their > devices are through with their setup? This is what the ccw bus on s390 > does: For ATA and IDE no, it might work with SCSI but your devices would randomly re-order which is also obnoxious. IDE relies on both link probe order and also has code that knows boot time processing is single threaded. ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels 2006-10-30 10:48 ` Alan Cox @ 2006-10-30 12:29 ` Matthew Wilcox 0 siblings, 0 replies; 152+ messages in thread From: Matthew Wilcox @ 2006-10-30 12:29 UTC (permalink / raw) To: Alan Cox Cc: Cornelia Huck, Andrew Morton, Pavel Machek, Greg KH, Stephen Hemminger, Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List, linux-pci, James Bottomley On Mon, Oct 30, 2006 at 10:48:51AM +0000, Alan Cox wrote: > Ar Llu, 2006-10-30 am 10:44 +0100, ysgrifennodd Cornelia Huck: > > Would it be sufficient just to make the busses wait until all their > > devices are through with their setup? This is what the ccw bus on s390 > > does: > > For ATA and IDE no, it might work with SCSI but your devices would > randomly re-order which is also obnoxious. IDE relies on both link probe > order and also has code that knows boot time processing is single > threaded. There's no need to parallelise the scanning of SCSI host adapters. Indeed, it only causes pain. With http://git.kernel.org/git/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commitdiff;h=3e082a910d217b2e7b186077ebf5a1126a68c62f and http://git.parisc-linux.org/?p=linux-2.6.git;a=shortlog;h=scsi-async-scan some bugfixing, and moving the scsi initialisation earlier (so it has longer to complete while other things initialise), we should never have to wait for scsi scans again. And your devices only reorder as much as they ever used to with scsi. ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [patch] drivers: wait for threaded probes between initcall levels 2006-10-27 22:59 ` Alan Cox 2006-10-27 23:06 ` Andrew Morton @ 2006-10-27 23:12 ` Olaf Hering 1 sibling, 0 replies; 152+ messages in thread From: Olaf Hering @ 2006-10-27 23:12 UTC (permalink / raw) To: Alan Cox Cc: Andrew Morton, Pavel Machek, Greg KH, Stephen Hemminger, Matthew Wilcox, Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List, linux-pci On Fri, Oct 27, Alan Cox wrote: > Ar Gwe, 2006-10-27 am 11:42 -0700, ysgrifennodd Andrew Morton: > > IOW, we want to be multithreaded _within_ an initcall level, but not between > > different levels. > > Thats actually insufficient. We have link ordered init sequences in > large numbers of driver subtrees (ATA, watchdog, etc). We'll need > several more initcall layers to fix that. Is it time for something better? True dependencies, an addition to or as replacement for module_init()? random example: hfs/super.c: depends_on_initialized(init_hfs_fs: init_hfsplus_fs,kmem_cache_thingie,core_filesystem_thingie,foo,bar,worldpeace); If init_hfsplus_fs() does not exist it should be no error. Whatever the sytax will be and however its parsed during build, that link order requirement bites every other month. ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: vmlinux.lds: consolidate initcall sections 2006-10-27 18:41 ` vmlinux.lds: consolidate initcall sections Andrew Morton 2006-10-27 18:42 ` [patch] drivers: wait for threaded probes between initcall levels Andrew Morton @ 2006-10-27 19:31 ` Haavard Skinnemoen 2006-10-29 10:21 ` Geert Uytterhoeven 2006-10-27 19:44 ` Matthew Wilcox 2 siblings, 1 reply; 152+ messages in thread From: Haavard Skinnemoen @ 2006-10-27 19:31 UTC (permalink / raw) To: Andrew Morton Cc: Pavel Machek, Greg KH, Stephen Hemminger, Matthew Wilcox, Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List, linux-pci On 10/27/06, Andrew Morton <akpm@osdl.org> wrote: > From: Andrew Morton <akpm@osdl.org> > > Add a vmlinux.lds.h helper macro for defining the eight-level initcall table, > teach all the architectures to use it. Please include AVR32 as well while you're at it ;) Signed-off-by: Haavard Skinnemoen <hskinnemoen@atmel.com> --- arch/avr32/kernel/vmlinux.lds.c | 8 +------- 1 files changed, 1 insertions(+), 7 deletions(-) diff --git a/arch/avr32/kernel/vmlinux.lds.c b/arch/avr32/kernel/vmlinux.lds.c index cdd627c..5c4424e 100644 --- a/arch/avr32/kernel/vmlinux.lds.c +++ b/arch/avr32/kernel/vmlinux.lds.c @@ -38,13 +38,7 @@ SECTIONS __setup_end = .; . = ALIGN(4); __initcall_start = .; - *(.initcall1.init) - *(.initcall2.init) - *(.initcall3.init) - *(.initcall4.init) - *(.initcall5.init) - *(.initcall6.init) - *(.initcall7.init) + INITCALLS __initcall_end = .; __con_initcall_start = .; *(.con_initcall.init) -- 1.4.1.1 ^ permalink raw reply related [flat|nested] 152+ messages in thread
* Re: vmlinux.lds: consolidate initcall sections 2006-10-27 19:31 ` vmlinux.lds: consolidate initcall sections Haavard Skinnemoen @ 2006-10-29 10:21 ` Geert Uytterhoeven 0 siblings, 0 replies; 152+ messages in thread From: Geert Uytterhoeven @ 2006-10-29 10:21 UTC (permalink / raw) To: Andrew Morton Cc: Haavard Skinnemoen, Pavel Machek, Greg KH, Stephen Hemminger, Matthew Wilcox, Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List, linux-pci, Geert Uytterhoeven On Fri, 27 Oct 2006, Haavard Skinnemoen wrote: > On 10/27/06, Andrew Morton <akpm@osdl.org> wrote: > > From: Andrew Morton <akpm@osdl.org> > > > > Add a vmlinux.lds.h helper macro for defining the eight-level initcall > > table, > > teach all the architectures to use it. > > Please include AVR32 as well while you're at it ;) And m68k :-) Signed-Off-By: Geert Uytterhoeven <geert@linux-m68k.org> --- linux/arch/m68k/kernel/vmlinux-std.lds 2006-09-25 22:34:27.000000000 +0200 +++ linux-m68k/arch/m68k/kernel/vmlinux-std.lds 2006-10-29 11:15:18.000000000 +0100 @@ -54,13 +54,7 @@ SECTIONS __setup_end = .; __initcall_start = .; .initcall.init : { - *(.initcall1.init) - *(.initcall2.init) - *(.initcall3.init) - *(.initcall4.init) - *(.initcall5.init) - *(.initcall6.init) - *(.initcall7.init) + INITCALLS } __initcall_end = .; __con_initcall_start = .; --- linux/arch/m68k/kernel/vmlinux-sun3.lds 2006-09-25 22:34:27.000000000 +0200 +++ linux-m68k/arch/m68k/kernel/vmlinux-sun3.lds 2006-10-29 11:14:50.000000000 +0100 @@ -48,13 +48,7 @@ __init_begin = .; __setup_end = .; __initcall_start = .; .initcall.init : { - *(.initcall1.init) - *(.initcall2.init) - *(.initcall3.init) - *(.initcall4.init) - *(.initcall5.init) - *(.initcall6.init) - *(.initcall7.init) + INITCALLS } __initcall_end = .; __con_initcall_start = .; Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: vmlinux.lds: consolidate initcall sections 2006-10-27 18:41 ` vmlinux.lds: consolidate initcall sections Andrew Morton 2006-10-27 18:42 ` [patch] drivers: wait for threaded probes between initcall levels Andrew Morton 2006-10-27 19:31 ` vmlinux.lds: consolidate initcall sections Haavard Skinnemoen @ 2006-10-27 19:44 ` Matthew Wilcox 2006-10-27 20:17 ` Andrew Morton 2 siblings, 1 reply; 152+ messages in thread From: Matthew Wilcox @ 2006-10-27 19:44 UTC (permalink / raw) To: Andrew Morton Cc: Pavel Machek, Greg KH, Stephen Hemminger, Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List, linux-pci On Fri, Oct 27, 2006 at 11:41:44AM -0700, Andrew Morton wrote: > Add a vmlinux.lds.h helper macro for defining the eight-level initcall table, > teach all the architectures to use it. > @@ -48,13 +48,7 @@ SECTIONS > . = ALIGN(8); > __initcall_start = .; > .initcall.init : { > - *(.initcall1.init) > - *(.initcall2.init) > - *(.initcall3.init) > - *(.initcall4.init) > - *(.initcall5.init) > - *(.initcall6.init) > - *(.initcall7.init) > + INITCALLS > } > __initcall_end = .; Why not make the INITCALLS macro include more: +#define INITCALLS \ + __initcall_start = .; \ + .initcall.init : { \ + *(.initcall1.init) \ + *(.initcall2.init) \ + *(.initcall3.init) \ + *(.initcall4.init) \ + *(.initcall5.init) \ + *(.initcall6.init) \ + *(.initcall7.init) \ + } \ + __initcall_end = .; Also, you might want to check the spaces at the front of your INITCALLS macro; I see two spaces before the first tab. ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: vmlinux.lds: consolidate initcall sections 2006-10-27 19:44 ` Matthew Wilcox @ 2006-10-27 20:17 ` Andrew Morton 2006-10-27 20:27 ` Matthew Wilcox 0 siblings, 1 reply; 152+ messages in thread From: Andrew Morton @ 2006-10-27 20:17 UTC (permalink / raw) To: Matthew Wilcox Cc: Pavel Machek, Greg KH, Stephen Hemminger, Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List, linux-pci On Fri, 27 Oct 2006 13:44:13 -0600 Matthew Wilcox <matthew@wil.cx> wrote: > On Fri, Oct 27, 2006 at 11:41:44AM -0700, Andrew Morton wrote: > > Add a vmlinux.lds.h helper macro for defining the eight-level initcall table, > > teach all the architectures to use it. > > > @@ -48,13 +48,7 @@ SECTIONS > > . = ALIGN(8); > > __initcall_start = .; > > .initcall.init : { > > - *(.initcall1.init) > > - *(.initcall2.init) > > - *(.initcall3.init) > > - *(.initcall4.init) > > - *(.initcall5.init) > > - *(.initcall6.init) > > - *(.initcall7.init) > > + INITCALLS > > } > > __initcall_end = .; > > Why not make the INITCALLS macro include more: > > +#define INITCALLS \ > + __initcall_start = .; \ > + .initcall.init : { \ > + *(.initcall1.init) \ > + *(.initcall2.init) \ > + *(.initcall3.init) \ > + *(.initcall4.init) \ > + *(.initcall5.init) \ > + *(.initcall6.init) \ > + *(.initcall7.init) \ > + } \ > + __initcall_end = .; Would be nice, but i386 does: __initcall_start = .; .initcall.init : AT(ADDR(.initcall.init) - 0xC0000000) { *(.initcall1.init) *(.initcall2.init) ... > Also, you might want to check the spaces at the front of your INITCALLS > macro; I see two spaces before the first tab. thanks. ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: vmlinux.lds: consolidate initcall sections 2006-10-27 20:17 ` Andrew Morton @ 2006-10-27 20:27 ` Matthew Wilcox 0 siblings, 0 replies; 152+ messages in thread From: Matthew Wilcox @ 2006-10-27 20:27 UTC (permalink / raw) To: Andrew Morton Cc: Pavel Machek, Greg KH, Stephen Hemminger, Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List, linux-pci On Fri, Oct 27, 2006 at 01:17:30PM -0700, Andrew Morton wrote: > Would be nice, but i386 does: > > __initcall_start = .; > .initcall.init : AT(ADDR(.initcall.init) - 0xC0000000) { > *(.initcall1.init) Interesting ... but by the looks of SECURITY_INIT, we can support that by using LOAD_OFFSET ... ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN 2006-10-27 17:07 ` Greg KH 2006-10-27 17:22 ` Pavel Machek @ 2006-10-27 22:23 ` Adrian Bunk 2006-10-27 22:38 ` Andrew Morton 2006-10-27 23:03 ` Alan Cox 2006-10-27 22:57 ` Alan Cox 2 siblings, 2 replies; 152+ messages in thread From: Adrian Bunk @ 2006-10-27 22:23 UTC (permalink / raw) To: Greg KH Cc: Stephen Hemminger, Andrew Morton, Matthew Wilcox, Linus Torvalds, Linux Kernel Mailing List, Pavel Machek, linux-pci On Fri, Oct 27, 2006 at 10:07:48AM -0700, Greg KH wrote: > On Thu, Oct 26, 2006 at 07:11:31PM -0700, Stephen Hemminger wrote: > > On Thu, 26 Oct 2006 18:28:38 -0700 > > Andrew Morton <akpm@osdl.org> wrote: > > > > > On Thu, 26 Oct 2006 19:20:58 -0600 > > > Matthew Wilcox <matthew@wil.cx> wrote: > > > > > > > On Fri, Oct 27, 2006 at 03:02:52AM +0200, Adrian Bunk wrote: > > > > > PCI_MULTITHREAD_PROBE is an interesting feature, but in it's current > > > > > state it seems to be more of a trap for users who accidentally > > > > > enable it. > > > > > > > > > > This patch lets PCI_MULTITHREAD_PROBE depend on BROKEN for 2.6.19. > > > > > > > > > > The intention is to get this patch reversed in -mm as soon as it's in > > > > > Linus' tree, and reverse it for 2.6.20 or 2.6.21 after the fallout of > > > > > in-kernel problems PCI_MULTITHREAD_PROBE causes got fixed. > > > > > > > > People who enable features clearly marked as EXPERIMENTAL deserve what > > > > they get, IMO. > > > > > > It's not the impact on "people" which is of concern - it's the impact on > > > kernel developers - specifically those who spend time looking at bug > > > reports :( > > > > Either it is broken and should be removed, or is barely working and > > should be fixed. If Greg wants to take bug reports then it can stay. > > I want to keep taking bug reports. > > I've found only 1 real bug from all of this. The pci MSI initialization > issue. It's on my queue of things to fix. Andrew has also sent me > another "interesting" patch about making sure devices are found by the > time we hit another init level which I'll see about adding too. > > But that MSI bug was a real bug, which is good to have found. It's also > found other real bugs in other subsystems that could easily be hit by > other users. > > So no, this should not be marked BROKEN. > > It's a very experimental feature, as the help text says. If you can > think of any harsher language to put in that text, please let me know. The problem is that if only 1 out of 100 people who are compiling a kernel accidentally enable this option, linux-kernel will be swamped with bug reports... If it shouldn't be enabled by users, the only correct language is a dependency on BROKEN. And it doesn't matter whether PCI_MULTITHREAD_PROBE itself is buggy or whether it only exposes latent bugs in other subsystems - the effect is the same. > And yes, there also has been a proposed change to the driver core to fix > up how the multi-thread stuff works that looks very good, but it's down > in my queue that I'm trying to catch up on right now. > > So consider this a NAK for this change. > > thanks, > > greg k-h cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN 2006-10-27 22:23 ` [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN Adrian Bunk @ 2006-10-27 22:38 ` Andrew Morton 2006-10-28 1:08 ` Greg KH 2006-10-27 23:03 ` Alan Cox 1 sibling, 1 reply; 152+ messages in thread From: Andrew Morton @ 2006-10-27 22:38 UTC (permalink / raw) To: Adrian Bunk Cc: Greg KH, Stephen Hemminger, Matthew Wilcox, Linus Torvalds, Linux Kernel Mailing List, Pavel Machek, linux-pci On Sat, 28 Oct 2006 00:23:26 +0200 Adrian Bunk <bunk@stusta.de> wrote: > ... > > So no, this should not be marked BROKEN. > > > > It's a very experimental feature, as the help text says. If you can > > think of any harsher language to put in that text, please let me know. > > The problem is that if only 1 out of 100 people who are compiling a > kernel accidentally enable this option, linux-kernel will be swamped > with bug reports... > Yes, that's a legitimate practical concern, IMO. I guess many of the people who test -rc kernels have sufficient familarity to know to disable this option, but a lot of the people who test major releases do not. So how about we mark PCI_MULTITHREAD_PROBE as broken in 2.6.19-rc6, then revert that change in 2.6.20-rc1, and keep doing that until the feature is ready? ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN 2006-10-27 22:38 ` Andrew Morton @ 2006-10-28 1:08 ` Greg KH 0 siblings, 0 replies; 152+ messages in thread From: Greg KH @ 2006-10-28 1:08 UTC (permalink / raw) To: Andrew Morton Cc: Adrian Bunk, Stephen Hemminger, Matthew Wilcox, Linus Torvalds, Linux Kernel Mailing List, Pavel Machek, linux-pci On Fri, Oct 27, 2006 at 03:38:54PM -0700, Andrew Morton wrote: > On Sat, 28 Oct 2006 00:23:26 +0200 > Adrian Bunk <bunk@stusta.de> wrote: > > > ... > > > So no, this should not be marked BROKEN. > > > > > > It's a very experimental feature, as the help text says. If you can > > > think of any harsher language to put in that text, please let me know. > > > > The problem is that if only 1 out of 100 people who are compiling a > > kernel accidentally enable this option, linux-kernel will be swamped > > with bug reports... > > > > Yes, that's a legitimate practical concern, IMO. > > I guess many of the people who test -rc kernels have sufficient familarity > to know to disable this option, but a lot of the people who test major > releases do not. So how about we mark PCI_MULTITHREAD_PROBE as broken in > 2.6.19-rc6, then revert that change in 2.6.20-rc1, and keep doing that > until the feature is ready? Ok, I can live with that. I'll send in a change for this with the next round of driver core fixes. thanks, greg k-h ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN 2006-10-27 22:23 ` [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN Adrian Bunk 2006-10-27 22:38 ` Andrew Morton @ 2006-10-27 23:03 ` Alan Cox 1 sibling, 0 replies; 152+ messages in thread From: Alan Cox @ 2006-10-27 23:03 UTC (permalink / raw) To: Adrian Bunk Cc: Greg KH, Stephen Hemminger, Andrew Morton, Matthew Wilcox, Linus Torvalds, Linux Kernel Mailing List, Pavel Machek, linux-pci Ar Sad, 2006-10-28 am 00:23 +0200, ysgrifennodd Adrian Bunk: > The problem is that if only 1 out of 100 people who are compiling a > kernel accidentally enable this option, linux-kernel will be swamped > with bug reports... > > If it shouldn't be enabled by users, the only correct language is a > dependency on BROKEN. If Greg insists of NAKking this then will you please make IDE and ATA at least dependant on !MULTITHREADED_PROBE, as neither are safe with it selected. No I've no idea how you will boot a box with Greg's stuff after that either, but I'm just pointing out the correct dependancies as the code stands today. Alan ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN 2006-10-27 17:07 ` Greg KH 2006-10-27 17:22 ` Pavel Machek 2006-10-27 22:23 ` [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN Adrian Bunk @ 2006-10-27 22:57 ` Alan Cox 2 siblings, 0 replies; 152+ messages in thread From: Alan Cox @ 2006-10-27 22:57 UTC (permalink / raw) To: Greg KH Cc: Stephen Hemminger, Andrew Morton, Matthew Wilcox, Adrian Bunk, Linus Torvalds, Linux Kernel Mailing List, Pavel Machek, linux-pci Ar Gwe, 2006-10-27 am 10:07 -0700, ysgrifennodd Greg KH: > It's a very experimental feature, as the help text says. If you can > think of any harsher language to put in that text, please let me know. The ATA drivers use text like (RAVING LUNATIC) for such things. Realistically right now the multithread_probe stuff is useless because your hardware ends up randomly re-ordered and everything breaks. ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN 2006-10-27 1:20 ` Matthew Wilcox 2006-10-27 1:28 ` Andrew Morton @ 2006-10-27 8:27 ` Pavel Machek 1 sibling, 0 replies; 152+ messages in thread From: Pavel Machek @ 2006-10-27 8:27 UTC (permalink / raw) To: Matthew Wilcox Cc: Adrian Bunk, Linus Torvalds, Andrew Morton, Linux Kernel Mailing List, Greg KH, linux-pci, Stephen Hemminger On Thu 2006-10-26 19:20:58, Matthew Wilcox wrote: > On Fri, Oct 27, 2006 at 03:02:52AM +0200, Adrian Bunk wrote: > > PCI_MULTITHREAD_PROBE is an interesting feature, but in it's current > > state it seems to be more of a trap for users who accidentally > > enable it. > > > > This patch lets PCI_MULTITHREAD_PROBE depend on BROKEN for 2.6.19. > > > > The intention is to get this patch reversed in -mm as soon as it's in > > Linus' tree, and reverse it for 2.6.20 or 2.6.21 after the fallout of > > in-kernel problems PCI_MULTITHREAD_PROBE causes got fixed. > > People who enable features clearly marked as EXPERIMENTAL deserve what > they get, IMO. Eh? It is no longer "experimental". It went to "known broken in non-funny ways". People normally use experimental features... (like cpu hotplug, acpi hotkeys, intel 830m framebuffer, USB CATC ethernet, SDHCI, kernel profiling) without expecting breakages. (Hmm, perhaps some of these should not be marked experimental any more?) I'd actually vote for removing MULTITHREAD_PROBE from kconfig, temporarily, but I guess BROKEN is okay, too. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 152+ messages in thread
* 2.6.19-rc3: known unfixed regressions (v3) 2006-10-23 23:22 Linux 2.6.19-rc3 Linus Torvalds @ 2006-10-29 23:13 ` Adrian Bunk 2006-10-24 7:46 ` Muli Ben-Yehuda ` (6 subsequent siblings) 7 siblings, 0 replies; 152+ messages in thread From: Adrian Bunk @ 2006-10-29 23:13 UTC (permalink / raw) To: Linus Torvalds, Andrew Morton Cc: Linux Kernel Mailing List, Jeff Chua, gregkh, linux-pci, Prakash Punnoor, phil.el, oprofile-list, Martin Lorenz, len.brown, linux-acpi, Michael S. Tsirkin, Thierry Vignaud, jgarzik, linux-ide, Alex Romosan, Jens Axboe, Komuro, Thomas Gleixner, Christian, Mark Langsdorf, davej, cpufreq This email lists some known regressions in 2.6.19-rc3 compared to 2.6.18 that are not yet fixed in Linus' tree. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject : PCI: MMCONFIG breakage References : http://lkml.org/lkml/2006/10/23/182 Submitter : Jeff Chua <jeff.chua.linux@gmail.com> Status : unknown, both BIOS and Direct work Subject : x86_64: oprofile doesn't work References : http://lkml.org/lkml/2006/10/27/3 Submitter : Prakash Punnoor <prakash@punnoor.de> Status : unknown Subject : X60s: BUG()s, lose ACPI events after suspend/resume References : http://lkml.org/lkml/2006/10/10/39 Submitter : Martin Lorenz <martin@lorenz.eu.org> Status : unknown Subject : T60 stops triggering any ACPI events References : http://lkml.org/lkml/2006/10/4/425 http://lkml.org/lkml/2006/10/16/262 http://bugzilla.kernel.org/show_bug.cgi?id=7408 Submitter : "Michael S. Tsirkin" <mst@mellanox.co.il> Status : unknown Subject : sata-via doesn't detect anymore disks attached to VIA vt6421 References : http://bugzilla.kernel.org/show_bug.cgi?id=7255 Submitter : Thierry Vignaud <tvignaud@mandriva.com> Status : unknown Subject : unable to rip cd References : http://lkml.org/lkml/2006/10/13/100 Submitter : Alex Romosan <romosan@sycorax.lbl.gov> Status : unknown Subject : SMP kernel can not generate ISA irq properly References : http://lkml.org/lkml/2006/10/22/15 Submitter : Komuro <komurojun-mbn@nifty.com> Handled-By : Thomas Gleixner <tglx@linutronix.de> Status : Thomas will investigate Subject : cpufreq not working on AMD K8 References : http://lkml.org/lkml/2006/10/10/114 Submitter : Christian <christiand59@web.de> Handled-By : Mark Langsdorf <mark.langsdorf@amd.com> Status : Mark is investigating ^ permalink raw reply [flat|nested] 152+ messages in thread
* 2.6.19-rc3: known unfixed regressions (v3) @ 2006-10-29 23:13 ` Adrian Bunk 0 siblings, 0 replies; 152+ messages in thread From: Adrian Bunk @ 2006-10-29 23:13 UTC (permalink / raw) To: Linus Torvalds, Andrew Morton Cc: Linux Kernel Mailing List, Jeff Chua, gregkh, linux-pci, Prakash Punnoor, phil.el, oprofile-list, Martin Lorenz, len.brown, linux-acpi, Michael S. Tsirkin, Thierry Vignaud, jgarzik, linux-ide, Alex Romosan, Jens Axboe, Komuro, Thomas Gleixner, Christian, Mark Langsdorf, davej, cpufreq This email lists some known regressions in 2.6.19-rc3 compared to 2.6.18 that are not yet fixed in Linus' tree. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject : PCI: MMCONFIG breakage References : http://lkml.org/lkml/2006/10/23/182 Submitter : Jeff Chua <jeff.chua.linux@gmail.com> Status : unknown, both BIOS and Direct work Subject : x86_64: oprofile doesn't work References : http://lkml.org/lkml/2006/10/27/3 Submitter : Prakash Punnoor <prakash@punnoor.de> Status : unknown Subject : X60s: BUG()s, lose ACPI events after suspend/resume References : http://lkml.org/lkml/2006/10/10/39 Submitter : Martin Lorenz <martin@lorenz.eu.org> Status : unknown Subject : T60 stops triggering any ACPI events References : http://lkml.org/lkml/2006/10/4/425 http://lkml.org/lkml/2006/10/16/262 http://bugzilla.kernel.org/show_bug.cgi?id=7408 Submitter : "Michael S. Tsirkin" <mst@mellanox.co.il> Status : unknown Subject : sata-via doesn't detect anymore disks attached to VIA vt6421 References : http://bugzilla.kernel.org/show_bug.cgi?id=7255 Submitter : Thierry Vignaud <tvignaud@mandriva.com> Status : unknown Subject : unable to rip cd References : http://lkml.org/lkml/2006/10/13/100 Submitter : Alex Romosan <romosan@sycorax.lbl.gov> Status : unknown Subject : SMP kernel can not generate ISA irq properly References : http://lkml.org/lkml/2006/10/22/15 Submitter : Komuro <komurojun-mbn@nifty.com> Handled-By : Thomas Gleixner <tglx@linutronix.de> Status : Thomas will investigate Subject : cpufreq not working on AMD K8 References : http://lkml.org/lkml/2006/10/10/114 Submitter : Christian <christiand59@web.de> Handled-By : Mark Langsdorf <mark.langsdorf@amd.com> Status : Mark is investigating ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3) 2006-10-29 23:13 ` Adrian Bunk @ 2006-10-30 13:56 ` Michael S. Tsirkin -1 siblings, 0 replies; 152+ messages in thread From: Michael S. Tsirkin @ 2006-10-30 13:56 UTC (permalink / raw) To: Pavel Machek Cc: Andrew Morton, len.brown, Linus Torvalds, linux-pm, linux-acpi, Jun'ichi Nomura, Martin Lorenz, Linux Kernel Mailing List, Adrian Bunk Quoting r. Adrian Bunk <bunk@stusta.de>: > Subject : T60 stops triggering any ACPI events > References : http://lkml.org/lkml/2006/10/4/425 > http://lkml.org/lkml/2006/10/16/262 > http://bugzilla.kernel.org/show_bug.cgi?id=7408 > Submitter : "Michael S. Tsirkin" <mst@mellanox.co.il> > Status : unknown OK, I spent half a night with git-bisect, and the patch that triggers this issue seems to be this: commit d7dd8fd9557840162b724a8ac1366dd78a12dff Author: Andrew Morton <akpm@osdl.org> [PATCH] blockdev.c: check driver layer errors Reset to d7dd8fd9557840162b724a8ac1366dd78a12dff seems to hide part of the issue (I have ACPI after kernel build, but not after suspend/resume). Both reverting this patch, and reset to the parent of this patch seem to solve (or at least, hide) both problems for me (no ACPI after suspend/resume and no ACPI after kernel build). I am currently running on 2.6.19-rc3 minus d7dd8fd9557840162b724a8ac1366dd78a12dff, and in a full day of use I have not observed any issues yet. 2.6.19-rc3 without reverting d7dd8fd9557840162b724a8ac1366dd78a12dff stops receiving ACPI events after some use (sometimes after suspend/resume, sometimes after kernel build stress). Now, what does this tell us? Andrew, any idea? Martin, could you test whether reverting this helps you, too, by chance? Here's a patch to apply for testing this. --- commit 658488b7577b7b2242372c43f081f55e2d274615 Author: Michael S. Tsirkin <mst@mellanox.co.il> Date: Mon Oct 30 01:28:40 2006 +0200 Revert "[PATCH] blockdev.c: check driver layer errors" This reverts commit 4d7dd8fd9557840162b724a8ac1366dd78a12dff. diff --git a/fs/block_dev.c b/fs/block_dev.c index bc8f27c..b15ad29 100644 --- a/fs/block_dev.c +++ b/fs/block_dev.c @@ -545,11 +545,11 @@ static struct kobject *bdev_get_holder(s return kobject_get(bdev->bd_disk->holder_dir); } -static int add_symlink(struct kobject *from, struct kobject *to) +static void add_symlink(struct kobject *from, struct kobject *to) { if (!from || !to) - return 0; - return sysfs_create_link(from, to, kobject_name(to)); + return; + sysfs_create_link(from, to, kobject_name(to)); } static void del_symlink(struct kobject *from, struct kobject *to) @@ -650,38 +650,30 @@ static void free_bd_holder(struct bd_hol * If there is no matching entry with @bo in @bdev->bd_holder_list, * add @bo to the list, create symlinks. * - * Returns 0 if symlinks are created or already there. - * Returns -ve if something fails and @bo can be freed. + * Returns 1 if @bo was added to the list. + * Returns 0 if @bo wasn't used by any reason and should be freed. */ static int add_bd_holder(struct block_device *bdev, struct bd_holder *bo) { struct bd_holder *tmp; - int ret; if (!bo) - return -EINVAL; + return 0; list_for_each_entry(tmp, &bdev->bd_holder_list, list) { if (tmp->sdir == bo->sdir) { tmp->count++; - /* We've already done what we need to do here. */ - free_bd_holder(bo); return 0; } } if (!bd_holder_grab_dirs(bdev, bo)) - return -EBUSY; + return 0; - ret = add_symlink(bo->sdir, bo->sdev); - if (ret == 0) { - ret = add_symlink(bo->hdir, bo->hdev); - if (ret) - del_symlink(bo->sdir, bo->sdev); - } - if (ret == 0) - list_add_tail(&bo->list, &bdev->bd_holder_list); - return ret; + add_symlink(bo->sdir, bo->sdev); + add_symlink(bo->hdir, bo->hdev); + list_add_tail(&bo->list, &bdev->bd_holder_list); + return 1; } /** @@ -751,9 +743,7 @@ static int bd_claim_by_kobject(struct bl mutex_lock_nested(&bdev->bd_mutex, BD_MUTEX_PARTITION); res = bd_claim(bdev, holder); - if (res == 0) - res = add_bd_holder(bdev, bo); - if (res) + if (res || !add_bd_holder(bdev, bo)) free_bd_holder(bo); mutex_unlock(&bdev->bd_mutex); -- MST ^ permalink raw reply related [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3) @ 2006-10-30 13:56 ` Michael S. Tsirkin 0 siblings, 0 replies; 152+ messages in thread From: Michael S. Tsirkin @ 2006-10-30 13:56 UTC (permalink / raw) To: Pavel Machek Cc: Adrian Bunk, Linus Torvalds, Andrew Morton, Linux Kernel Mailing List, len.brown, linux-acpi, linux-pm, Jun'ichi Nomura, Randy.Dunlap, Martin Lorenz Quoting r. Adrian Bunk <bunk@stusta.de>: > Subject : T60 stops triggering any ACPI events > References : http://lkml.org/lkml/2006/10/4/425 > http://lkml.org/lkml/2006/10/16/262 > http://bugzilla.kernel.org/show_bug.cgi?id=7408 > Submitter : "Michael S. Tsirkin" <mst@mellanox.co.il> > Status : unknown OK, I spent half a night with git-bisect, and the patch that triggers this issue seems to be this: commit d7dd8fd9557840162b724a8ac1366dd78a12dff Author: Andrew Morton <akpm@osdl.org> [PATCH] blockdev.c: check driver layer errors Reset to d7dd8fd9557840162b724a8ac1366dd78a12dff seems to hide part of the issue (I have ACPI after kernel build, but not after suspend/resume). Both reverting this patch, and reset to the parent of this patch seem to solve (or at least, hide) both problems for me (no ACPI after suspend/resume and no ACPI after kernel build). I am currently running on 2.6.19-rc3 minus d7dd8fd9557840162b724a8ac1366dd78a12dff, and in a full day of use I have not observed any issues yet. 2.6.19-rc3 without reverting d7dd8fd9557840162b724a8ac1366dd78a12dff stops receiving ACPI events after some use (sometimes after suspend/resume, sometimes after kernel build stress). Now, what does this tell us? Andrew, any idea? Martin, could you test whether reverting this helps you, too, by chance? Here's a patch to apply for testing this. --- commit 658488b7577b7b2242372c43f081f55e2d274615 Author: Michael S. Tsirkin <mst@mellanox.co.il> Date: Mon Oct 30 01:28:40 2006 +0200 Revert "[PATCH] blockdev.c: check driver layer errors" This reverts commit 4d7dd8fd9557840162b724a8ac1366dd78a12dff. diff --git a/fs/block_dev.c b/fs/block_dev.c index bc8f27c..b15ad29 100644 --- a/fs/block_dev.c +++ b/fs/block_dev.c @@ -545,11 +545,11 @@ static struct kobject *bdev_get_holder(s return kobject_get(bdev->bd_disk->holder_dir); } -static int add_symlink(struct kobject *from, struct kobject *to) +static void add_symlink(struct kobject *from, struct kobject *to) { if (!from || !to) - return 0; - return sysfs_create_link(from, to, kobject_name(to)); + return; + sysfs_create_link(from, to, kobject_name(to)); } static void del_symlink(struct kobject *from, struct kobject *to) @@ -650,38 +650,30 @@ static void free_bd_holder(struct bd_hol * If there is no matching entry with @bo in @bdev->bd_holder_list, * add @bo to the list, create symlinks. * - * Returns 0 if symlinks are created or already there. - * Returns -ve if something fails and @bo can be freed. + * Returns 1 if @bo was added to the list. + * Returns 0 if @bo wasn't used by any reason and should be freed. */ static int add_bd_holder(struct block_device *bdev, struct bd_holder *bo) { struct bd_holder *tmp; - int ret; if (!bo) - return -EINVAL; + return 0; list_for_each_entry(tmp, &bdev->bd_holder_list, list) { if (tmp->sdir == bo->sdir) { tmp->count++; - /* We've already done what we need to do here. */ - free_bd_holder(bo); return 0; } } if (!bd_holder_grab_dirs(bdev, bo)) - return -EBUSY; + return 0; - ret = add_symlink(bo->sdir, bo->sdev); - if (ret == 0) { - ret = add_symlink(bo->hdir, bo->hdev); - if (ret) - del_symlink(bo->sdir, bo->sdev); - } - if (ret == 0) - list_add_tail(&bo->list, &bdev->bd_holder_list); - return ret; + add_symlink(bo->sdir, bo->sdev); + add_symlink(bo->hdir, bo->hdev); + list_add_tail(&bo->list, &bdev->bd_holder_list); + return 1; } /** @@ -751,9 +743,7 @@ static int bd_claim_by_kobject(struct bl mutex_lock_nested(&bdev->bd_mutex, BD_MUTEX_PARTITION); res = bd_claim(bdev, holder); - if (res == 0) - res = add_bd_holder(bdev, bo); - if (res) + if (res || !add_bd_holder(bdev, bo)) free_bd_holder(bo); mutex_unlock(&bdev->bd_mutex); -- MST ^ permalink raw reply related [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3) 2006-10-30 13:56 ` Michael S. Tsirkin (?) @ 2006-10-30 15:27 ` Martin Lorenz -1 siblings, 0 replies; 152+ messages in thread From: Martin Lorenz @ 2006-10-30 15:27 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Andrew Morton, len.brown, linux-pm, linux-acpi, Linus Torvalds, Jun'ichi Nomura, Linux Kernel Mailing List, Adrian Bunk [-- Attachment #1: Type: text/plain, Size: 1536 bytes --] On Mon, Oct 30, 2006 at 03:56:26PM +0200, Michael S. Tsirkin wrote: > Quoting r. Adrian Bunk <bunk@stusta.de>: > > Subject : T60 stops triggering any ACPI events > > References : http://lkml.org/lkml/2006/10/4/425 > > http://lkml.org/lkml/2006/10/16/262 > > http://bugzilla.kernel.org/show_bug.cgi?id=7408 > > Submitter : "Michael S. Tsirkin" <mst@mellanox.co.il> > > Status : unknown > > OK, I spent half a night with git-bisect, and the patch that triggers this issue > seems to be this: > > commit d7dd8fd9557840162b724a8ac1366dd78a12dff great! I was about bisecting myself this weekend but had to let go in favour of my daughter... thank you for that > I am currently running on 2.6.19-rc3 minus > d7dd8fd9557840162b724a8ac1366dd78a12dff, and in a full day of use I have not applied your patch and compiling... but I can hardly belive something in the block_dev layer can interfere with ACPI to result in the behavieour we experienced > 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 and it dosen't change anything for me 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 [-- Attachment #2: dmesg.2.6.19-rc3-ts-tp-ie-e1-44.1+1430-g06df5d4f-dirty.boot --] [-- Type: text/plain, Size: 31340 bytes --] 0.000000] Normal 4096 -> 229376 [ 0.000000] HighMem 229376 -> 521952 [ 0.000000] early_node_map[1] active PFN ranges [ 0.000000] 0: 0 -> 521952 [ 0.000000] On node 0 totalpages: 521952 [ 0.000000] DMA zone: 32 pages used for memmap [ 0.000000] DMA zone: 0 pages reserved [ 0.000000] DMA zone: 4064 pages, LIFO batch:0 [ 0.000000] Normal zone: 1760 pages used for memmap [ 0.000000] Normal zone: 223520 pages, LIFO batch:31 [ 0.000000] HighMem zone: 2285 pages used for memmap [ 0.000000] HighMem zone: 290291 pages, LIFO batch:31 [ 0.000000] DMI present. [ 0.000000] ACPI: RSDP (v002 LENOVO ) @ 0x000f6870 [ 0.000000] ACPI: XSDT (v001 LENOVO TP-7B 0x00001100 LTP 0x00000000) @ 0x7f6e6526 [ 0.000000] ACPI: FADT (v003 LENOVO TP-7B 0x00001100 LNVO 0x00000001) @ 0x7f6e6600 [ 0.000000] ACPI: SSDT (v001 LENOVO TP-7B 0x00001100 MSFT 0x0100000e) @ 0x7f6e67b4 [ 0.000000] ACPI: ECDT (v001 LENOVO TP-7B 0x00001100 LNVO 0x00000001) @ 0x7f6f2d45 [ 0.000000] ACPI: TCPA (v002 LENOVO TP-7B 0x00001100 LNVO 0x00000001) @ 0x7f6f2d97 [ 0.000000] ACPI: MADT (v001 LENOVO TP-7B 0x00001100 LNVO 0x00000001) @ 0x7f6f2dc9 [ 0.000000] ACPI: MCFG (v001 LENOVO TP-7B 0x00001100 LNVO 0x00000001) @ 0x7f6f2e31 [ 0.000000] ACPI: HPET (v001 LENOVO TP-7B 0x00001100 LNVO 0x00000001) @ 0x7f6f2e6f [ 0.000000] ACPI: BOOT (v001 LENOVO TP-7B 0x00001100 LTP 0x00000001) @ 0x7f6f2fd8 [ 0.000000] ACPI: SSDT (v001 LENOVO TP-7B 0x00001100 INTL 0x20050513) @ 0x7f6e5ae1 [ 0.000000] ACPI: SSDT (v001 LENOVO TP-7B 0x00001100 INTL 0x20050513) @ 0x7f6e5909 [ 0.000000] ACPI: DSDT (v001 LENOVO TP-7B 0x00001100 MSFT 0x0100000e) @ 0x00000000 [ 0.000000] ACPI: PM-Timer IO Port: 0x1008 [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [ 0.000000] Processor #0 6:14 APIC version 20 [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) [ 0.000000] Processor #1 6:14 APIC version 20 [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) [ 0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [ 0.000000] ACPI: IRQ0 used by override. [ 0.000000] ACPI: IRQ2 used by override. [ 0.000000] ACPI: IRQ9 used by override. [ 0.000000] Enabling APIC mode: Flat. Using 1 I/O APICs [ 0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000 [ 0.000000] Using ACPI (MADT) for SMP configuration information [ 0.000000] Allocating PCI resources starting at 88000000 (gap: 80000000:70000000) [ 0.000000] Detected 1662.624 MHz processor. [ 10.539368] Built 1 zonelists. Total pages: 517875 [ 10.539373] Kernel command line: root=/dev/sda5 ro resume [ 10.539720] mapped APIC to ffffd000 (fee00000) [ 10.539724] mapped IOAPIC to ffffc000 (fec00000) [ 10.539728] Enabling fast FPU save and restore... done. [ 10.539733] Enabling unmasked SIMD FPU exception support... done. [ 10.539737] Initializing CPU#0 [ 10.539818] PID hash table entries: 4096 (order: 12, 16384 bytes) [ 10.541567] Console: colour VGA+ 80x25 [ 10.545995] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [ 10.546589] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [ 10.688172] Memory: 2065788k/2087808k available (1949k kernel code, 20860k reserved, 775k data, 176k init, 1170304k highmem) [ 10.688330] virtual kernel memory layout: [ 10.688332] fixmap : 0xfff9d000 - 0xfffff000 ( 392 kB) [ 10.688334] pkmap : 0xff800000 - 0xffc00000 (4096 kB) [ 10.688336] vmalloc : 0xf8800000 - 0xff7fe000 ( 111 MB) [ 10.688339] lowmem : 0xc0000000 - 0xf8000000 ( 896 MB) [ 10.688341] .init : 0xc0400000 - 0xc042c000 ( 176 kB) [ 10.688343] .data : 0xc02e77a9 - 0xc03a9414 ( 775 kB) [ 10.688346] .text : 0xc0100000 - 0xc02e77a9 (1949 kB) [ 10.689084] Checking if this processor honours the WP bit even in supervisor mode... Ok. [ 10.689471] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0 [ 10.689749] hpet0: 3 64-bit timers, 14318180 Hz [ 10.690845] Using HPET for base-timer [ 10.750381] Calibrating delay using timer specific routine.. 3328.29 BogoMIPS (lpj=1664148) [ 10.750612] Security Framework v1.0.0 initialized [ 10.750710] Capability LSM initialized [ 10.750819] Mount-cache hash table entries: 512 [ 10.751046] CPU: After generic identify, caps: bfe9fbff 00100000 00000000 00000000 0000c1a9 00000000 00000000 [ 10.751058] monitor/mwait feature present. [ 10.751150] using mwait in idle threads. [ 10.751243] CPU: L1 I cache: 32K, L1 D cache: 32K [ 10.751392] CPU: L2 cache: 2048K [ 10.751481] CPU: Physical Processor ID: 0 [ 10.751571] CPU: Processor Core ID: 0 [ 10.751661] CPU: After all inits, caps: bfe9fbff 00100000 00000000 00000940 0000c1a9 00000000 00000000 [ 10.751672] Intel machine check architecture supported. [ 10.751771] Intel machine check reporting enabled on CPU#0. [ 10.751869] Compat vDSO mapped to ffffe000. [ 10.751972] Checking 'hlt' instruction... OK. [ 10.755540] SMP alternatives: switching to UP code [ 10.755838] ACPI: Core revision 20060707 [ 10.779647] CPU0: Intel Genuine Intel(R) CPU L2400 @ 1.66GHz stepping 08 [ 10.779925] SMP alternatives: switching to SMP code [ 10.780081] Booting processor 1/1 eip 3000 [ 10.791299] Initializing CPU#1 [ 10.851566] Calibrating delay using timer specific routine.. 3325.08 BogoMIPS (lpj=1662541) [ 10.851575] CPU: After generic identify, caps: bfe9fbff 00100000 00000000 00000000 0000c1a9 00000000 00000000 [ 10.851584] monitor/mwait feature present. [ 10.851589] CPU: L1 I cache: 32K, L1 D cache: 32K [ 10.851593] CPU: L2 cache: 2048K [ 10.851596] CPU: Physical Processor ID: 0 [ 10.851599] CPU: Processor Core ID: 1 [ 10.851601] CPU: After all inits, caps: bfe9fbff 00100000 00000000 00000940 0000c1a9 00000000 00000000 [ 10.851610] Intel machine check architecture supported. [ 10.851619] Intel machine check reporting enabled on CPU#1. [ 10.851890] CPU1: Intel Genuine Intel(R) CPU L2400 @ 1.66GHz stepping 08 [ 10.853013] Total of 2 processors activated (6653.37 BogoMIPS). [ 10.853317] ENABLING IO-APIC IRQs [ 10.853624] ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 [ 10.965046] checking TSC synchronization across 2 CPUs: [ 0.000086] CPU#0 had -172 usecs TSC skew, fixed it up. [ 0.000181] CPU#1 had 172 usecs TSC skew, fixed it up. [ 0.000949] Brought up 2 CPUs [ 0.307634] migration_cost=117 [ 0.308430] NET: Registered protocol family 16 [ 0.308637] ACPI: bus type pci registered [ 0.308735] PCI: Using MMCONFIG [ 0.309658] Setting up standard PCI resources [ 0.328979] ACPI: Interpreter enabled [ 0.329072] ACPI: Using IOAPIC for interrupt routing [ 0.330596] ACPI: PCI Interrupt Link [LNKA] (IRQs *3 4 5 6 7 9 10 11) [ 0.332204] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 *4 5 6 7 9 10 11) [ 0.333820] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 9 10 11) [ 0.335446] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 *6 7 9 10 11) [ 0.337062] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 *11) [ 0.338682] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 *11) [ 0.340286] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 *10 11) [ 0.341902] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 *11) [ 0.343116] ACPI: PCI Root Bridge [PCI0] (0000:00) [ 0.343214] PCI: Probing PCI hardware (bus 00) [ 0.348387] Boot video device is 0000:00:02.0 [ 0.348988] PCI quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO [ 0.349086] PCI quirk: region 1180-11bf claimed by ICH6 GPIO [ 0.349227] PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1 [ 0.350564] PCI: Transparent bridge - 0000:00:1e.0 [ 0.350806] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] [ 0.358912] ACPI: Power Resource [PUBS] (on) [ 0.361453] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP0._PRT] [ 0.361772] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP1._PRT] [ 0.362089] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP2._PRT] [ 0.362477] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP3._PRT] [ 0.362853] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT] [ 0.365662] Linux Plug and Play Support v0.97 (c) Adam Belay [ 0.365766] pnp: PnP ACPI init [ 0.372613] pnp: PnP ACPI: found 12 devices [ 0.372737] intel_rng: FWH not detected [ 0.373008] SCSI subsystem initialized [ 0.373188] PCI: Using ACPI for IRQ routing [ 0.373280] PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report [ 0.374947] PCI: Ignore bogus resource 6 [0:0] of 0000:00:02.0 [ 0.375046] PCI: Bridge: 0000:00:1c.0 [ 0.375138] IO window: 2000-2fff [ 0.375231] MEM window: ee000000-ee0fffff [ 0.375323] PREFETCH window: disabled. [ 0.375425] PCI: Bridge: 0000:00:1c.1 [ 0.375516] IO window: 3000-4fff [ 0.375609] MEM window: ec000000-edffffff [ 0.375702] PREFETCH window: e4000000-e40fffff [ 0.375798] PCI: Bridge: 0000:00:1c.2 [ 0.375891] IO window: 5000-6fff [ 0.375985] MEM window: e8000000-e9ffffff [ 0.376080] PREFETCH window: e4100000-e41fffff [ 0.376175] PCI: Bridge: 0000:00:1c.3 [ 0.376267] IO window: 7000-8fff [ 0.376370] MEM window: ea000000-ebffffff [ 0.376465] PREFETCH window: e4200000-e42fffff [ 0.376567] PCI: Bus 22, cardbus bridge: 0000:15:00.0 [ 0.376661] IO window: 00009000-000090ff [ 0.376756] IO window: 00009400-000094ff [ 0.376852] PREFETCH window: e0000000-e1ffffff [ 0.376948] MEM window: e6000000-e7ffffff [ 0.377042] PCI: Bridge: 0000:00:1e.0 [ 0.377135] IO window: 9000-cfff [ 0.377229] MEM window: e4300000-e7ffffff [ 0.377324] PREFETCH window: e0000000-e3ffffff [ 0.377449] ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 20 (level, low) -> IRQ 16 [ 0.377635] PCI: Setting latency timer of device 0000:00:1c.0 to 64 [ 0.377658] ACPI: PCI Interrupt 0000:00:1c.1[B] -> GSI 21 (level, low) -> IRQ 17 [ 0.377843] PCI: Setting latency timer of device 0000:00:1c.1 to 64 [ 0.377866] ACPI: PCI Interrupt 0000:00:1c.2[C] -> GSI 22 (level, low) -> IRQ 18 [ 0.378050] PCI: Setting latency timer of device 0000:00:1c.2 to 64 [ 0.378072] ACPI: PCI Interrupt 0000:00:1c.3[D] -> GSI 23 (level, low) -> IRQ 19 [ 0.378257] PCI: Setting latency timer of device 0000:00:1c.3 to 64 [ 0.378268] PCI: Enabling device 0000:00:1e.0 (0005 -> 0007) [ 0.378374] PCI: Setting latency timer of device 0000:00:1e.0 to 64 [ 0.378393] ACPI: PCI Interrupt 0000:15:00.0[A] -> GSI 16 (level, low) -> IRQ 20 [ 0.378579] PCI: Setting latency timer of device 0000:15:00.0 to 64 [ 0.378614] NET: Registered protocol family 2 [ 0.391378] IP route cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.391621] TCP established hash table entries: 262144 (order: 9, 2097152 bytes) [ 0.394548] TCP bind hash table entries: 65536 (order: 7, 524288 bytes) [ 0.395357] TCP: Hash tables configured (established 262144 bind 65536) [ 0.395453] TCP reno registered [ 0.395768] Simple Boot Flag at 0x35 set to 0x1 [ 0.396509] audit: initializing netlink socket (disabled) [ 0.396620] audit(1162223349.853:1): initialized [ 0.396812] highmem bounce pool size: 64 pages [ 0.397170] io scheduler noop registered [ 0.397313] io scheduler anticipatory registered [ 0.397454] io scheduler deadline registered [ 0.397607] io scheduler cfq registered (default) [ 0.398102] PCI: Setting latency timer of device 0000:00:1c.0 to 64 [ 0.398156] assign_interrupt_mode Found MSI capability [ 0.398309] Allocate Port Service[0000:00:1c.0:pcie00] [ 0.398370] Allocate Port Service[0000:00:1c.0:pcie02] [ 0.398428] Allocate Port Service[0000:00:1c.0:pcie03] [ 0.398548] PCI: Setting latency timer of device 0000:00:1c.1 to 64 [ 0.398601] assign_interrupt_mode Found MSI capability [ 0.399564] Allocate Port Service[0000:00:1c.1:pcie00] [ 0.399614] Allocate Port Service[0000:00:1c.1:pcie02] [ 0.399661] Allocate Port Service[0000:00:1c.1:pcie03] [ 0.399775] PCI: Setting latency timer of device 0000:00:1c.2 to 64 [ 0.399828] assign_interrupt_mode Found MSI capability [ 0.399962] Allocate Port Service[0000:00:1c.2:pcie00] [ 0.400009] Allocate Port Service[0000:00:1c.2:pcie02] [ 0.400061] Allocate Port Service[0000:00:1c.2:pcie03] [ 0.400175] PCI: Setting latency timer of device 0000:00:1c.3 to 64 [ 0.400228] assign_interrupt_mode Found MSI capability [ 0.400368] Allocate Port Service[0000:00:1c.3:pcie00] [ 0.400418] Allocate Port Service[0000:00:1c.3:pcie02] [ 0.400465] Allocate Port Service[0000:00:1c.3:pcie03] [ 0.433651] Real Time Clock Driver v1.12ac [ 0.433809] hpet_resources: 0xfed00000 is busy [ 0.433837] Linux agpgart interface v0.101 (c) Dave Jones [ 0.433975] agpgart: Detected an Intel 945GM Chipset. [ 0.435945] agpgart: Detected 7932K stolen memory. [ 0.453538] agpgart: AGP aperture is 256M @ 0xd0000000 [ 0.453679] [drm] Initialized drm 1.0.1 20051102 [ 0.454166] loop: loaded (max 8 devices) [ 0.454264] Intel(R) PRO/1000 Network Driver - version 7.2.9-k2-NAPI [ 0.454358] Copyright (c) 1999-2006 Intel Corporation. [ 0.454526] ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 20 [ 0.454719] PCI: Setting latency timer of device 0000:02:00.0 to 64 [ 0.460267] e1000: 0000:02:00.0: e1000_probe: (PCI Express:2.5Gb/s:32-bit) 00:16:d3:22:9b:82 [ 0.505134] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection [ 0.505373] netconsole: not configured, aborting [ 0.505579] libata version 2.00 loaded. [ 0.505629] ahci 0000:00:1f.2: version 2.0 [ 0.505647] ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 16 (level, low) -> IRQ 20 [ 1.507573] PCI: Setting latency timer of device 0000:00:1f.2 to 64 [ 1.507583] ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 4 ports 1.5 Gbps 0x1 impl SATA mode [ 1.507722] ahci 0000:00:1f.2: flags: 64bit ncq pm led clo pio slum part [ 1.507910] ata1: SATA max UDMA/133 cmd 0xF8824500 ctl 0x0 bmdma 0x0 irq 219 [ 1.508079] ata2: SATA max UDMA/133 cmd 0xF8824580 ctl 0x0 bmdma 0x0 irq 219 [ 1.508251] ata3: SATA max UDMA/133 cmd 0xF8824600 ctl 0x0 bmdma 0x0 irq 219 [ 1.508419] ata4: SATA max UDMA/133 cmd 0xF8824680 ctl 0x0 bmdma 0x0 irq 219 [ 1.508524] scsi0 : ahci [ 1.966832] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 1.967289] ata1.00: ATA-7, max UDMA/100, 156301488 sectors: LBA48 NCQ (depth 31/32) [ 1.967424] ata1.00: ata1: dev 0 multi count 16 [ 1.969850] ata1.00: configured for UDMA/100 [ 1.969952] scsi1 : ahci [ 2.273333] ata2: SATA link down (SStatus 0 SControl 0) [ 2.273440] scsi2 : ahci [ 2.576850] ata3: SATA link down (SStatus 0 SControl 0) [ 2.576953] scsi3 : ahci [ 2.880368] ata4: SATA link down (SStatus 0 SControl 0) [ 2.880597] scsi 0:0:0:0: Direct-Access ATA FUJITSU MHV2080B 0084 PQ: 0 ANSI: 5 [ 2.880870] SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) [ 2.880982] sda: Write Protect is off [ 2.881073] sda: Mode Sense: 00 3a 00 00 [ 2.881099] SCSI device sda: drive cache: write back [ 2.881251] SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) [ 2.881362] sda: Write Protect is off [ 2.881453] sda: Mode Sense: 00 3a 00 00 [ 2.881478] SCSI device sda: drive cache: write back [ 2.881575] sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 sda9 sda10 sda11 sda12 sda13 sda14 > [ 3.052953] sd 0:0:0:0: Attached scsi disk sda [ 3.053295] PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12 [ 3.064269] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 3.064367] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 3.064626] mice: PS/2 mouse device common for all mice [ 3.064722] i2c /dev entries driver [ 3.064957] ACPI: PCI Interrupt 0000:00:1f.3[A] -> GSI 23 (level, low) -> IRQ 19 [ 3.065268] hdaps: LENOVO ThinkPad X60 detected, inverting axes [ 3.069987] input: AT Translated Set 2 keyboard as /class/input/input0 [ 3.076297] hdaps: initial mode latch is 0x05 [ 3.076468] hdaps: setting ec_rate=250, filter_order=2 [ 3.076509] hdaps: fake_data_mode set to 0 [ 3.076732] hdaps: device successfully initialized. [ 3.076906] input: hdaps as /class/input/input1 [ 3.076999] hdaps: driver successfully loaded. [ 3.077093] EDAC MC: Ver: 2.0.1 Oct 30 2006 [ 3.077714] thinkpad_ec: thinkpad_ec 0.30 loaded. [ 3.077956] TCP bic registered [ 3.078057] NET: Registered protocol family 1 [ 3.078153] NET: Registered protocol family 17 [ 3.078263] Starting balanced_irq [ 3.078359] Using IPI No-Shortcut mode [ 3.078884] ACPI: (supports S0 S3 S4 S5) [ 3.079246] Time: tsc clocksource has been installed. [ 3.079386] BIOS EDD facility v0.16 2004-Jun-25, 1 devices found [ 3.082224] VFS: Mounted root (ext2 filesystem) readonly. [ 3.082457] Freeing unused kernel memory: 176k freed [ 6.179063] ieee1394: Initialized config rom entry `ip1394' [ 6.181760] ACPI: PCI Interrupt 0000:15:00.1[B] -> GSI 17 (level, low) -> IRQ 21 [ 6.181958] PCI: Setting latency timer of device 0000:15:00.1 to 64 [ 6.235209] ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[21] MMIO=[e4301000-e43017ff] Max Packet=[2048] IR/IT contexts=[4/4] [ 6.349287] input: PC Speaker as /class/input/input2 [ 6.712159] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 [ 6.712263] ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx [ 6.908445] usbcore: registered new interface driver usbfs [ 6.908579] usbcore: registered new interface driver hub [ 6.908711] usbcore: registered new device driver usb [ 7.089196] irda_init() [ 7.089213] NET: Registered protocol family 23 [ 7.146382] USB Universal Host Controller Interface driver v3.0 [ 7.146545] ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 20 [ 7.146745] PCI: Setting latency timer of device 0000:00:1d.0 to 64 [ 7.146751] uhci_hcd 0000:00:1d.0: UHCI Host Controller [ 7.147058] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1 [ 7.147234] uhci_hcd 0000:00:1d.0: irq 20, io base 0x00001820 [ 7.147488] usb usb1: configuration #1 chosen from 1 choice [ 7.147628] hub 1-0:1.0: USB hub found [ 7.147726] hub 1-0:1.0: 2 ports detected [ 7.198161] sdhci: Secure Digital Host Controller Interface driver, 0.12 [ 7.198263] sdhci: Copyright(c) Pierre Ossman [ 7.248594] ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 17 (level, low) -> IRQ 21 [ 7.248798] PCI: Setting latency timer of device 0000:00:1d.1 to 64 [ 7.248804] uhci_hcd 0000:00:1d.1: UHCI Host Controller [ 7.248942] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 2 [ 7.249108] uhci_hcd 0000:00:1d.1: irq 21, io base 0x00001840 [ 7.249338] usb usb2: configuration #1 chosen from 1 choice [ 7.249818] hub 2-0:1.0: USB hub found [ 7.249917] hub 2-0:1.0: 2 ports detected [ 7.351432] ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 22 [ 7.351634] PCI: Setting latency timer of device 0000:00:1d.2 to 64 [ 7.351640] uhci_hcd 0000:00:1d.2: UHCI Host Controller [ 7.351771] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 3 [ 7.351940] uhci_hcd 0000:00:1d.2: irq 22, io base 0x00001860 [ 7.352165] usb usb3: configuration #1 chosen from 1 choice [ 7.352305] hub 3-0:1.0: USB hub found [ 7.352401] hub 3-0:1.0: 2 ports detected [ 7.453217] ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 19 (level, low) -> IRQ 23 [ 7.453403] PCI: Setting latency timer of device 0000:00:1d.3 to 64 [ 7.453408] uhci_hcd 0000:00:1d.3: UHCI Host Controller [ 7.453537] uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 4 [ 7.453701] uhci_hcd 0000:00:1d.3: irq 23, io base 0x00001880 [ 7.453921] usb usb4: configuration #1 chosen from 1 choice [ 7.454051] hub 4-0:1.0: USB hub found [ 7.454150] hub 4-0:1.0: 2 ports detected [ 7.499170] ieee1394: Host added: ID:BUS[0-00:1023] GUID[000ae40600192017] [ 7.555770] ACPI: PCI Interrupt 0000:00:1d.7[D] -> GSI 19 (level, low) -> IRQ 23 [ 7.555969] PCI: Setting latency timer of device 0000:00:1d.7 to 64 [ 7.555975] ehci_hcd 0000:00:1d.7: EHCI Host Controller [ 7.556109] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 5 [ 7.556283] ehci_hcd 0000:00:1d.7: debug port 1 [ 7.556384] PCI: cache line size of 32 is not supported by device 0000:00:1d.7 [ 7.556395] ehci_hcd 0000:00:1d.7: irq 23, io mem 0xee444000 [ 7.560381] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 [ 7.560837] usb usb5: configuration #1 chosen from 1 choice [ 7.560967] hub 5-0:1.0: USB hub found [ 7.561064] hub 5-0:1.0: 8 ports detected [ 7.563438] eth1394: eth1: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0) [ 7.637032] IBM TrackPoint firmware: 0x0e, buttons: 3/3 [ 7.657935] input: TPPS/2 IBM TrackPoint as /class/input/input3 [ 7.661955] Yenta: CardBus bridge found at 0000:15:00.0 [17aa:201c] [ 7.663374] pnp: Device 00:0a activated. [ 7.663471] nsc_ircc_pnp_probe() : From PnP, found firbase 0x2F8 ; irq 7 ; dma 1. [ 7.663500] nsc-ircc, chip->init [ 7.663605] nsc-ircc, Found chip at base=0x164e [ 7.663738] nsc-ircc, driver loaded (Dag Brattli) [ 7.663925] IrDA: Registered device irda0 [ 7.664080] nsc-ircc, Found dongle: No dongle connected [ 7.664183] nsc_ircc_init_dongle_interface(), No dongle connected [ 7.785417] Yenta: ISA IRQ mask 0x0c38, PCI irq 20 [ 7.785519] Socket status: 30000006 [ 7.785615] pcmcia: parent PCI bridge I/O window: 0x9000 - 0xcfff [ 7.785713] pcmcia: parent PCI bridge Memory window: 0xe4300000 - 0xe7ffffff [ 7.785812] pcmcia: parent PCI bridge Memory window: 0xe0000000 - 0xe3ffffff [ 7.786199] ACPI: PCI Interrupt 0000:00:1b.0[B] -> GSI 17 (level, low) -> IRQ 21 [ 7.786450] PCI: Setting latency timer of device 0000:00:1b.0 to 64 [ 8.303763] usb 4-1: new full speed USB device using uhci_hcd and address 2 [ 8.465387] usb 4-1: configuration #1 chosen from 1 choice [ 8.550092] Bluetooth: Core ver 2.11 [ 8.550695] NET: Registered protocol family 31 [ 8.550795] Bluetooth: HCI device and connection manager initialized [ 8.550892] Bluetooth: HCI socket layer initialized [ 8.559175] Bluetooth: HCI USB driver ver 2.9 [ 8.677160] usb 4-2: new full speed USB device using uhci_hcd and address 3 [ 8.833905] hda_intel: No response from codec, disabling MSI... [ 8.842826] usb 4-2: configuration #1 chosen from 1 choice [ 8.847946] usbcore: registered new interface driver hci_usb [ 9.833318] hda_intel: azx_get_response timeout, switching to polling mode... [ 10.832730] hda_intel: azx_get_response timeout, switching to single_cmd mode... [ 21.618159] sdhci: SDHCI controller found at 0000:15:00.2 [1180:0822] (rev 18) [ 21.619154] ACPI: PCI Interrupt 0000:15:00.2[C] -> GSI 18 (level, low) -> IRQ 22 [ 21.620362] PCI: Setting latency timer of device 0000:15:00.2 to 64 [ 21.622574] mmc0: SDHCI at 0xe4301800 irq 22 DMA [ 22.346566] Adding 1951856k swap on /dev/sda12. Priority:-1 extents:1 across:1951856k [ 22.347780] Adding 2931820k swap on /dev/sda13. Priority:-2 extents:1 across:2931820k [ 22.692872] Non-volatile memory driver v1.2 [ 22.731265] ieee1394: sbp2: Driver forced to serialize I/O (serialize_io=1) [ 22.731365] ieee1394: sbp2: Try serialize_io=0 for better performance [ 22.764737] ibm_acpi: IBM ThinkPad ACPI Extras v0.12a [ 22.764844] ibm_acpi: http://ibm-acpi.sf.net/ [ 22.785014] ACPI (exconfig-0455): Dynamic SSDT Load - OemId [ PmRef] OemTableId [ Cpu0Ist] [20060707] [ 22.785828] ACPI (exconfig-0455): Dynamic SSDT Load - OemId [ PmRef] OemTableId [ Cpu0Cst] [20060707] [ 22.787166] ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3]) [ 22.787446] ACPI: Processor [CPU0] (supports 8 throttling states) [ 22.788615] ACPI (exconfig-0455): Dynamic SSDT Load - OemId [ PmRef] OemTableId [ Cpu1Ist] [20060707] [ 22.789318] ACPI (exconfig-0455): Dynamic SSDT Load - OemId [ PmRef] OemTableId [ Cpu1Cst] [20060707] [ 22.790705] ACPI: CPU1 (power states: C1[C1] C2[C2] C3[C3]) [ 22.790991] ACPI: Processor [CPU1] (supports 8 throttling states) [ 23.002000] Time: hpet clocksource has been installed. [ 23.019000] mmcblk0: mmc0:b368 SD 249856KiB [ 23.019000] mmcblk0: p1 [ 38.427000] ReiserFS: sda14: found reiserfs format "3.6" with standard journal [ 38.427000] ReiserFS: sda14: warning: CONFIG_REISERFS_CHECK is set ON [ 38.427000] ReiserFS: sda14: warning: - it is slow mode for debugging. [ 38.427000] ReiserFS: sda14: using ordered data mode [ 38.450000] ReiserFS: sda14: journal params: device sda14, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 [ 38.451000] ReiserFS: sda14: checking transaction log (sda14) [ 38.451000] ReiserFS: sda14: journal-1153: found in header: first_unflushed_offset 7418, last_flushed_trans_id 30277 [ 38.453000] ReiserFS: sda14: journal-1206: Starting replay from offset 130043019795706, trans_id 3223281428 [ 38.453000] ReiserFS: sda14: journal-1299: Setting newest_mount_id to 176 [ 38.495000] ReiserFS: sda14: Using r5 hash to sort names [ 38.558000] ReiserFS: sda8: found reiserfs format "3.6" with standard journal [ 38.558000] ReiserFS: sda8: warning: CONFIG_REISERFS_CHECK is set ON [ 38.558000] ReiserFS: sda8: warning: - it is slow mode for debugging. [ 38.558000] ReiserFS: sda8: using ordered data mode [ 38.565000] ReiserFS: sda8: journal params: device sda8, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 [ 38.566000] ReiserFS: sda8: checking transaction log (sda8) [ 38.566000] ReiserFS: sda8: journal-1153: found in header: first_unflushed_offset 6697, last_flushed_trans_id 571523 [ 38.574000] ReiserFS: sda8: journal-1206: Starting replay from offset 2454676888885801, trans_id 3223281428 [ 38.574000] ReiserFS: sda8: journal-1299: Setting newest_mount_id to 176 [ 38.617000] ReiserFS: sda8: Using r5 hash to sort names [ 38.687000] ReiserFS: sda11: found reiserfs format "3.6" with standard journal [ 38.688000] ReiserFS: sda11: warning: CONFIG_REISERFS_CHECK is set ON [ 38.688000] ReiserFS: sda11: warning: - it is slow mode for debugging. [ 38.688000] ReiserFS: sda11: using ordered data mode [ 38.715000] ReiserFS: sda11: journal params: device sda11, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 [ 38.716000] ReiserFS: sda11: checking transaction log (sda11) [ 38.716000] ReiserFS: sda11: journal-1153: found in header: first_unflushed_offset 5253, last_flushed_trans_id 20436 [ 38.749000] ReiserFS: sda11: journal-1206: Starting replay from offset 87776246633605, trans_id 3223281428 [ 38.749000] ReiserFS: sda11: journal-1299: Setting newest_mount_id to 176 [ 38.771000] ReiserFS: sda11: Using r5 hash to sort names [ 38.798000] ReiserFS: sda10: found reiserfs format "3.6" with standard journal [ 38.799000] ReiserFS: sda10: warning: CONFIG_REISERFS_CHECK is set ON [ 38.799000] ReiserFS: sda10: warning: - it is slow mode for debugging. [ 38.799000] ReiserFS: sda10: using ordered data mode [ 38.809000] ReiserFS: sda10: journal params: device sda10, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 [ 38.809000] ReiserFS: sda10: checking transaction log (sda10) [ 38.810000] ReiserFS: sda10: journal-1153: found in header: first_unflushed_offset 3806, last_flushed_trans_id 20392 [ 38.820000] ReiserFS: sda10: journal-1206: Starting replay from offset 87587268071134, trans_id 3223281428 [ 38.820000] ReiserFS: sda10: journal-1299: Setting newest_mount_id to 176 [ 38.831000] ReiserFS: sda10: Using r5 hash to sort names [ 38.848000] ReiserFS: sda9: found reiserfs format "3.6" with standard journal [ 38.848000] ReiserFS: sda9: warning: CONFIG_REISERFS_CHECK is set ON [ 38.848000] ReiserFS: sda9: warning: - it is slow mode for debugging. [ 38.849000] ReiserFS: sda9: using ordered data mode [ 38.855000] ReiserFS: sda9: journal params: device sda9, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 [ 38.856000] ReiserFS: sda9: checking transaction log (sda9) [ 38.856000] ReiserFS: sda9: journal-1153: found in header: first_unflushed_offset 6872, last_flushed_trans_id 96225 [ 38.859000] ReiserFS: sda9: journal-1206: Starting replay from offset 413287523031768, trans_id 4155609112 [ 38.859000] ReiserFS: sda9: journal-1299: Setting newest_mount_id to 176 [ 38.871000] ReiserFS: sda9: Using r5 hash to sort names [ 38.898000] ReiserFS: sda7: found reiserfs format "3.6" with standard journal [ 38.898000] ReiserFS: sda7: warning: CONFIG_REISERFS_CHECK is set ON [ 38.899000] ReiserFS: sda7: warning: - it is slow mode for debugging. [ 38.899000] ReiserFS: sda7: using ordered data mode [ 38.903000] ReiserFS: sda7: journal params: device sda7, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 [ 38.903000] ReiserFS: sda7: checking transaction log (sda7) [ 38.904000] ReiserFS: sda7: journal-1153: found in header: first_unflushed_offset 5590, last_flushed_trans_id 581233 [ 38.909000] ReiserFS: sda7: journal-1206: Starting replay from offset 2496381021328854, trans_id 24000000 [ 38.910000] ReiserFS: sda7: journal-1299: Setting newest_mount_id to 176 [ 38.953000] ReiserFS: sda7: Using r5 hash to sort names [ 39.014000] ReiserFS: sda6: found reiserfs format "3.6" with standard journal [ 39.015000] ReiserFS: sda6: warning: CONFIG_REISERFS_CHECK is set ON [ 39.015000] ReiserFS: sda6: warning: - it is slow mode for debugging. [ 39.015000] ReiserFS: sda6: using ordered data mode [ 39.052000] ReiserFS: sda6: journal params: device sda6, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 [ 39.052000] ReiserFS: sda6: checking transaction log (sda6) [ 39.052000] ReiserFS: sda6: journal-1153: found in header: first_unflushed_offset 2919, last_flushed_trans_id 787426 [ 39.078000] ReiserFS: sda6: journal-1206: Starting replay from offset 3381973212990311, trans_id 30000000 [ 39.078000] ReiserFS: sda6: journal-1299: Setting newest_mount_id to 176 [ 39.167000] ReiserFS: sda6: Using r5 hash to sort names [ 39.284000] kjournald starting. Commit interval 5 seconds [ 39.284000] EXT3 FS on mmcblk0p1, internal journal [ 39.284000] EXT3-fs: mounted filesystem with ordered data mode. [-- Attachment #3: dmesg.2.6.19-rc3-ts-tp-ie-e1-44.1+1430-g06df5d4f-dirty.run --] [-- Type: text/plain, Size: 31340 bytes --] IRQ0 used by override. [ 0.000000] ACPI: IRQ2 used by override. [ 0.000000] ACPI: IRQ9 used by override. [ 0.000000] Enabling APIC mode: Flat. Using 1 I/O APICs [ 0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000 [ 0.000000] Using ACPI (MADT) for SMP configuration information [ 0.000000] Allocating PCI resources starting at 88000000 (gap: 80000000:70000000) [ 0.000000] Detected 1662.624 MHz processor. [ 10.539368] Built 1 zonelists. Total pages: 517875 [ 10.539373] Kernel command line: root=/dev/sda5 ro resume [ 10.539720] mapped APIC to ffffd000 (fee00000) [ 10.539724] mapped IOAPIC to ffffc000 (fec00000) [ 10.539728] Enabling fast FPU save and restore... done. [ 10.539733] Enabling unmasked SIMD FPU exception support... done. [ 10.539737] Initializing CPU#0 [ 10.539818] PID hash table entries: 4096 (order: 12, 16384 bytes) [ 10.541567] Console: colour VGA+ 80x25 [ 10.545995] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [ 10.546589] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [ 10.688172] Memory: 2065788k/2087808k available (1949k kernel code, 20860k reserved, 775k data, 176k init, 1170304k highmem) [ 10.688330] virtual kernel memory layout: [ 10.688332] fixmap : 0xfff9d000 - 0xfffff000 ( 392 kB) [ 10.688334] pkmap : 0xff800000 - 0xffc00000 (4096 kB) [ 10.688336] vmalloc : 0xf8800000 - 0xff7fe000 ( 111 MB) [ 10.688339] lowmem : 0xc0000000 - 0xf8000000 ( 896 MB) [ 10.688341] .init : 0xc0400000 - 0xc042c000 ( 176 kB) [ 10.688343] .data : 0xc02e77a9 - 0xc03a9414 ( 775 kB) [ 10.688346] .text : 0xc0100000 - 0xc02e77a9 (1949 kB) [ 10.689084] Checking if this processor honours the WP bit even in supervisor mode... Ok. [ 10.689471] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0 [ 10.689749] hpet0: 3 64-bit timers, 14318180 Hz [ 10.690845] Using HPET for base-timer [ 10.750381] Calibrating delay using timer specific routine.. 3328.29 BogoMIPS (lpj=1664148) [ 10.750612] Security Framework v1.0.0 initialized [ 10.750710] Capability LSM initialized [ 10.750819] Mount-cache hash table entries: 512 [ 10.751046] CPU: After generic identify, caps: bfe9fbff 00100000 00000000 00000000 0000c1a9 00000000 00000000 [ 10.751058] monitor/mwait feature present. [ 10.751150] using mwait in idle threads. [ 10.751243] CPU: L1 I cache: 32K, L1 D cache: 32K [ 10.751392] CPU: L2 cache: 2048K [ 10.751481] CPU: Physical Processor ID: 0 [ 10.751571] CPU: Processor Core ID: 0 [ 10.751661] CPU: After all inits, caps: bfe9fbff 00100000 00000000 00000940 0000c1a9 00000000 00000000 [ 10.751672] Intel machine check architecture supported. [ 10.751771] Intel machine check reporting enabled on CPU#0. [ 10.751869] Compat vDSO mapped to ffffe000. [ 10.751972] Checking 'hlt' instruction... OK. [ 10.755540] SMP alternatives: switching to UP code [ 10.755838] ACPI: Core revision 20060707 [ 10.779647] CPU0: Intel Genuine Intel(R) CPU L2400 @ 1.66GHz stepping 08 [ 10.779925] SMP alternatives: switching to SMP code [ 10.780081] Booting processor 1/1 eip 3000 [ 10.791299] Initializing CPU#1 [ 10.851566] Calibrating delay using timer specific routine.. 3325.08 BogoMIPS (lpj=1662541) [ 10.851575] CPU: After generic identify, caps: bfe9fbff 00100000 00000000 00000000 0000c1a9 00000000 00000000 [ 10.851584] monitor/mwait feature present. [ 10.851589] CPU: L1 I cache: 32K, L1 D cache: 32K [ 10.851593] CPU: L2 cache: 2048K [ 10.851596] CPU: Physical Processor ID: 0 [ 10.851599] CPU: Processor Core ID: 1 [ 10.851601] CPU: After all inits, caps: bfe9fbff 00100000 00000000 00000940 0000c1a9 00000000 00000000 [ 10.851610] Intel machine check architecture supported. [ 10.851619] Intel machine check reporting enabled on CPU#1. [ 10.851890] CPU1: Intel Genuine Intel(R) CPU L2400 @ 1.66GHz stepping 08 [ 10.853013] Total of 2 processors activated (6653.37 BogoMIPS). [ 10.853317] ENABLING IO-APIC IRQs [ 10.853624] ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 [ 10.965046] checking TSC synchronization across 2 CPUs: [ 0.000086] CPU#0 had -172 usecs TSC skew, fixed it up. [ 0.000181] CPU#1 had 172 usecs TSC skew, fixed it up. [ 0.000949] Brought up 2 CPUs [ 0.307634] migration_cost=117 [ 0.308430] NET: Registered protocol family 16 [ 0.308637] ACPI: bus type pci registered [ 0.308735] PCI: Using MMCONFIG [ 0.309658] Setting up standard PCI resources [ 0.328979] ACPI: Interpreter enabled [ 0.329072] ACPI: Using IOAPIC for interrupt routing [ 0.330596] ACPI: PCI Interrupt Link [LNKA] (IRQs *3 4 5 6 7 9 10 11) [ 0.332204] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 *4 5 6 7 9 10 11) [ 0.333820] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 9 10 11) [ 0.335446] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 *6 7 9 10 11) [ 0.337062] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 *11) [ 0.338682] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 *11) [ 0.340286] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 *10 11) [ 0.341902] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 *11) [ 0.343116] ACPI: PCI Root Bridge [PCI0] (0000:00) [ 0.343214] PCI: Probing PCI hardware (bus 00) [ 0.348387] Boot video device is 0000:00:02.0 [ 0.348988] PCI quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO [ 0.349086] PCI quirk: region 1180-11bf claimed by ICH6 GPIO [ 0.349227] PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1 [ 0.350564] PCI: Transparent bridge - 0000:00:1e.0 [ 0.350806] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] [ 0.358912] ACPI: Power Resource [PUBS] (on) [ 0.361453] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP0._PRT] [ 0.361772] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP1._PRT] [ 0.362089] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP2._PRT] [ 0.362477] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP3._PRT] [ 0.362853] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT] [ 0.365662] Linux Plug and Play Support v0.97 (c) Adam Belay [ 0.365766] pnp: PnP ACPI init [ 0.372613] pnp: PnP ACPI: found 12 devices [ 0.372737] intel_rng: FWH not detected [ 0.373008] SCSI subsystem initialized [ 0.373188] PCI: Using ACPI for IRQ routing [ 0.373280] PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report [ 0.374947] PCI: Ignore bogus resource 6 [0:0] of 0000:00:02.0 [ 0.375046] PCI: Bridge: 0000:00:1c.0 [ 0.375138] IO window: 2000-2fff [ 0.375231] MEM window: ee000000-ee0fffff [ 0.375323] PREFETCH window: disabled. [ 0.375425] PCI: Bridge: 0000:00:1c.1 [ 0.375516] IO window: 3000-4fff [ 0.375609] MEM window: ec000000-edffffff [ 0.375702] PREFETCH window: e4000000-e40fffff [ 0.375798] PCI: Bridge: 0000:00:1c.2 [ 0.375891] IO window: 5000-6fff [ 0.375985] MEM window: e8000000-e9ffffff [ 0.376080] PREFETCH window: e4100000-e41fffff [ 0.376175] PCI: Bridge: 0000:00:1c.3 [ 0.376267] IO window: 7000-8fff [ 0.376370] MEM window: ea000000-ebffffff [ 0.376465] PREFETCH window: e4200000-e42fffff [ 0.376567] PCI: Bus 22, cardbus bridge: 0000:15:00.0 [ 0.376661] IO window: 00009000-000090ff [ 0.376756] IO window: 00009400-000094ff [ 0.376852] PREFETCH window: e0000000-e1ffffff [ 0.376948] MEM window: e6000000-e7ffffff [ 0.377042] PCI: Bridge: 0000:00:1e.0 [ 0.377135] IO window: 9000-cfff [ 0.377229] MEM window: e4300000-e7ffffff [ 0.377324] PREFETCH window: e0000000-e3ffffff [ 0.377449] ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 20 (level, low) -> IRQ 16 [ 0.377635] PCI: Setting latency timer of device 0000:00:1c.0 to 64 [ 0.377658] ACPI: PCI Interrupt 0000:00:1c.1[B] -> GSI 21 (level, low) -> IRQ 17 [ 0.377843] PCI: Setting latency timer of device 0000:00:1c.1 to 64 [ 0.377866] ACPI: PCI Interrupt 0000:00:1c.2[C] -> GSI 22 (level, low) -> IRQ 18 [ 0.378050] PCI: Setting latency timer of device 0000:00:1c.2 to 64 [ 0.378072] ACPI: PCI Interrupt 0000:00:1c.3[D] -> GSI 23 (level, low) -> IRQ 19 [ 0.378257] PCI: Setting latency timer of device 0000:00:1c.3 to 64 [ 0.378268] PCI: Enabling device 0000:00:1e.0 (0005 -> 0007) [ 0.378374] PCI: Setting latency timer of device 0000:00:1e.0 to 64 [ 0.378393] ACPI: PCI Interrupt 0000:15:00.0[A] -> GSI 16 (level, low) -> IRQ 20 [ 0.378579] PCI: Setting latency timer of device 0000:15:00.0 to 64 [ 0.378614] NET: Registered protocol family 2 [ 0.391378] IP route cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.391621] TCP established hash table entries: 262144 (order: 9, 2097152 bytes) [ 0.394548] TCP bind hash table entries: 65536 (order: 7, 524288 bytes) [ 0.395357] TCP: Hash tables configured (established 262144 bind 65536) [ 0.395453] TCP reno registered [ 0.395768] Simple Boot Flag at 0x35 set to 0x1 [ 0.396509] audit: initializing netlink socket (disabled) [ 0.396620] audit(1162223349.853:1): initialized [ 0.396812] highmem bounce pool size: 64 pages [ 0.397170] io scheduler noop registered [ 0.397313] io scheduler anticipatory registered [ 0.397454] io scheduler deadline registered [ 0.397607] io scheduler cfq registered (default) [ 0.398102] PCI: Setting latency timer of device 0000:00:1c.0 to 64 [ 0.398156] assign_interrupt_mode Found MSI capability [ 0.398309] Allocate Port Service[0000:00:1c.0:pcie00] [ 0.398370] Allocate Port Service[0000:00:1c.0:pcie02] [ 0.398428] Allocate Port Service[0000:00:1c.0:pcie03] [ 0.398548] PCI: Setting latency timer of device 0000:00:1c.1 to 64 [ 0.398601] assign_interrupt_mode Found MSI capability [ 0.399564] Allocate Port Service[0000:00:1c.1:pcie00] [ 0.399614] Allocate Port Service[0000:00:1c.1:pcie02] [ 0.399661] Allocate Port Service[0000:00:1c.1:pcie03] [ 0.399775] PCI: Setting latency timer of device 0000:00:1c.2 to 64 [ 0.399828] assign_interrupt_mode Found MSI capability [ 0.399962] Allocate Port Service[0000:00:1c.2:pcie00] [ 0.400009] Allocate Port Service[0000:00:1c.2:pcie02] [ 0.400061] Allocate Port Service[0000:00:1c.2:pcie03] [ 0.400175] PCI: Setting latency timer of device 0000:00:1c.3 to 64 [ 0.400228] assign_interrupt_mode Found MSI capability [ 0.400368] Allocate Port Service[0000:00:1c.3:pcie00] [ 0.400418] Allocate Port Service[0000:00:1c.3:pcie02] [ 0.400465] Allocate Port Service[0000:00:1c.3:pcie03] [ 0.433651] Real Time Clock Driver v1.12ac [ 0.433809] hpet_resources: 0xfed00000 is busy [ 0.433837] Linux agpgart interface v0.101 (c) Dave Jones [ 0.433975] agpgart: Detected an Intel 945GM Chipset. [ 0.435945] agpgart: Detected 7932K stolen memory. [ 0.453538] agpgart: AGP aperture is 256M @ 0xd0000000 [ 0.453679] [drm] Initialized drm 1.0.1 20051102 [ 0.454166] loop: loaded (max 8 devices) [ 0.454264] Intel(R) PRO/1000 Network Driver - version 7.2.9-k2-NAPI [ 0.454358] Copyright (c) 1999-2006 Intel Corporation. [ 0.454526] ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 20 [ 0.454719] PCI: Setting latency timer of device 0000:02:00.0 to 64 [ 0.460267] e1000: 0000:02:00.0: e1000_probe: (PCI Express:2.5Gb/s:32-bit) 00:16:d3:22:9b:82 [ 0.505134] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection [ 0.505373] netconsole: not configured, aborting [ 0.505579] libata version 2.00 loaded. [ 0.505629] ahci 0000:00:1f.2: version 2.0 [ 0.505647] ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 16 (level, low) -> IRQ 20 [ 1.507573] PCI: Setting latency timer of device 0000:00:1f.2 to 64 [ 1.507583] ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 4 ports 1.5 Gbps 0x1 impl SATA mode [ 1.507722] ahci 0000:00:1f.2: flags: 64bit ncq pm led clo pio slum part [ 1.507910] ata1: SATA max UDMA/133 cmd 0xF8824500 ctl 0x0 bmdma 0x0 irq 219 [ 1.508079] ata2: SATA max UDMA/133 cmd 0xF8824580 ctl 0x0 bmdma 0x0 irq 219 [ 1.508251] ata3: SATA max UDMA/133 cmd 0xF8824600 ctl 0x0 bmdma 0x0 irq 219 [ 1.508419] ata4: SATA max UDMA/133 cmd 0xF8824680 ctl 0x0 bmdma 0x0 irq 219 [ 1.508524] scsi0 : ahci [ 1.966832] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 1.967289] ata1.00: ATA-7, max UDMA/100, 156301488 sectors: LBA48 NCQ (depth 31/32) [ 1.967424] ata1.00: ata1: dev 0 multi count 16 [ 1.969850] ata1.00: configured for UDMA/100 [ 1.969952] scsi1 : ahci [ 2.273333] ata2: SATA link down (SStatus 0 SControl 0) [ 2.273440] scsi2 : ahci [ 2.576850] ata3: SATA link down (SStatus 0 SControl 0) [ 2.576953] scsi3 : ahci [ 2.880368] ata4: SATA link down (SStatus 0 SControl 0) [ 2.880597] scsi 0:0:0:0: Direct-Access ATA FUJITSU MHV2080B 0084 PQ: 0 ANSI: 5 [ 2.880870] SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) [ 2.880982] sda: Write Protect is off [ 2.881073] sda: Mode Sense: 00 3a 00 00 [ 2.881099] SCSI device sda: drive cache: write back [ 2.881251] SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) [ 2.881362] sda: Write Protect is off [ 2.881453] sda: Mode Sense: 00 3a 00 00 [ 2.881478] SCSI device sda: drive cache: write back [ 2.881575] sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 sda9 sda10 sda11 sda12 sda13 sda14 > [ 3.052953] sd 0:0:0:0: Attached scsi disk sda [ 3.053295] PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12 [ 3.064269] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 3.064367] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 3.064626] mice: PS/2 mouse device common for all mice [ 3.064722] i2c /dev entries driver [ 3.064957] ACPI: PCI Interrupt 0000:00:1f.3[A] -> GSI 23 (level, low) -> IRQ 19 [ 3.065268] hdaps: LENOVO ThinkPad X60 detected, inverting axes [ 3.069987] input: AT Translated Set 2 keyboard as /class/input/input0 [ 3.076297] hdaps: initial mode latch is 0x05 [ 3.076468] hdaps: setting ec_rate=250, filter_order=2 [ 3.076509] hdaps: fake_data_mode set to 0 [ 3.076732] hdaps: device successfully initialized. [ 3.076906] input: hdaps as /class/input/input1 [ 3.076999] hdaps: driver successfully loaded. [ 3.077093] EDAC MC: Ver: 2.0.1 Oct 30 2006 [ 3.077714] thinkpad_ec: thinkpad_ec 0.30 loaded. [ 3.077956] TCP bic registered [ 3.078057] NET: Registered protocol family 1 [ 3.078153] NET: Registered protocol family 17 [ 3.078263] Starting balanced_irq [ 3.078359] Using IPI No-Shortcut mode [ 3.078884] ACPI: (supports S0 S3 S4 S5) [ 3.079246] Time: tsc clocksource has been installed. [ 3.079386] BIOS EDD facility v0.16 2004-Jun-25, 1 devices found [ 3.082224] VFS: Mounted root (ext2 filesystem) readonly. [ 3.082457] Freeing unused kernel memory: 176k freed [ 6.179063] ieee1394: Initialized config rom entry `ip1394' [ 6.181760] ACPI: PCI Interrupt 0000:15:00.1[B] -> GSI 17 (level, low) -> IRQ 21 [ 6.181958] PCI: Setting latency timer of device 0000:15:00.1 to 64 [ 6.235209] ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[21] MMIO=[e4301000-e43017ff] Max Packet=[2048] IR/IT contexts=[4/4] [ 6.349287] input: PC Speaker as /class/input/input2 [ 6.712159] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 [ 6.712263] ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx [ 6.908445] usbcore: registered new interface driver usbfs [ 6.908579] usbcore: registered new interface driver hub [ 6.908711] usbcore: registered new device driver usb [ 7.089196] irda_init() [ 7.089213] NET: Registered protocol family 23 [ 7.146382] USB Universal Host Controller Interface driver v3.0 [ 7.146545] ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 20 [ 7.146745] PCI: Setting latency timer of device 0000:00:1d.0 to 64 [ 7.146751] uhci_hcd 0000:00:1d.0: UHCI Host Controller [ 7.147058] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1 [ 7.147234] uhci_hcd 0000:00:1d.0: irq 20, io base 0x00001820 [ 7.147488] usb usb1: configuration #1 chosen from 1 choice [ 7.147628] hub 1-0:1.0: USB hub found [ 7.147726] hub 1-0:1.0: 2 ports detected [ 7.198161] sdhci: Secure Digital Host Controller Interface driver, 0.12 [ 7.198263] sdhci: Copyright(c) Pierre Ossman [ 7.248594] ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 17 (level, low) -> IRQ 21 [ 7.248798] PCI: Setting latency timer of device 0000:00:1d.1 to 64 [ 7.248804] uhci_hcd 0000:00:1d.1: UHCI Host Controller [ 7.248942] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 2 [ 7.249108] uhci_hcd 0000:00:1d.1: irq 21, io base 0x00001840 [ 7.249338] usb usb2: configuration #1 chosen from 1 choice [ 7.249818] hub 2-0:1.0: USB hub found [ 7.249917] hub 2-0:1.0: 2 ports detected [ 7.351432] ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 22 [ 7.351634] PCI: Setting latency timer of device 0000:00:1d.2 to 64 [ 7.351640] uhci_hcd 0000:00:1d.2: UHCI Host Controller [ 7.351771] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 3 [ 7.351940] uhci_hcd 0000:00:1d.2: irq 22, io base 0x00001860 [ 7.352165] usb usb3: configuration #1 chosen from 1 choice [ 7.352305] hub 3-0:1.0: USB hub found [ 7.352401] hub 3-0:1.0: 2 ports detected [ 7.453217] ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 19 (level, low) -> IRQ 23 [ 7.453403] PCI: Setting latency timer of device 0000:00:1d.3 to 64 [ 7.453408] uhci_hcd 0000:00:1d.3: UHCI Host Controller [ 7.453537] uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 4 [ 7.453701] uhci_hcd 0000:00:1d.3: irq 23, io base 0x00001880 [ 7.453921] usb usb4: configuration #1 chosen from 1 choice [ 7.454051] hub 4-0:1.0: USB hub found [ 7.454150] hub 4-0:1.0: 2 ports detected [ 7.499170] ieee1394: Host added: ID:BUS[0-00:1023] GUID[000ae40600192017] [ 7.555770] ACPI: PCI Interrupt 0000:00:1d.7[D] -> GSI 19 (level, low) -> IRQ 23 [ 7.555969] PCI: Setting latency timer of device 0000:00:1d.7 to 64 [ 7.555975] ehci_hcd 0000:00:1d.7: EHCI Host Controller [ 7.556109] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 5 [ 7.556283] ehci_hcd 0000:00:1d.7: debug port 1 [ 7.556384] PCI: cache line size of 32 is not supported by device 0000:00:1d.7 [ 7.556395] ehci_hcd 0000:00:1d.7: irq 23, io mem 0xee444000 [ 7.560381] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 [ 7.560837] usb usb5: configuration #1 chosen from 1 choice [ 7.560967] hub 5-0:1.0: USB hub found [ 7.561064] hub 5-0:1.0: 8 ports detected [ 7.563438] eth1394: eth1: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0) [ 7.637032] IBM TrackPoint firmware: 0x0e, buttons: 3/3 [ 7.657935] input: TPPS/2 IBM TrackPoint as /class/input/input3 [ 7.661955] Yenta: CardBus bridge found at 0000:15:00.0 [17aa:201c] [ 7.663374] pnp: Device 00:0a activated. [ 7.663471] nsc_ircc_pnp_probe() : From PnP, found firbase 0x2F8 ; irq 7 ; dma 1. [ 7.663500] nsc-ircc, chip->init [ 7.663605] nsc-ircc, Found chip at base=0x164e [ 7.663738] nsc-ircc, driver loaded (Dag Brattli) [ 7.663925] IrDA: Registered device irda0 [ 7.664080] nsc-ircc, Found dongle: No dongle connected [ 7.664183] nsc_ircc_init_dongle_interface(), No dongle connected [ 7.785417] Yenta: ISA IRQ mask 0x0c38, PCI irq 20 [ 7.785519] Socket status: 30000006 [ 7.785615] pcmcia: parent PCI bridge I/O window: 0x9000 - 0xcfff [ 7.785713] pcmcia: parent PCI bridge Memory window: 0xe4300000 - 0xe7ffffff [ 7.785812] pcmcia: parent PCI bridge Memory window: 0xe0000000 - 0xe3ffffff [ 7.786199] ACPI: PCI Interrupt 0000:00:1b.0[B] -> GSI 17 (level, low) -> IRQ 21 [ 7.786450] PCI: Setting latency timer of device 0000:00:1b.0 to 64 [ 8.303763] usb 4-1: new full speed USB device using uhci_hcd and address 2 [ 8.465387] usb 4-1: configuration #1 chosen from 1 choice [ 8.550092] Bluetooth: Core ver 2.11 [ 8.550695] NET: Registered protocol family 31 [ 8.550795] Bluetooth: HCI device and connection manager initialized [ 8.550892] Bluetooth: HCI socket layer initialized [ 8.559175] Bluetooth: HCI USB driver ver 2.9 [ 8.677160] usb 4-2: new full speed USB device using uhci_hcd and address 3 [ 8.833905] hda_intel: No response from codec, disabling MSI... [ 8.842826] usb 4-2: configuration #1 chosen from 1 choice [ 8.847946] usbcore: registered new interface driver hci_usb [ 9.833318] hda_intel: azx_get_response timeout, switching to polling mode... [ 10.832730] hda_intel: azx_get_response timeout, switching to single_cmd mode... [ 21.618159] sdhci: SDHCI controller found at 0000:15:00.2 [1180:0822] (rev 18) [ 21.619154] ACPI: PCI Interrupt 0000:15:00.2[C] -> GSI 18 (level, low) -> IRQ 22 [ 21.620362] PCI: Setting latency timer of device 0000:15:00.2 to 64 [ 21.622574] mmc0: SDHCI at 0xe4301800 irq 22 DMA [ 22.346566] Adding 1951856k swap on /dev/sda12. Priority:-1 extents:1 across:1951856k [ 22.347780] Adding 2931820k swap on /dev/sda13. Priority:-2 extents:1 across:2931820k [ 22.692872] Non-volatile memory driver v1.2 [ 22.731265] ieee1394: sbp2: Driver forced to serialize I/O (serialize_io=1) [ 22.731365] ieee1394: sbp2: Try serialize_io=0 for better performance [ 22.764737] ibm_acpi: IBM ThinkPad ACPI Extras v0.12a [ 22.764844] ibm_acpi: http://ibm-acpi.sf.net/ [ 22.785014] ACPI (exconfig-0455): Dynamic SSDT Load - OemId [ PmRef] OemTableId [ Cpu0Ist] [20060707] [ 22.785828] ACPI (exconfig-0455): Dynamic SSDT Load - OemId [ PmRef] OemTableId [ Cpu0Cst] [20060707] [ 22.787166] ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3]) [ 22.787446] ACPI: Processor [CPU0] (supports 8 throttling states) [ 22.788615] ACPI (exconfig-0455): Dynamic SSDT Load - OemId [ PmRef] OemTableId [ Cpu1Ist] [20060707] [ 22.789318] ACPI (exconfig-0455): Dynamic SSDT Load - OemId [ PmRef] OemTableId [ Cpu1Cst] [20060707] [ 22.790705] ACPI: CPU1 (power states: C1[C1] C2[C2] C3[C3]) [ 22.790991] ACPI: Processor [CPU1] (supports 8 throttling states) [ 23.002000] Time: hpet clocksource has been installed. [ 23.019000] mmcblk0: mmc0:b368 SD 249856KiB [ 23.019000] mmcblk0: p1 [ 38.427000] ReiserFS: sda14: found reiserfs format "3.6" with standard journal [ 38.427000] ReiserFS: sda14: warning: CONFIG_REISERFS_CHECK is set ON [ 38.427000] ReiserFS: sda14: warning: - it is slow mode for debugging. [ 38.427000] ReiserFS: sda14: using ordered data mode [ 38.450000] ReiserFS: sda14: journal params: device sda14, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 [ 38.451000] ReiserFS: sda14: checking transaction log (sda14) [ 38.451000] ReiserFS: sda14: journal-1153: found in header: first_unflushed_offset 7418, last_flushed_trans_id 30277 [ 38.453000] ReiserFS: sda14: journal-1206: Starting replay from offset 130043019795706, trans_id 3223281428 [ 38.453000] ReiserFS: sda14: journal-1299: Setting newest_mount_id to 176 [ 38.495000] ReiserFS: sda14: Using r5 hash to sort names [ 38.558000] ReiserFS: sda8: found reiserfs format "3.6" with standard journal [ 38.558000] ReiserFS: sda8: warning: CONFIG_REISERFS_CHECK is set ON [ 38.558000] ReiserFS: sda8: warning: - it is slow mode for debugging. [ 38.558000] ReiserFS: sda8: using ordered data mode [ 38.565000] ReiserFS: sda8: journal params: device sda8, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 [ 38.566000] ReiserFS: sda8: checking transaction log (sda8) [ 38.566000] ReiserFS: sda8: journal-1153: found in header: first_unflushed_offset 6697, last_flushed_trans_id 571523 [ 38.574000] ReiserFS: sda8: journal-1206: Starting replay from offset 2454676888885801, trans_id 3223281428 [ 38.574000] ReiserFS: sda8: journal-1299: Setting newest_mount_id to 176 [ 38.617000] ReiserFS: sda8: Using r5 hash to sort names [ 38.687000] ReiserFS: sda11: found reiserfs format "3.6" with standard journal [ 38.688000] ReiserFS: sda11: warning: CONFIG_REISERFS_CHECK is set ON [ 38.688000] ReiserFS: sda11: warning: - it is slow mode for debugging. [ 38.688000] ReiserFS: sda11: using ordered data mode [ 38.715000] ReiserFS: sda11: journal params: device sda11, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 [ 38.716000] ReiserFS: sda11: checking transaction log (sda11) [ 38.716000] ReiserFS: sda11: journal-1153: found in header: first_unflushed_offset 5253, last_flushed_trans_id 20436 [ 38.749000] ReiserFS: sda11: journal-1206: Starting replay from offset 87776246633605, trans_id 3223281428 [ 38.749000] ReiserFS: sda11: journal-1299: Setting newest_mount_id to 176 [ 38.771000] ReiserFS: sda11: Using r5 hash to sort names [ 38.798000] ReiserFS: sda10: found reiserfs format "3.6" with standard journal [ 38.799000] ReiserFS: sda10: warning: CONFIG_REISERFS_CHECK is set ON [ 38.799000] ReiserFS: sda10: warning: - it is slow mode for debugging. [ 38.799000] ReiserFS: sda10: using ordered data mode [ 38.809000] ReiserFS: sda10: journal params: device sda10, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 [ 38.809000] ReiserFS: sda10: checking transaction log (sda10) [ 38.810000] ReiserFS: sda10: journal-1153: found in header: first_unflushed_offset 3806, last_flushed_trans_id 20392 [ 38.820000] ReiserFS: sda10: journal-1206: Starting replay from offset 87587268071134, trans_id 3223281428 [ 38.820000] ReiserFS: sda10: journal-1299: Setting newest_mount_id to 176 [ 38.831000] ReiserFS: sda10: Using r5 hash to sort names [ 38.848000] ReiserFS: sda9: found reiserfs format "3.6" with standard journal [ 38.848000] ReiserFS: sda9: warning: CONFIG_REISERFS_CHECK is set ON [ 38.848000] ReiserFS: sda9: warning: - it is slow mode for debugging. [ 38.849000] ReiserFS: sda9: using ordered data mode [ 38.855000] ReiserFS: sda9: journal params: device sda9, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 [ 38.856000] ReiserFS: sda9: checking transaction log (sda9) [ 38.856000] ReiserFS: sda9: journal-1153: found in header: first_unflushed_offset 6872, last_flushed_trans_id 96225 [ 38.859000] ReiserFS: sda9: journal-1206: Starting replay from offset 413287523031768, trans_id 4155609112 [ 38.859000] ReiserFS: sda9: journal-1299: Setting newest_mount_id to 176 [ 38.871000] ReiserFS: sda9: Using r5 hash to sort names [ 38.898000] ReiserFS: sda7: found reiserfs format "3.6" with standard journal [ 38.898000] ReiserFS: sda7: warning: CONFIG_REISERFS_CHECK is set ON [ 38.899000] ReiserFS: sda7: warning: - it is slow mode for debugging. [ 38.899000] ReiserFS: sda7: using ordered data mode [ 38.903000] ReiserFS: sda7: journal params: device sda7, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 [ 38.903000] ReiserFS: sda7: checking transaction log (sda7) [ 38.904000] ReiserFS: sda7: journal-1153: found in header: first_unflushed_offset 5590, last_flushed_trans_id 581233 [ 38.909000] ReiserFS: sda7: journal-1206: Starting replay from offset 2496381021328854, trans_id 24000000 [ 38.910000] ReiserFS: sda7: journal-1299: Setting newest_mount_id to 176 [ 38.953000] ReiserFS: sda7: Using r5 hash to sort names [ 39.014000] ReiserFS: sda6: found reiserfs format "3.6" with standard journal [ 39.015000] ReiserFS: sda6: warning: CONFIG_REISERFS_CHECK is set ON [ 39.015000] ReiserFS: sda6: warning: - it is slow mode for debugging. [ 39.015000] ReiserFS: sda6: using ordered data mode [ 39.052000] ReiserFS: sda6: journal params: device sda6, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 [ 39.052000] ReiserFS: sda6: checking transaction log (sda6) [ 39.052000] ReiserFS: sda6: journal-1153: found in header: first_unflushed_offset 2919, last_flushed_trans_id 787426 [ 39.078000] ReiserFS: sda6: journal-1206: Starting replay from offset 3381973212990311, trans_id 30000000 [ 39.078000] ReiserFS: sda6: journal-1299: Setting newest_mount_id to 176 [ 39.167000] ReiserFS: sda6: Using r5 hash to sort names [ 39.284000] kjournald starting. Commit interval 5 seconds [ 39.284000] EXT3 FS on mmcblk0p1, internal journal [ 39.284000] EXT3-fs: mounted filesystem with ordered data mode. [ 51.071000] ACPI: AC Adapter [AC] (off-line) [ 51.096000] ACPI: Battery Slot [BAT0] (battery present) [ 51.111000] ACPI: Power Button (FF) [PWRF] [ 51.111000] ACPI: Lid Switch [LID] [ 51.111000] ACPI: Sleep Button (CM) [SLPB] [ 51.127000] ACPI: ACPI Dock Station Driver [ 51.177000] ACPI: Thermal Zone [THM0] (46 C) [ 51.179000] ACPI: Thermal Zone [THM1] (47 C) [ 51.194000] ACPI: Video Device [VID] (multi-head: yes rom: no post: no) [ 51.195000] ACPI: Video Device [VID] (multi-head: yes rom: no post: no) [ 64.840000] ACPI: PCI interrupt for device 0000:00:1b.0 disabled [ 65.195000] PCI: Enabling device 0000:00:1b.0 (0100 -> 0102) [ 65.195000] ACPI: PCI Interrupt 0000:00:1b.0[B] -> GSI 17 (level, low) -> IRQ 21 [ 65.198000] PCI: Setting latency timer of device 0000:00:1b.0 to 64 [ 66.484000] hda_intel: No response from codec, disabling MSI... [ 67.485000] hda_intel: azx_get_response timeout, switching to polling mode... [ 71.911000] ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 20 [ 71.912000] [drm] Initialized i915 1.5.0 20060119 on minor 0 [ 155.470000] e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex [ 155.470000] e1000: eth0: e1000_watchdog: 10/100 speed: disabling TSO [ 155.914000] ACPI: docking [ 156.289000] usb 5-6: new high speed USB device using ehci_hcd and address 4 [ 156.403000] usb 5-6: configuration #1 chosen from 1 choice [ 156.403000] hub 5-6:1.0: USB hub found [ 156.403000] hub 5-6:1.0: 4 ports detected [ 156.682000] usb 5-6.1: new low speed USB device using ehci_hcd and address 5 [ 156.773000] usb 5-6.1: configuration #1 chosen from 1 choice [ 156.951000] usb 5-6.3: new low speed USB device using ehci_hcd and address 6 [ 157.057000] usb 5-6.3: configuration #1 chosen from 1 choice [ 157.202000] usbcore: registered new interface driver hiddev [ 157.204000] input: Logitech USB-PS/2 Optical Mouse as /class/input/input4 [ 157.205000] input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-0000:00:1d.7-6.1 [ 157.212000] input: Microsoft Comfort Curve Keyboard 2000 as /class/input/input5 [ 157.212000] input: USB HID v1.11 Keyboard [Microsoft Comfort Curve Keyboard 2000] on usb-0000:00:1d.7-6.3 [ 157.223000] input: Microsoft Comfort Curve Keyboard 2000 as /class/input/input6 [ 157.223000] input: USB HID v1.11 Device [Microsoft Comfort Curve Keyboard 2000] on usb-0000:00:1d.7-6.3 [ 157.223000] usbcore: registered new interface driver usbhid [ 157.223000] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [-- Attachment #4: dmesg.2.6.19-rc3-ts-tp-ie-e1-44.1+1430-g06df5d4f-dirty.run2 --] [-- Type: text/plain, Size: 31421 bytes --] ded (max 8 devices) [ 0.454264] Intel(R) PRO/1000 Network Driver - version 7.2.9-k2-NAPI [ 0.454358] Copyright (c) 1999-2006 Intel Corporation. [ 0.454526] ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 20 [ 0.454719] PCI: Setting latency timer of device 0000:02:00.0 to 64 [ 0.460267] e1000: 0000:02:00.0: e1000_probe: (PCI Express:2.5Gb/s:32-bit) 00:16:d3:22:9b:82 [ 0.505134] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection [ 0.505373] netconsole: not configured, aborting [ 0.505579] libata version 2.00 loaded. [ 0.505629] ahci 0000:00:1f.2: version 2.0 [ 0.505647] ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 16 (level, low) -> IRQ 20 [ 1.507573] PCI: Setting latency timer of device 0000:00:1f.2 to 64 [ 1.507583] ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 4 ports 1.5 Gbps 0x1 impl SATA mode [ 1.507722] ahci 0000:00:1f.2: flags: 64bit ncq pm led clo pio slum part [ 1.507910] ata1: SATA max UDMA/133 cmd 0xF8824500 ctl 0x0 bmdma 0x0 irq 219 [ 1.508079] ata2: SATA max UDMA/133 cmd 0xF8824580 ctl 0x0 bmdma 0x0 irq 219 [ 1.508251] ata3: SATA max UDMA/133 cmd 0xF8824600 ctl 0x0 bmdma 0x0 irq 219 [ 1.508419] ata4: SATA max UDMA/133 cmd 0xF8824680 ctl 0x0 bmdma 0x0 irq 219 [ 1.508524] scsi0 : ahci [ 1.966832] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 1.967289] ata1.00: ATA-7, max UDMA/100, 156301488 sectors: LBA48 NCQ (depth 31/32) [ 1.967424] ata1.00: ata1: dev 0 multi count 16 [ 1.969850] ata1.00: configured for UDMA/100 [ 1.969952] scsi1 : ahci [ 2.273333] ata2: SATA link down (SStatus 0 SControl 0) [ 2.273440] scsi2 : ahci [ 2.576850] ata3: SATA link down (SStatus 0 SControl 0) [ 2.576953] scsi3 : ahci [ 2.880368] ata4: SATA link down (SStatus 0 SControl 0) [ 2.880597] scsi 0:0:0:0: Direct-Access ATA FUJITSU MHV2080B 0084 PQ: 0 ANSI: 5 [ 2.880870] SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) [ 2.880982] sda: Write Protect is off [ 2.881073] sda: Mode Sense: 00 3a 00 00 [ 2.881099] SCSI device sda: drive cache: write back [ 2.881251] SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) [ 2.881362] sda: Write Protect is off [ 2.881453] sda: Mode Sense: 00 3a 00 00 [ 2.881478] SCSI device sda: drive cache: write back [ 2.881575] sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 sda9 sda10 sda11 sda12 sda13 sda14 > [ 3.052953] sd 0:0:0:0: Attached scsi disk sda [ 3.053295] PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12 [ 3.064269] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 3.064367] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 3.064626] mice: PS/2 mouse device common for all mice [ 3.064722] i2c /dev entries driver [ 3.064957] ACPI: PCI Interrupt 0000:00:1f.3[A] -> GSI 23 (level, low) -> IRQ 19 [ 3.065268] hdaps: LENOVO ThinkPad X60 detected, inverting axes [ 3.069987] input: AT Translated Set 2 keyboard as /class/input/input0 [ 3.076297] hdaps: initial mode latch is 0x05 [ 3.076468] hdaps: setting ec_rate=250, filter_order=2 [ 3.076509] hdaps: fake_data_mode set to 0 [ 3.076732] hdaps: device successfully initialized. [ 3.076906] input: hdaps as /class/input/input1 [ 3.076999] hdaps: driver successfully loaded. [ 3.077093] EDAC MC: Ver: 2.0.1 Oct 30 2006 [ 3.077714] thinkpad_ec: thinkpad_ec 0.30 loaded. [ 3.077956] TCP bic registered [ 3.078057] NET: Registered protocol family 1 [ 3.078153] NET: Registered protocol family 17 [ 3.078263] Starting balanced_irq [ 3.078359] Using IPI No-Shortcut mode [ 3.078884] ACPI: (supports S0 S3 S4 S5) [ 3.079246] Time: tsc clocksource has been installed. [ 3.079386] BIOS EDD facility v0.16 2004-Jun-25, 1 devices found [ 3.082224] VFS: Mounted root (ext2 filesystem) readonly. [ 3.082457] Freeing unused kernel memory: 176k freed [ 6.179063] ieee1394: Initialized config rom entry `ip1394' [ 6.181760] ACPI: PCI Interrupt 0000:15:00.1[B] -> GSI 17 (level, low) -> IRQ 21 [ 6.181958] PCI: Setting latency timer of device 0000:15:00.1 to 64 [ 6.235209] ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[21] MMIO=[e4301000-e43017ff] Max Packet=[2048] IR/IT contexts=[4/4] [ 6.349287] input: PC Speaker as /class/input/input2 [ 6.712159] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 [ 6.712263] ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx [ 6.908445] usbcore: registered new interface driver usbfs [ 6.908579] usbcore: registered new interface driver hub [ 6.908711] usbcore: registered new device driver usb [ 7.089196] irda_init() [ 7.089213] NET: Registered protocol family 23 [ 7.146382] USB Universal Host Controller Interface driver v3.0 [ 7.146545] ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 20 [ 7.146745] PCI: Setting latency timer of device 0000:00:1d.0 to 64 [ 7.146751] uhci_hcd 0000:00:1d.0: UHCI Host Controller [ 7.147058] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1 [ 7.147234] uhci_hcd 0000:00:1d.0: irq 20, io base 0x00001820 [ 7.147488] usb usb1: configuration #1 chosen from 1 choice [ 7.147628] hub 1-0:1.0: USB hub found [ 7.147726] hub 1-0:1.0: 2 ports detected [ 7.198161] sdhci: Secure Digital Host Controller Interface driver, 0.12 [ 7.198263] sdhci: Copyright(c) Pierre Ossman [ 7.248594] ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 17 (level, low) -> IRQ 21 [ 7.248798] PCI: Setting latency timer of device 0000:00:1d.1 to 64 [ 7.248804] uhci_hcd 0000:00:1d.1: UHCI Host Controller [ 7.248942] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 2 [ 7.249108] uhci_hcd 0000:00:1d.1: irq 21, io base 0x00001840 [ 7.249338] usb usb2: configuration #1 chosen from 1 choice [ 7.249818] hub 2-0:1.0: USB hub found [ 7.249917] hub 2-0:1.0: 2 ports detected [ 7.351432] ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 22 [ 7.351634] PCI: Setting latency timer of device 0000:00:1d.2 to 64 [ 7.351640] uhci_hcd 0000:00:1d.2: UHCI Host Controller [ 7.351771] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 3 [ 7.351940] uhci_hcd 0000:00:1d.2: irq 22, io base 0x00001860 [ 7.352165] usb usb3: configuration #1 chosen from 1 choice [ 7.352305] hub 3-0:1.0: USB hub found [ 7.352401] hub 3-0:1.0: 2 ports detected [ 7.453217] ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 19 (level, low) -> IRQ 23 [ 7.453403] PCI: Setting latency timer of device 0000:00:1d.3 to 64 [ 7.453408] uhci_hcd 0000:00:1d.3: UHCI Host Controller [ 7.453537] uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 4 [ 7.453701] uhci_hcd 0000:00:1d.3: irq 23, io base 0x00001880 [ 7.453921] usb usb4: configuration #1 chosen from 1 choice [ 7.454051] hub 4-0:1.0: USB hub found [ 7.454150] hub 4-0:1.0: 2 ports detected [ 7.499170] ieee1394: Host added: ID:BUS[0-00:1023] GUID[000ae40600192017] [ 7.555770] ACPI: PCI Interrupt 0000:00:1d.7[D] -> GSI 19 (level, low) -> IRQ 23 [ 7.555969] PCI: Setting latency timer of device 0000:00:1d.7 to 64 [ 7.555975] ehci_hcd 0000:00:1d.7: EHCI Host Controller [ 7.556109] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 5 [ 7.556283] ehci_hcd 0000:00:1d.7: debug port 1 [ 7.556384] PCI: cache line size of 32 is not supported by device 0000:00:1d.7 [ 7.556395] ehci_hcd 0000:00:1d.7: irq 23, io mem 0xee444000 [ 7.560381] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 [ 7.560837] usb usb5: configuration #1 chosen from 1 choice [ 7.560967] hub 5-0:1.0: USB hub found [ 7.561064] hub 5-0:1.0: 8 ports detected [ 7.563438] eth1394: eth1: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0) [ 7.637032] IBM TrackPoint firmware: 0x0e, buttons: 3/3 [ 7.657935] input: TPPS/2 IBM TrackPoint as /class/input/input3 [ 7.661955] Yenta: CardBus bridge found at 0000:15:00.0 [17aa:201c] [ 7.663374] pnp: Device 00:0a activated. [ 7.663471] nsc_ircc_pnp_probe() : From PnP, found firbase 0x2F8 ; irq 7 ; dma 1. [ 7.663500] nsc-ircc, chip->init [ 7.663605] nsc-ircc, Found chip at base=0x164e [ 7.663738] nsc-ircc, driver loaded (Dag Brattli) [ 7.663925] IrDA: Registered device irda0 [ 7.664080] nsc-ircc, Found dongle: No dongle connected [ 7.664183] nsc_ircc_init_dongle_interface(), No dongle connected [ 7.785417] Yenta: ISA IRQ mask 0x0c38, PCI irq 20 [ 7.785519] Socket status: 30000006 [ 7.785615] pcmcia: parent PCI bridge I/O window: 0x9000 - 0xcfff [ 7.785713] pcmcia: parent PCI bridge Memory window: 0xe4300000 - 0xe7ffffff [ 7.785812] pcmcia: parent PCI bridge Memory window: 0xe0000000 - 0xe3ffffff [ 7.786199] ACPI: PCI Interrupt 0000:00:1b.0[B] -> GSI 17 (level, low) -> IRQ 21 [ 7.786450] PCI: Setting latency timer of device 0000:00:1b.0 to 64 [ 8.303763] usb 4-1: new full speed USB device using uhci_hcd and address 2 [ 8.465387] usb 4-1: configuration #1 chosen from 1 choice [ 8.550092] Bluetooth: Core ver 2.11 [ 8.550695] NET: Registered protocol family 31 [ 8.550795] Bluetooth: HCI device and connection manager initialized [ 8.550892] Bluetooth: HCI socket layer initialized [ 8.559175] Bluetooth: HCI USB driver ver 2.9 [ 8.677160] usb 4-2: new full speed USB device using uhci_hcd and address 3 [ 8.833905] hda_intel: No response from codec, disabling MSI... [ 8.842826] usb 4-2: configuration #1 chosen from 1 choice [ 8.847946] usbcore: registered new interface driver hci_usb [ 9.833318] hda_intel: azx_get_response timeout, switching to polling mode... [ 10.832730] hda_intel: azx_get_response timeout, switching to single_cmd mode... [ 21.618159] sdhci: SDHCI controller found at 0000:15:00.2 [1180:0822] (rev 18) [ 21.619154] ACPI: PCI Interrupt 0000:15:00.2[C] -> GSI 18 (level, low) -> IRQ 22 [ 21.620362] PCI: Setting latency timer of device 0000:15:00.2 to 64 [ 21.622574] mmc0: SDHCI at 0xe4301800 irq 22 DMA [ 22.346566] Adding 1951856k swap on /dev/sda12. Priority:-1 extents:1 across:1951856k [ 22.347780] Adding 2931820k swap on /dev/sda13. Priority:-2 extents:1 across:2931820k [ 22.692872] Non-volatile memory driver v1.2 [ 22.731265] ieee1394: sbp2: Driver forced to serialize I/O (serialize_io=1) [ 22.731365] ieee1394: sbp2: Try serialize_io=0 for better performance [ 22.764737] ibm_acpi: IBM ThinkPad ACPI Extras v0.12a [ 22.764844] ibm_acpi: http://ibm-acpi.sf.net/ [ 22.785014] ACPI (exconfig-0455): Dynamic SSDT Load - OemId [ PmRef] OemTableId [ Cpu0Ist] [20060707] [ 22.785828] ACPI (exconfig-0455): Dynamic SSDT Load - OemId [ PmRef] OemTableId [ Cpu0Cst] [20060707] [ 22.787166] ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3]) [ 22.787446] ACPI: Processor [CPU0] (supports 8 throttling states) [ 22.788615] ACPI (exconfig-0455): Dynamic SSDT Load - OemId [ PmRef] OemTableId [ Cpu1Ist] [20060707] [ 22.789318] ACPI (exconfig-0455): Dynamic SSDT Load - OemId [ PmRef] OemTableId [ Cpu1Cst] [20060707] [ 22.790705] ACPI: CPU1 (power states: C1[C1] C2[C2] C3[C3]) [ 22.790991] ACPI: Processor [CPU1] (supports 8 throttling states) [ 23.002000] Time: hpet clocksource has been installed. [ 23.019000] mmcblk0: mmc0:b368 SD 249856KiB [ 23.019000] mmcblk0: p1 [ 38.427000] ReiserFS: sda14: found reiserfs format "3.6" with standard journal [ 38.427000] ReiserFS: sda14: warning: CONFIG_REISERFS_CHECK is set ON [ 38.427000] ReiserFS: sda14: warning: - it is slow mode for debugging. [ 38.427000] ReiserFS: sda14: using ordered data mode [ 38.450000] ReiserFS: sda14: journal params: device sda14, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 [ 38.451000] ReiserFS: sda14: checking transaction log (sda14) [ 38.451000] ReiserFS: sda14: journal-1153: found in header: first_unflushed_offset 7418, last_flushed_trans_id 30277 [ 38.453000] ReiserFS: sda14: journal-1206: Starting replay from offset 130043019795706, trans_id 3223281428 [ 38.453000] ReiserFS: sda14: journal-1299: Setting newest_mount_id to 176 [ 38.495000] ReiserFS: sda14: Using r5 hash to sort names [ 38.558000] ReiserFS: sda8: found reiserfs format "3.6" with standard journal [ 38.558000] ReiserFS: sda8: warning: CONFIG_REISERFS_CHECK is set ON [ 38.558000] ReiserFS: sda8: warning: - it is slow mode for debugging. [ 38.558000] ReiserFS: sda8: using ordered data mode [ 38.565000] ReiserFS: sda8: journal params: device sda8, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 [ 38.566000] ReiserFS: sda8: checking transaction log (sda8) [ 38.566000] ReiserFS: sda8: journal-1153: found in header: first_unflushed_offset 6697, last_flushed_trans_id 571523 [ 38.574000] ReiserFS: sda8: journal-1206: Starting replay from offset 2454676888885801, trans_id 3223281428 [ 38.574000] ReiserFS: sda8: journal-1299: Setting newest_mount_id to 176 [ 38.617000] ReiserFS: sda8: Using r5 hash to sort names [ 38.687000] ReiserFS: sda11: found reiserfs format "3.6" with standard journal [ 38.688000] ReiserFS: sda11: warning: CONFIG_REISERFS_CHECK is set ON [ 38.688000] ReiserFS: sda11: warning: - it is slow mode for debugging. [ 38.688000] ReiserFS: sda11: using ordered data mode [ 38.715000] ReiserFS: sda11: journal params: device sda11, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 [ 38.716000] ReiserFS: sda11: checking transaction log (sda11) [ 38.716000] ReiserFS: sda11: journal-1153: found in header: first_unflushed_offset 5253, last_flushed_trans_id 20436 [ 38.749000] ReiserFS: sda11: journal-1206: Starting replay from offset 87776246633605, trans_id 3223281428 [ 38.749000] ReiserFS: sda11: journal-1299: Setting newest_mount_id to 176 [ 38.771000] ReiserFS: sda11: Using r5 hash to sort names [ 38.798000] ReiserFS: sda10: found reiserfs format "3.6" with standard journal [ 38.799000] ReiserFS: sda10: warning: CONFIG_REISERFS_CHECK is set ON [ 38.799000] ReiserFS: sda10: warning: - it is slow mode for debugging. [ 38.799000] ReiserFS: sda10: using ordered data mode [ 38.809000] ReiserFS: sda10: journal params: device sda10, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 [ 38.809000] ReiserFS: sda10: checking transaction log (sda10) [ 38.810000] ReiserFS: sda10: journal-1153: found in header: first_unflushed_offset 3806, last_flushed_trans_id 20392 [ 38.820000] ReiserFS: sda10: journal-1206: Starting replay from offset 87587268071134, trans_id 3223281428 [ 38.820000] ReiserFS: sda10: journal-1299: Setting newest_mount_id to 176 [ 38.831000] ReiserFS: sda10: Using r5 hash to sort names [ 38.848000] ReiserFS: sda9: found reiserfs format "3.6" with standard journal [ 38.848000] ReiserFS: sda9: warning: CONFIG_REISERFS_CHECK is set ON [ 38.848000] ReiserFS: sda9: warning: - it is slow mode for debugging. [ 38.849000] ReiserFS: sda9: using ordered data mode [ 38.855000] ReiserFS: sda9: journal params: device sda9, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 [ 38.856000] ReiserFS: sda9: checking transaction log (sda9) [ 38.856000] ReiserFS: sda9: journal-1153: found in header: first_unflushed_offset 6872, last_flushed_trans_id 96225 [ 38.859000] ReiserFS: sda9: journal-1206: Starting replay from offset 413287523031768, trans_id 4155609112 [ 38.859000] ReiserFS: sda9: journal-1299: Setting newest_mount_id to 176 [ 38.871000] ReiserFS: sda9: Using r5 hash to sort names [ 38.898000] ReiserFS: sda7: found reiserfs format "3.6" with standard journal [ 38.898000] ReiserFS: sda7: warning: CONFIG_REISERFS_CHECK is set ON [ 38.899000] ReiserFS: sda7: warning: - it is slow mode for debugging. [ 38.899000] ReiserFS: sda7: using ordered data mode [ 38.903000] ReiserFS: sda7: journal params: device sda7, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 [ 38.903000] ReiserFS: sda7: checking transaction log (sda7) [ 38.904000] ReiserFS: sda7: journal-1153: found in header: first_unflushed_offset 5590, last_flushed_trans_id 581233 [ 38.909000] ReiserFS: sda7: journal-1206: Starting replay from offset 2496381021328854, trans_id 24000000 [ 38.910000] ReiserFS: sda7: journal-1299: Setting newest_mount_id to 176 [ 38.953000] ReiserFS: sda7: Using r5 hash to sort names [ 39.014000] ReiserFS: sda6: found reiserfs format "3.6" with standard journal [ 39.015000] ReiserFS: sda6: warning: CONFIG_REISERFS_CHECK is set ON [ 39.015000] ReiserFS: sda6: warning: - it is slow mode for debugging. [ 39.015000] ReiserFS: sda6: using ordered data mode [ 39.052000] ReiserFS: sda6: journal params: device sda6, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 [ 39.052000] ReiserFS: sda6: checking transaction log (sda6) [ 39.052000] ReiserFS: sda6: journal-1153: found in header: first_unflushed_offset 2919, last_flushed_trans_id 787426 [ 39.078000] ReiserFS: sda6: journal-1206: Starting replay from offset 3381973212990311, trans_id 30000000 [ 39.078000] ReiserFS: sda6: journal-1299: Setting newest_mount_id to 176 [ 39.167000] ReiserFS: sda6: Using r5 hash to sort names [ 39.284000] kjournald starting. Commit interval 5 seconds [ 39.284000] EXT3 FS on mmcblk0p1, internal journal [ 39.284000] EXT3-fs: mounted filesystem with ordered data mode. [ 51.071000] ACPI: AC Adapter [AC] (off-line) [ 51.096000] ACPI: Battery Slot [BAT0] (battery present) [ 51.111000] ACPI: Power Button (FF) [PWRF] [ 51.111000] ACPI: Lid Switch [LID] [ 51.111000] ACPI: Sleep Button (CM) [SLPB] [ 51.127000] ACPI: ACPI Dock Station Driver [ 51.177000] ACPI: Thermal Zone [THM0] (46 C) [ 51.179000] ACPI: Thermal Zone [THM1] (47 C) [ 51.194000] ACPI: Video Device [VID] (multi-head: yes rom: no post: no) [ 51.195000] ACPI: Video Device [VID] (multi-head: yes rom: no post: no) [ 64.840000] ACPI: PCI interrupt for device 0000:00:1b.0 disabled [ 65.195000] PCI: Enabling device 0000:00:1b.0 (0100 -> 0102) [ 65.195000] ACPI: PCI Interrupt 0000:00:1b.0[B] -> GSI 17 (level, low) -> IRQ 21 [ 65.198000] PCI: Setting latency timer of device 0000:00:1b.0 to 64 [ 66.484000] hda_intel: No response from codec, disabling MSI... [ 67.485000] hda_intel: azx_get_response timeout, switching to polling mode... [ 71.911000] ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 20 [ 71.912000] [drm] Initialized i915 1.5.0 20060119 on minor 0 [ 155.470000] e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex [ 155.470000] e1000: eth0: e1000_watchdog: 10/100 speed: disabling TSO [ 155.914000] ACPI: docking [ 156.289000] usb 5-6: new high speed USB device using ehci_hcd and address 4 [ 156.403000] usb 5-6: configuration #1 chosen from 1 choice [ 156.403000] hub 5-6:1.0: USB hub found [ 156.403000] hub 5-6:1.0: 4 ports detected [ 156.682000] usb 5-6.1: new low speed USB device using ehci_hcd and address 5 [ 156.773000] usb 5-6.1: configuration #1 chosen from 1 choice [ 156.951000] usb 5-6.3: new low speed USB device using ehci_hcd and address 6 [ 157.057000] usb 5-6.3: configuration #1 chosen from 1 choice [ 157.202000] usbcore: registered new interface driver hiddev [ 157.204000] input: Logitech USB-PS/2 Optical Mouse as /class/input/input4 [ 157.205000] input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-0000:00:1d.7-6.1 [ 157.212000] input: Microsoft Comfort Curve Keyboard 2000 as /class/input/input5 [ 157.212000] input: USB HID v1.11 Keyboard [Microsoft Comfort Curve Keyboard 2000] on usb-0000:00:1d.7-6.3 [ 157.223000] input: Microsoft Comfort Curve Keyboard 2000 as /class/input/input6 [ 157.223000] input: USB HID v1.11 Device [Microsoft Comfort Curve Keyboard 2000] on usb-0000:00:1d.7-6.3 [ 157.223000] usbcore: registered new interface driver usbhid [ 157.223000] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 579.730000] usb 5-6.2: new high speed USB device using ehci_hcd and address 7 [ 579.815000] usb 5-6.2: configuration #1 chosen from 1 choice [ 579.882000] Initializing USB Mass Storage driver... [ 579.882000] scsi4 : SCSI emulation for USB Mass Storage devices [ 579.882000] usb-storage: device found at 7 [ 579.882000] usb-storage: waiting for device to settle before scanning [ 579.882000] usbcore: registered new interface driver usb-storage [ 579.882000] USB Mass Storage support registered. [ 584.884000] scsi 4:0:0:0: Direct-Access USB 2.0 memory 0.00 PQ: 0 ANSI: 2 [ 584.885000] SCSI device sdb: 1024000 512-byte hdwr sectors (524 MB) [ 584.886000] sdb: Write Protect is off [ 584.886000] sdb: Mode Sense: 00 00 00 00 [ 584.886000] sdb: assuming drive cache: write through [ 584.888000] SCSI device sdb: 1024000 512-byte hdwr sectors (524 MB) [ 584.888000] sdb: Write Protect is off [ 584.888000] sdb: Mode Sense: 00 00 00 00 [ 584.888000] sdb: assuming drive cache: write through [ 584.889000] sdb: sdb1 [ 585.076000] sd 4:0:0:0: Attached scsi removable disk sdb [ 585.077000] usb-storage: device scan complete [ 599.265000] usb 5-6.2: USB disconnect, address 7 [ 702.852000] ACPI: undocking [ 703.083000] usb 5-6: USB disconnect, address 4 [ 703.083000] usb 5-6.1: USB disconnect, address 5 [ 703.083000] usb 5-6.3: USB disconnect, address 6 [ 708.397000] e1000: eth0: e1000_watchdog: NIC Link is Down [ 729.483000] Disabling non-boot CPUs ... [ 729.537000] Breaking affinity for irq 219 [ 729.538000] CPU 1 is now offline [ 729.538000] SMP alternatives: switching to UP code [ 729.547000] CPU1 is down [ 729.547000] Stopping tasks: =========================================================================================================================| [ 730.081000] Suspending console(s) [ 730.081000] usbdev4.3_ep83: PM: suspend 0->2, parent 4-2:1.0 already 2 [ 730.081000] usbdev4.3_ep02: PM: suspend 0->2, parent 4-2:1.0 already 2 [ 730.081000] usbdev4.3_ep81: PM: suspend 0->2, parent 4-2:1.0 already 2 [ 730.081000] usb 4-2:1.0: PM: suspend 2->2, parent 4-2 already 2 [ 730.081000] usbdev4.3_ep00: PM: suspend 0->2, parent 4-2 already 2 [ 730.094000] hdaps: setting ec_rate=0, filter_order=1 [ 731.775000] pnp: Device 00:0a disabled. [ 731.776000] ACPI: PCI interrupt for device 0000:15:00.2 disabled [ 731.798000] ACPI: PCI interrupt for device 0000:15:00.0 disabled [ 731.846000] ACPI: PCI interrupt for device 0000:02:00.0 disabled [ 731.859000] ACPI: PCI interrupt for device 0000:00:1f.2 disabled [ 731.870000] ACPI: PCI interrupt for device 0000:00:1d.7 disabled [ 731.982000] ACPI: PCI interrupt for device 0000:00:1d.3 disabled [ 731.982000] ACPI: PCI interrupt for device 0000:00:1d.2 disabled [ 731.982000] ACPI: PCI interrupt for device 0000:00:1d.1 disabled [ 731.982000] ACPI: PCI interrupt for device 0000:00:1d.0 disabled [ 731.984000] ACPI: PCI interrupt for device 0000:00:1b.0 disabled [ 731.995000] Intel machine check architecture supported. [ 731.995000] Intel machine check reporting enabled on CPU#0. [ 731.995000] Back to C! [ 1633.713000] PM: Writing back config space on device 0000:00:02.1 at offset 1 (was 900000, writing 900003) [ 1633.725000] PM: Writing back config space on device 0000:00:1b.0 at offset 1 (was 100106, writing 100100) [ 1633.725000] PCI: Enabling device 0000:00:1b.0 (0100 -> 0102) [ 1633.725000] ACPI: PCI Interrupt 0000:00:1b.0[B] -> GSI 17 (level, low) -> IRQ 21 [ 1633.725000] PCI: Setting latency timer of device 0000:00:1b.0 to 64 [ 1633.743000] PM: Writing back config space on device 0000:00:1c.0 at offset 1 (was 100107, writing 100507) [ 1633.743000] PCI: Setting latency timer of device 0000:00:1c.0 to 64 [ 1633.743000] PM: Writing back config space on device 0000:00:1c.1 at offset 1 (was 100107, writing 100507) [ 1633.743000] PCI: Setting latency timer of device 0000:00:1c.1 to 64 [ 1633.743000] PM: Writing back config space on device 0000:00:1c.2 at offset 7 (was 20006050, writing 6050) [ 1633.743000] PM: Writing back config space on device 0000:00:1c.2 at offset 1 (was 100107, writing 100507) [ 1633.743000] PCI: Setting latency timer of device 0000:00:1c.2 to 64 [ 1633.743000] PM: Writing back config space on device 0000:00:1c.3 at offset f (was 40400, writing 4040b) [ 1633.743000] PM: Writing back config space on device 0000:00:1c.3 at offset 9 (was 10001, writing e421e421) [ 1633.743000] PM: Writing back config space on device 0000:00:1c.3 at offset 8 (was 0, writing ebf0ea00) [ 1633.743000] PM: Writing back config space on device 0000:00:1c.3 at offset 7 (was 20000000, writing 8070) [ 1633.743000] PM: Writing back config space on device 0000:00:1c.3 at offset 3 (was 810000, writing 810010) [ 1633.743000] PM: Writing back config space on device 0000:00:1c.3 at offset 1 (was 100000, writing 100507) [ 1633.743000] PCI: Setting latency timer of device 0000:00:1c.3 to 64 [ 1633.743000] ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 20 [ 1633.743000] PCI: Setting latency timer of device 0000:00:1d.0 to 64 [ 1633.743000] usb usb1: root hub lost power or was reset [ 1633.743000] ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 17 (level, low) -> IRQ 21 [ 1633.743000] PCI: Setting latency timer of device 0000:00:1d.1 to 64 [ 1633.743000] usb usb2: root hub lost power or was reset [ 1633.743000] ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 22 [ 1633.743000] PCI: Setting latency timer of device 0000:00:1d.2 to 64 [ 1633.743000] usb usb3: root hub lost power or was reset [ 1633.743000] ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 19 (level, low) -> IRQ 23 [ 1633.743000] PCI: Setting latency timer of device 0000:00:1d.3 to 64 [ 1633.743000] usb usb4: root hub lost power or was reset [ 1634.104000] ACPI: PCI Interrupt 0000:00:1d.7[D] -> GSI 19 (level, low) -> IRQ 23 [ 1634.104000] PCI: Setting latency timer of device 0000:00:1d.7 to 64 [ 1634.104000] PM: Writing back config space on device 0000:00:1e.0 at offset 1 (was 100005, writing 100007) [ 1634.104000] PCI: Setting latency timer of device 0000:00:1e.0 to 64 [ 1634.115000] ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 16 (level, low) -> IRQ 20 [ 1634.115000] PCI: Setting latency timer of device 0000:00:1f.2 to 64 [ 1635.129000] ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 20 [ 1635.129000] PCI: Setting latency timer of device 0000:02:00.0 to 64 [ 1635.172000] PM: Writing back config space on device 0000:15:00.0 at offset 1 (was 2100000, writing 2100007) [ 1635.172000] ACPI: PCI Interrupt 0000:15:00.0[A] -> GSI 16 (level, low) -> IRQ 20 [ 1635.214000] PM: Writing back config space on device 0000:15:00.1 at offset 4 (was 0, writing e4301000) [ 1635.214000] PM: Writing back config space on device 0000:15:00.1 at offset 3 (was 800000, writing 804000) [ 1635.214000] PM: Writing back config space on device 0000:15:00.1 at offset 1 (was 2100000, writing 2100006) [ 1635.225000] PM: Writing back config space on device 0000:15:00.2 at offset 4 (was 0, writing e4301800) [ 1635.225000] PM: Writing back config space on device 0000:15:00.2 at offset 3 (was 800000, writing 804000) [ 1635.225000] PM: Writing back config space on device 0000:15:00.2 at offset 1 (was 2100000, writing 2100006) [ 1635.225000] ACPI: PCI Interrupt 0000:15:00.2[C] -> GSI 18 (level, low) -> IRQ 22 [ 1635.400000] pnp: Device 00:08 does not support activation. [ 1635.400000] pnp: Device 00:09 does not support activation. [ 1635.401000] pnp: Device 00:0a activated. [ 1635.421000] ata2: SATA link down (SStatus 0 SControl 0) [ 1635.421000] ata3: SATA link down (SStatus 0 SControl 0) [ 1635.421000] ata4: SATA link down (SStatus 0 SControl 0) [ 1635.680000] hdaps: initial mode latch is 0x05 [ 1635.680000] hdaps: setting ec_rate=250, filter_order=2 [ 1635.680000] hdaps: fake_data_mode set to 0 [ 1635.821000] nsc_ircc_init_dongle_interface(), No dongle connected [ 1635.821000] nsc_ircc_change_dongle_speed(), No dongle connected is not for IrDA mode [ 1635.821000] usbdev4.2_ep00: PM: resume from 0, parent 4-1 still 2 [ 1635.821000] hci_usb 4-1:1.0: PM: resume from 2, parent 4-1 still 2 [ 1635.821000] usbdev4.2_ep81: PM: resume from 0, parent 4-1:1.0 still 2 [ 1635.821000] usbdev4.2_ep82: PM: resume from 0, parent 4-1:1.0 still 2 [ 1635.821000] usbdev4.2_ep02: PM: resume from 0, parent 4-1:1.0 still 2 [ 1635.821000] hci_usb 4-1:1.1: PM: resume from 2, parent 4-1 still 2 [ 1635.821000] usb 4-1:1.2: PM: resume from 2, parent 4-1 still 2 [ 1635.821000] usbdev4.2_ep84: PM: resume from 0, parent 4-1:1.2 still 2 [ 1635.821000] usbdev4.2_ep04: PM: resume from 0, parent 4-1:1.2 still 2 [ 1635.821000] usb 4-1:1.3: PM: resume from 2, parent 4-1 still 2 [ 1635.821000] usbdev4.3_ep00: PM: resume from 0, parent 4-2 still 2 [ 1635.821000] usbdev4.3_ep81: PM: resume from 0, parent 4-2:1.0 still 2 [ 1635.821000] usbdev4.3_ep02: PM: resume from 0, parent 4-2:1.0 still 2 [ 1635.821000] usbdev4.3_ep83: PM: resume from 0, parent 4-2:1.0 still 2 [ 1635.821000] usbdev4.2_ep83: PM: resume from 0, parent 4-1:1.1 still 2 [ 1635.821000] usbdev4.2_ep03: PM: resume from 0, parent 4-1:1.1 still 2 [ 1635.821000] hci0: PM: resume from 0, parent 4-1:1.0 still 2 [ 1635.822000] Restarting tasks...<6>usb 4-1: USB disconnect, address 2 [ 1635.832000] done [ 1635.832000] Enabling non-boot CPUs ... [ 1635.845000] SMP alternatives: switching to SMP code [ 1635.846000] Booting processor 1/1 eip 3000 [ 1635.856000] Initializing CPU#1 [ 1635.917000] Calibrating delay using timer specific routine.. 3325.06 BogoMIPS (lpj=1662531) [ 1635.917000] CPU: After generic identify, caps: bfe9fbff 00100000 00000000 00000000 0000c1a9 00000000 00000000 [ 1635.917000] monitor/mwait feature present. [ 1635.917000] CPU: L1 I cache: 32K, L1 D cache: 32K [ 1635.917000] CPU: L2 cache: 2048K [ 1635.917000] CPU: Physical Processor ID: 0 [ 1635.917000] CPU: Processor Core ID: 1 [ 1635.917000] CPU: After all inits, caps: bfe9fbff 00100000 00000000 00000940 0000c1a9 00000000 00000000 [ 1635.917000] Intel machine check architecture supported. [ 1635.917000] Intel machine check reporting enabled on CPU#1. [ 1635.917000] CPU1: Intel Genuine Intel(R) CPU L2400 @ 1.66GHz stepping 08 [ 1635.996000] usb 4-2: USB disconnect, address 3 [ 1636.202000] usb 4-2: new full speed USB device using uhci_hcd and address 4 [ 1636.365000] usb 4-2: configuration #1 chosen from 1 choice [ 1636.647000] ata1: waiting for device to spin up (7 secs) [ 1636.817000] usb 4-1: new full speed USB device using uhci_hcd and address 5 [ 1636.977000] usb 4-1: configuration #1 chosen from 1 choice [ 1638.293000] CPU1 is up [ 1644.484000] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 1644.488000] ata1.00: configured for UDMA/100 [ 1644.489000] SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) [ 1644.489000] sda: Write Protect is off [ 1644.489000] sda: Mode Sense: 00 3a 00 00 [ 1644.489000] SCSI device sda: drive cache: write back [ 1831.582000] thinkpad_ec: thinkpad_ec_request_row: bad end STR3: (0x11:0x00)->0x80 [-- Attachment #5: ibm_acpi.dump.2006-10-30-150116-UTC_before --] [-- Type: text/plain, Size: 3479 bytes --] /proc/acpi/ibm/bay status: not supported ================================================================ /proc/acpi/ibm/beep status: supported commands: <cmd> (<cmd> is 0-17) ================================================================ /proc/acpi/ibm/bluetooth status: enabled commands: enable, disable ================================================================ /proc/acpi/ibm/brightness level: 3 commands: up, down commands: level <level> (<level> is 0-7) ================================================================ /proc/acpi/ibm/cmos status: supported commands: <cmd> (<cmd> is 0-21) ================================================================ /proc/acpi/ibm/driver driver: IBM ThinkPad ACPI Extras version: 0.12a ================================================================ /proc/acpi/ibm/ecdump EC +00 +01 +02 +03 +04 +05 +06 +07 +08 +09 +0a +0b +0c +0d +0e +0f EC 0x00: *a6 *05 *a0 *01 *fe *96 00 00 *1f *02 *47 00 00 00 *80 00 EC 0x10: 00 00 *ff *ff *f4 *3c *87 *09 *43 *ff *82 *01 *ff *ff *2d 00 EC 0x20: 00 00 00 00 00 00 00 00 00 00 00 00 *85 00 00 *80 EC 0x30: *4a *03 *12 00 *30 *04 00 00 *c5 00 *b0 *10 00 *50 00 00 EC 0x40: 00 00 00 00 00 00 *84 *01 *0a 00 00 00 00 00 00 00 EC 0x50: 00 *c0 *02 *23 *41 00 *33 *2d *03 *2f *2d *06 *21 *23 *30 00 EC 0x60: *80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 EC 0x70: 00 00 00 00 00 *12 *30 *40 *2e *2a *80 *2d *21 *80 *1f *80 EC 0x80: 00 00 00 *06 00 00 *03 00 00 00 *0e *78 00 00 00 00 EC 0x90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 EC 0xa0: *11 *0a *74 *0a *62 00 *61 00 *34 *fc *3b *3f *ff *ff *e0 00 EC 0xb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 EC 0xc0: *2b *29 *80 *80 *80 *80 *80 *80 00 00 00 00 00 00 *10 00 EC 0xd0: *06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 EC 0xe0: 00 00 00 00 00 00 00 00 *10 *80 *a6 *04 *24 *2e *55 *03 EC 0xf0: *37 *42 *48 *54 *33 *35 *57 *57 *0c *f5 *60 *7c *0c *e7 *63 *93 ================================================================ /proc/acpi/ibm/fan status: enabled speed: 0 commands: enable, disable ================================================================ /proc/acpi/ibm/hotkey status: enabled mask: 0xff9f commands: enable, disable, reset, <mask> ================================================================ /proc/acpi/ibm/led status: supported commands: <led> on, <led> off, <led> blink (<led> is 0-7) ================================================================ /proc/acpi/ibm/light status: off commands: on, off ================================================================ /proc/acpi/ibm/thermal temperatures: 46 42 -128 45 33 -128 31 -128 ================================================================ /proc/acpi/ibm/video status: supported lcd: enabled crt: enabled dvi: disabled auto: enabled commands: lcd_enable, lcd_disable commands: crt_enable, crt_disable commands: dvi_enable, dvi_disable commands: auto_enable, auto_disable commands: video_switch, expand_toggle ================================================================ /proc/acpi/ibm/volume level: 10 mute: on commands: up, down, mute commands: level <level> (<level> is 0-15) ================================================================ /proc/acpi/ibm/wan status: not installed ================================================================ [-- Attachment #6: ibm_acpi.dump.2006-10-30-151632-UTC_after1 --] [-- Type: text/plain, Size: 3479 bytes --] /proc/acpi/ibm/bay status: not supported ================================================================ /proc/acpi/ibm/beep status: supported commands: <cmd> (<cmd> is 0-17) ================================================================ /proc/acpi/ibm/bluetooth status: enabled commands: enable, disable ================================================================ /proc/acpi/ibm/brightness level: 3 commands: up, down commands: level <level> (<level> is 0-7) ================================================================ /proc/acpi/ibm/cmos status: supported commands: <cmd> (<cmd> is 0-21) ================================================================ /proc/acpi/ibm/driver driver: IBM ThinkPad ACPI Extras version: 0.12a ================================================================ /proc/acpi/ibm/ecdump EC +00 +01 +02 +03 +04 +05 +06 +07 +08 +09 +0a +0b +0c +0d +0e +0f EC 0x00: *a7 05 a0 01 fe 96 00 00 1f 02 47 00 00 00 80 00 EC 0x10: 00 00 ff ff f4 3c 87 09 43 ff 82 01 ff ff 2d 00 EC 0x20: 00 00 00 00 00 00 00 00 00 00 00 00 85 00 00 80 EC 0x30: 4a 03 *02 00 30 04 *04 00 c5 00 *30 10 *2a 50 00 00 EC 0x40: 00 00 00 00 00 00 84 01 0a 00 00 00 00 00 *04 00 EC 0x50: 00 c0 02 23 41 00 33 2d 03 2f 2d 06 21 23 30 00 EC 0x60: 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 EC 0x70: 00 00 00 00 00 12 30 40 *24 *1e 80 *20 *1c 80 *1c 80 EC 0x80: 00 00 00 06 00 00 03 00 00 00 0e 78 00 00 00 00 EC 0x90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 EC 0xa0: *ef *09 74 0a *6e 00 *5f 00 *9e fc *f0 *3e ff ff *c0 00 EC 0xb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 EC 0xc0: *1d *1e 80 80 80 80 80 80 00 00 00 00 00 00 10 00 EC 0xd0: 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 EC 0xe0: 00 00 00 00 00 00 00 00 10 80 a6 04 24 2e 55 03 EC 0xf0: 37 42 48 54 33 35 57 57 0c f5 60 7c 0c e7 63 93 ================================================================ /proc/acpi/ibm/fan status: enabled speed: 0 commands: enable, disable ================================================================ /proc/acpi/ibm/hotkey status: enabled mask: 0xff9f commands: enable, disable, reset, <mask> ================================================================ /proc/acpi/ibm/led status: supported commands: <led> on, <led> off, <led> blink (<led> is 0-7) ================================================================ /proc/acpi/ibm/light status: off commands: on, off ================================================================ /proc/acpi/ibm/thermal temperatures: 41 31 -128 37 29 -128 28 -128 ================================================================ /proc/acpi/ibm/video status: supported lcd: enabled crt: enabled dvi: disabled auto: enabled commands: lcd_enable, lcd_disable commands: crt_enable, crt_disable commands: dvi_enable, dvi_disable commands: auto_enable, auto_disable commands: video_switch, expand_toggle ================================================================ /proc/acpi/ibm/volume level: 10 mute: on commands: up, down, mute commands: level <level> (<level> is 0-15) ================================================================ /proc/acpi/ibm/wan status: not installed ================================================================ [-- Attachment #7: ibm_acpi.dump.2006-10-30-151747-UTC_after2 --] [-- Type: text/plain, Size: 3480 bytes --] /proc/acpi/ibm/bay status: not supported ================================================================ /proc/acpi/ibm/beep status: supported commands: <cmd> (<cmd> is 0-17) ================================================================ /proc/acpi/ibm/bluetooth status: enabled commands: enable, disable ================================================================ /proc/acpi/ibm/brightness level: 3 commands: up, down commands: level <level> (<level> is 0-7) ================================================================ /proc/acpi/ibm/cmos status: supported commands: <cmd> (<cmd> is 0-21) ================================================================ /proc/acpi/ibm/driver driver: IBM ThinkPad ACPI Extras version: 0.12a ================================================================ /proc/acpi/ibm/ecdump EC +00 +01 +02 +03 +04 +05 +06 +07 +08 +09 +0a +0b +0c +0d +0e +0f EC 0x00: a7 05 a0 01 fe 96 00 00 1f 02 47 00 00 00 80 00 EC 0x10: 00 00 ff ff f4 3c 87 09 43 ff 82 01 ff ff 2d 00 EC 0x20: 00 00 00 00 00 00 00 00 00 00 00 00 85 00 00 80 EC 0x30: 4a 03 02 00 30 04 00 00 c5 00 30 10 2a 50 00 00 EC 0x40: 00 00 00 00 00 00 84 01 0a 00 00 00 00 00 00 00 EC 0x50: 00 c0 02 23 41 00 33 2d 03 2f 2d 06 21 23 30 00 EC 0x60: 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 EC 0x70: 00 00 00 00 00 12 30 40 *2b *1f 80 *26 1d 80 1c 80 EC 0x80: 00 00 00 06 00 00 03 00 00 00 0e 78 00 00 00 00 EC 0x90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 EC 0xa0: *c7 09 74 0a *4d 00 *5e 00 *28 fc *87 3e ff ff c0 00 EC 0xb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 EC 0xc0: *20 *21 80 80 80 80 80 80 00 00 00 00 00 00 10 00 EC 0xd0: 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 EC 0xe0: 00 00 00 00 00 00 00 00 10 80 a6 04 24 2e 55 03 EC 0xf0: 37 42 48 54 33 35 57 57 0c f5 60 7c 0c e7 63 93 ================================================================ /proc/acpi/ibm/fan status: enabled speed: 0 commands: enable, disable ================================================================ /proc/acpi/ibm/hotkey status: disabled mask: 0x080c commands: enable, disable, reset, <mask> ================================================================ /proc/acpi/ibm/led status: supported commands: <led> on, <led> off, <led> blink (<led> is 0-7) ================================================================ /proc/acpi/ibm/light status: off commands: on, off ================================================================ /proc/acpi/ibm/thermal temperatures: 45 32 -128 40 29 -128 28 -128 ================================================================ /proc/acpi/ibm/video status: supported lcd: enabled crt: enabled dvi: disabled auto: enabled commands: lcd_enable, lcd_disable commands: crt_enable, crt_disable commands: dvi_enable, dvi_disable commands: auto_enable, auto_disable commands: video_switch, expand_toggle ================================================================ /proc/acpi/ibm/volume level: 10 mute: on commands: up, down, mute commands: level <level> (<level> is 0-15) ================================================================ /proc/acpi/ibm/wan status: not installed ================================================================ [-- Attachment #8: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3) 2006-10-30 13:56 ` Michael S. Tsirkin (?) (?) @ 2006-10-30 16:17 ` Jun'ichi Nomura 2006-10-30 16:32 ` Michael S. Tsirkin 2006-10-30 16:44 ` Linus Torvalds -1 siblings, 2 replies; 152+ messages in thread From: Jun'ichi Nomura @ 2006-10-30 16:17 UTC (permalink / raw) To: Michael S. Tsirkin, Martin Lorenz Cc: Pavel Machek, Adrian Bunk, Linus Torvalds, Andrew Morton, Linux Kernel Mailing List, len.brown, linux-acpi, linux-pm, Randy.Dunlap Hi Michael, > 2.6.19-rc3 without reverting > d7dd8fd9557840162b724a8ac1366dd78a12dff stops receiving ACPI events after some > use (sometimes after suspend/resume, sometimes after kernel build stress). Now, > what does this tell us? Andrew, any idea? The code is related to bd_claim_by_disk which is called when device-mapper or md tries to mark the underlying devices for exclusive use and creates symlinks from/to the devices in sysfs. The patch added error handlings which weren't in the original code. I have no idea how it affects ACPI event handling. Are you using dm and/or md on your machine? Have you seen any unusual kernel messages or symptoms regarding dm/md before the ACPI problem occurs? Michael S. Tsirkin wrote: > Quoting r. Adrian Bunk <bunk@stusta.de>: >> Subject : T60 stops triggering any ACPI events >> References : http://lkml.org/lkml/2006/10/4/425 >> http://lkml.org/lkml/2006/10/16/262 >> http://bugzilla.kernel.org/show_bug.cgi?id=7408 >> Submitter : "Michael S. Tsirkin" <mst@mellanox.co.il> >> Status : unknown > > OK, I spent half a night with git-bisect, and the patch that triggers this issue > seems to be this: > > commit d7dd8fd9557840162b724a8ac1366dd78a12dff > Author: Andrew Morton <akpm@osdl.org> > [PATCH] blockdev.c: check driver layer errors > > Reset to d7dd8fd9557840162b724a8ac1366dd78a12dff seems to hide part of the issue > (I have ACPI after kernel build, but not after suspend/resume). Both reverting > this patch, and reset to the parent of this patch seem to solve (or at least, > hide) both problems for me (no ACPI after suspend/resume and no ACPI after > kernel build). > > I am currently running on 2.6.19-rc3 minus > d7dd8fd9557840162b724a8ac1366dd78a12dff, and in a full day of use I have not > observed any issues yet. 2.6.19-rc3 without reverting > d7dd8fd9557840162b724a8ac1366dd78a12dff stops receiving ACPI events after some > use (sometimes after suspend/resume, sometimes after kernel build stress). Now, > what does this tell us? Andrew, any idea? > > > Martin, could you test whether reverting this helps you, too, by chance? > Here's a patch to apply for testing this. > > --- > > commit 658488b7577b7b2242372c43f081f55e2d274615 > Author: Michael S. Tsirkin <mst@mellanox.co.il> > Date: Mon Oct 30 01:28:40 2006 +0200 > > Revert "[PATCH] blockdev.c: check driver layer errors" > > This reverts commit 4d7dd8fd9557840162b724a8ac1366dd78a12dff. Thanks, -- Jun'ichi Nomura, NEC Corporation of America ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3) 2006-10-30 16:17 ` Jun'ichi Nomura @ 2006-10-30 16:32 ` Michael S. Tsirkin 2006-10-30 17:20 ` Jun'ichi Nomura 2006-10-30 16:44 ` Linus Torvalds 1 sibling, 1 reply; 152+ messages in thread From: Michael S. Tsirkin @ 2006-10-30 16:32 UTC (permalink / raw) To: Jun'ichi Nomura Cc: Martin Lorenz, Pavel Machek, Adrian Bunk, Linus Torvalds, Andrew Morton, Linux Kernel Mailing List, len.brown, linux-acpi, linux-pm, Randy.Dunlap Quoting r. Jun'ichi Nomura <j-nomura@ce.jp.nec.com>: > Subject: Re: 2.6.19-rc3: known unfixed regressions (v3) > > Hi Michael, > > > 2.6.19-rc3 without reverting > > d7dd8fd9557840162b724a8ac1366dd78a12dff stops receiving ACPI events after some > > use (sometimes after suspend/resume, sometimes after kernel build stress). Now, > > what does this tell us? Andrew, any idea? > > The code is related to bd_claim_by_disk which is called when > device-mapper or md tries to mark the underlying devices > for exclusive use and creates symlinks from/to the devices > in sysfs. The patch added error handlings which weren't in > the original code. > > I have no idea how it affects ACPI event handling. It's a mystery. Probably exposes a bug somewhere? > Are you using dm and/or md on your machine? The .config is attached to bugzilla. > Have you seen any unusual kernel messages or symptoms regarding > dm/md before the ACPI problem occurs? I haven't. -- MST ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3) 2006-10-30 16:32 ` Michael S. Tsirkin @ 2006-10-30 17:20 ` Jun'ichi Nomura 0 siblings, 0 replies; 152+ messages in thread From: Jun'ichi Nomura @ 2006-10-30 17:20 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Andrew Morton, len.brown, Linus Torvalds, linux-pm, linux-acpi, Linux Kernel Mailing List, Adrian Bunk, Martin Lorenz Hi Michael, Michael S. Tsirkin wrote: >> The code is related to bd_claim_by_disk which is called when >> device-mapper or md tries to mark the underlying devices >> for exclusive use and creates symlinks from/to the devices >> in sysfs. The patch added error handlings which weren't in >> the original code. >> >> I have no idea how it affects ACPI event handling. > > It's a mystery. Probably exposes a bug somewhere? > >> Are you using dm and/or md on your machine? > > The .config is attached to bugzilla. OK, I found you disabled CONFIG_MD, which means neither dm.ko nor md.ko was built. Do you have any out-of-tree kernel modules which call either bd_claim_by_kobject or bd_claim_by_disk? If you aren't using either of them, I'm afraid reverting the patch doesn't really solve your problem because the patched code is called only from them. >> Have you seen any unusual kernel messages or symptoms regarding >> dm/md before the ACPI problem occurs? > > I haven't. Thanks, -- Jun'ichi Nomura, NEC Corporation of America ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3) @ 2006-10-30 17:20 ` Jun'ichi Nomura 0 siblings, 0 replies; 152+ messages in thread From: Jun'ichi Nomura @ 2006-10-30 17:20 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Martin Lorenz, Pavel Machek, Adrian Bunk, Linus Torvalds, Andrew Morton, Linux Kernel Mailing List, len.brown, linux-acpi, linux-pm, Randy.Dunlap Hi Michael, Michael S. Tsirkin wrote: >> The code is related to bd_claim_by_disk which is called when >> device-mapper or md tries to mark the underlying devices >> for exclusive use and creates symlinks from/to the devices >> in sysfs. The patch added error handlings which weren't in >> the original code. >> >> I have no idea how it affects ACPI event handling. > > It's a mystery. Probably exposes a bug somewhere? > >> Are you using dm and/or md on your machine? > > The .config is attached to bugzilla. OK, I found you disabled CONFIG_MD, which means neither dm.ko nor md.ko was built. Do you have any out-of-tree kernel modules which call either bd_claim_by_kobject or bd_claim_by_disk? If you aren't using either of them, I'm afraid reverting the patch doesn't really solve your problem because the patched code is called only from them. >> Have you seen any unusual kernel messages or symptoms regarding >> dm/md before the ACPI problem occurs? > > I haven't. Thanks, -- Jun'ichi Nomura, NEC Corporation of America ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3) 2006-10-30 17:20 ` Jun'ichi Nomura @ 2006-10-30 17:54 ` Michael S. Tsirkin -1 siblings, 0 replies; 152+ messages in thread From: Michael S. Tsirkin @ 2006-10-30 17:54 UTC (permalink / raw) To: Jun'ichi Nomura Cc: Andrew Morton, len.brown, Linus Torvalds, linux-pm, linux-acpi, Linux Kernel Mailing List, Adrian Bunk, Martin Lorenz Quoting r. Jun'ichi Nomura <j-nomura@ce.jp.nec.com>: > Subject: Re: 2.6.19-rc3: known unfixed regressions (v3) > > Hi Michael, > > Michael S. Tsirkin wrote: > >> The code is related to bd_claim_by_disk which is called when > >> device-mapper or md tries to mark the underlying devices > >> for exclusive use and creates symlinks from/to the devices > >> in sysfs. The patch added error handlings which weren't in > >> the original code. > >> > >> I have no idea how it affects ACPI event handling. > > > > It's a mystery. Probably exposes a bug somewhere? > > > >> Are you using dm and/or md on your machine? > > > > The .config is attached to bugzilla. > > OK, I found you disabled CONFIG_MD, which means neither > dm.ko nor md.ko was built. > Do you have any out-of-tree kernel modules which call either > bd_claim_by_kobject or bd_claim_by_disk? No, I don't have any out-of-tree modules. > If you aren't using either of them, I'm afraid reverting > the patch doesn't really solve your problem because the patched > code is called only from them. I agree this could be just papering over some issue. The test results (of both git-bisect and reverting the patch) seem to be pretty consistent so far though. Keep me posted if you rework the patch. > >> Have you seen any unusual kernel messages or symptoms regarding > >> dm/md before the ACPI problem occurs? > > > > I haven't. > > Thanks, -- MST ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3) @ 2006-10-30 17:54 ` Michael S. Tsirkin 0 siblings, 0 replies; 152+ messages in thread From: Michael S. Tsirkin @ 2006-10-30 17:54 UTC (permalink / raw) To: Jun'ichi Nomura Cc: Martin Lorenz, Pavel Machek, Adrian Bunk, Linus Torvalds, Andrew Morton, Linux Kernel Mailing List, len.brown, linux-acpi, linux-pm, Randy.Dunlap Quoting r. Jun'ichi Nomura <j-nomura@ce.jp.nec.com>: > Subject: Re: 2.6.19-rc3: known unfixed regressions (v3) > > Hi Michael, > > Michael S. Tsirkin wrote: > >> The code is related to bd_claim_by_disk which is called when > >> device-mapper or md tries to mark the underlying devices > >> for exclusive use and creates symlinks from/to the devices > >> in sysfs. The patch added error handlings which weren't in > >> the original code. > >> > >> I have no idea how it affects ACPI event handling. > > > > It's a mystery. Probably exposes a bug somewhere? > > > >> Are you using dm and/or md on your machine? > > > > The .config is attached to bugzilla. > > OK, I found you disabled CONFIG_MD, which means neither > dm.ko nor md.ko was built. > Do you have any out-of-tree kernel modules which call either > bd_claim_by_kobject or bd_claim_by_disk? No, I don't have any out-of-tree modules. > If you aren't using either of them, I'm afraid reverting > the patch doesn't really solve your problem because the patched > code is called only from them. I agree this could be just papering over some issue. The test results (of both git-bisect and reverting the patch) seem to be pretty consistent so far though. Keep me posted if you rework the patch. > >> Have you seen any unusual kernel messages or symptoms regarding > >> dm/md before the ACPI problem occurs? > > > > I haven't. > > Thanks, -- MST ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3) 2006-10-30 16:17 ` Jun'ichi Nomura 2006-10-30 16:32 ` Michael S. Tsirkin @ 2006-10-30 16:44 ` Linus Torvalds 2006-10-30 17:34 ` Jun'ichi Nomura 1 sibling, 1 reply; 152+ messages in thread From: Linus Torvalds @ 2006-10-30 16:44 UTC (permalink / raw) To: Jun'ichi Nomura Cc: Michael S. Tsirkin, Martin Lorenz, Pavel Machek, Adrian Bunk, Andrew Morton, Linux Kernel Mailing List, len.brown, linux-acpi, linux-pm, Randy.Dunlap On Mon, 30 Oct 2006, Jun'ichi Nomura wrote: > > The code is related to bd_claim_by_disk which is called when > device-mapper or md tries to mark the underlying devices > for exclusive use and creates symlinks from/to the devices > in sysfs. The patch added error handlings which weren't in > the original code. Actually, looking closer at the code, the patch seems to add _incorrect_ error handling. For example, look at bd_claim_by_kobject(): if the "bd_claim()" inside of it succeeds, we used to always return success. Now, we don't necessarily do that: we may have done a _successful_ "bd_claim()" call, but then we return an error because something else failed, and now we're returning with from bd_claim_by_kobject() with the bd_claim() done, but with an error return (so the caller will _not_ call "bd_release()", and the block_device will forever stay exclusive). No? Now, exactly why acpi stops working as a result, I don't know, but maybe something else tries to get exclusive access to a swap partition, for example, and now fails, causing some acpi sequence to not be set up? Dunno. So I suspect it should be reverted, but maybe somebody can see exactly what goes wrong here. Linus ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3) 2006-10-30 16:44 ` Linus Torvalds @ 2006-10-30 17:34 ` Jun'ichi Nomura 2006-10-30 18:16 ` Linus Torvalds 0 siblings, 1 reply; 152+ messages in thread From: Jun'ichi Nomura @ 2006-10-30 17:34 UTC (permalink / raw) To: Linus Torvalds Cc: Michael S. Tsirkin, Martin Lorenz, Pavel Machek, Adrian Bunk, Andrew Morton, Linux Kernel Mailing List, len.brown, linux-acpi, linux-pm, Randy.Dunlap Hi Linus, Linus Torvalds wrote: > Actually, looking closer at the code, the patch seems to add _incorrect_ > error handling. > > For example, look at bd_claim_by_kobject(): if the "bd_claim()" inside of > it succeeds, we used to always return success. Now, we don't necessarily > do that: we may have done a _successful_ "bd_claim()" call, but then we > return an error because something else failed, and now we're returning > with from bd_claim_by_kobject() with the bd_claim() done, but with an > error return (so the caller will _not_ call "bd_release()", and the > block_device will forever stay exclusive). > > No? You're right. > Now, exactly why acpi stops working as a result, I don't know, but maybe > something else tries to get exclusive access to a swap partition, for > example, and now fails, causing some acpi sequence to not be set up? > Dunno. > > So I suspect it should be reverted, but maybe somebody can see exactly > what goes wrong here. Please revert the patch. I'll fix the wrong error handling. I'm not sure reverting the patch solves the ACPI problem because Michael's kernel seems not having any user of bd_claim_by_kobject. Thanks, -- Jun'ichi Nomura, NEC Corporation of America ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3) 2006-10-30 17:34 ` Jun'ichi Nomura @ 2006-10-30 18:16 ` Linus Torvalds 0 siblings, 0 replies; 152+ messages in thread From: Linus Torvalds @ 2006-10-30 18:16 UTC (permalink / raw) To: Jun'ichi Nomura Cc: Andrew Morton, len.brown, linux-pm, linux-acpi, Michael S. Tsirkin, Adrian Bunk, Martin Lorenz, Linux Kernel Mailing List On Mon, 30 Oct 2006, Jun'ichi Nomura wrote: > > Please revert the patch. I'll fix the wrong error handling. > > I'm not sure reverting the patch solves the ACPI problem > because Michael's kernel seems not having any user of > bd_claim_by_kobject. Yeah, doing a grep does seem to imply that there is no way that those changes could matter. Michael, can you double-check? I think Jun'ichi is right - in your kernel, according to the config posted on bugzilla, I don't think there should be a single caller of bd_claim_by_disk, since CONFIG_MD is disabled. So it does seem strange. But if you bisected to that patch, and it reliably does _not_ have problems with the patch reverted, maybe there is some strange preprocessor thing that makes "grep" not find the caller. Michael, you also reported: > Reset to d7dd8fd9557840162b724a8ac1366dd78a12dff seems to hide part of > the issue (I have ACPI after kernel build, but not after > suspend/resume). Both reverting this patch, and reset to the parent of > this patch seem to solve (or at least, hide) both problems for me (no > ACPI after suspend/resume and no ACPI after kernel build). (where that "d7dd8f.." is actually missing the initial "4" - I think you cut-and-pasted things incorrectly). So I wonder.. You still had ACPI working _after_ the kernel build even with that patch in place, and it seems that suspend/resume is the real issue. Martin Lorenz reports on the same bugzilla entry, and he only has problems with suspend/resume. I assume that "compile the kernel" just triggers some magic ACPI event (probably fan-related due to heat), and I wonder if the bisection faked you out because once you get "close enough" the differences are small enough that the kernel compile is quick and the heat event doesn't actually trigger? See what I'm saying? Maybe the act of bisecting itself changed the results, and then when you just revert the patch, you end up in the same situation: you only recompile a small part (you only recompile that particular file), and the problem doesn't occur, so you'd think that the revert "fixed" it. If it's heat-related, it should probably trigger by anything that does a lot of CPU (and perhaps disk) accesses, not just kernel builds. It might be good to try to find another test-case for it than a kernel recompile, one that doesn't depend on how much changed in the kernel.. Linus ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3) @ 2006-10-30 18:16 ` Linus Torvalds 0 siblings, 0 replies; 152+ messages in thread From: Linus Torvalds @ 2006-10-30 18:16 UTC (permalink / raw) To: Jun'ichi Nomura Cc: Michael S. Tsirkin, Martin Lorenz, Pavel Machek, Adrian Bunk, Andrew Morton, Linux Kernel Mailing List, len.brown, linux-acpi, linux-pm, Randy.Dunlap On Mon, 30 Oct 2006, Jun'ichi Nomura wrote: > > Please revert the patch. I'll fix the wrong error handling. > > I'm not sure reverting the patch solves the ACPI problem > because Michael's kernel seems not having any user of > bd_claim_by_kobject. Yeah, doing a grep does seem to imply that there is no way that those changes could matter. Michael, can you double-check? I think Jun'ichi is right - in your kernel, according to the config posted on bugzilla, I don't think there should be a single caller of bd_claim_by_disk, since CONFIG_MD is disabled. So it does seem strange. But if you bisected to that patch, and it reliably does _not_ have problems with the patch reverted, maybe there is some strange preprocessor thing that makes "grep" not find the caller. Michael, you also reported: > Reset to d7dd8fd9557840162b724a8ac1366dd78a12dff seems to hide part of > the issue (I have ACPI after kernel build, but not after > suspend/resume). Both reverting this patch, and reset to the parent of > this patch seem to solve (or at least, hide) both problems for me (no > ACPI after suspend/resume and no ACPI after kernel build). (where that "d7dd8f.." is actually missing the initial "4" - I think you cut-and-pasted things incorrectly). So I wonder.. You still had ACPI working _after_ the kernel build even with that patch in place, and it seems that suspend/resume is the real issue. Martin Lorenz reports on the same bugzilla entry, and he only has problems with suspend/resume. I assume that "compile the kernel" just triggers some magic ACPI event (probably fan-related due to heat), and I wonder if the bisection faked you out because once you get "close enough" the differences are small enough that the kernel compile is quick and the heat event doesn't actually trigger? See what I'm saying? Maybe the act of bisecting itself changed the results, and then when you just revert the patch, you end up in the same situation: you only recompile a small part (you only recompile that particular file), and the problem doesn't occur, so you'd think that the revert "fixed" it. If it's heat-related, it should probably trigger by anything that does a lot of CPU (and perhaps disk) accesses, not just kernel builds. It might be good to try to find another test-case for it than a kernel recompile, one that doesn't depend on how much changed in the kernel.. Linus ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3) 2006-10-30 18:16 ` Linus Torvalds (?) @ 2006-10-30 18:35 ` Adrian Bunk 2006-10-30 19:00 ` Michael S. Tsirkin ` (2 more replies) -1 siblings, 3 replies; 152+ messages in thread From: Adrian Bunk @ 2006-10-30 18:35 UTC (permalink / raw) To: Linus Torvalds Cc: Jun'ichi Nomura, Michael S. Tsirkin, Martin Lorenz, Pavel Machek, Andrew Morton, Linux Kernel Mailing List, len.brown, linux-acpi, linux-pm, Randy.Dunlap On Mon, Oct 30, 2006 at 10:16:34AM -0800, Linus Torvalds wrote: >... > I assume that "compile the kernel" just triggers some magic ACPI event > (probably fan-related due to heat), and I wonder if the bisection faked > you out because once you get "close enough" the differences are small > enough that the kernel compile is quick and the heat event doesn't > actually trigger? > > See what I'm saying? Maybe the act of bisecting itself changed the > results, and then when you just revert the patch, you end up in the same > situation: you only recompile a small part (you only recompile that > particular file), and the problem doesn't occur, so you'd think that the > revert "fixed" it. > > If it's heat-related, it should probably trigger by anything that does a > lot of CPU (and perhaps disk) accesses, not just kernel builds. It might > be good to try to find another test-case for it than a kernel recompile, > one that doesn't depend on how much changed in the kernel.. Martin's original bug report stated "now I loose ACPI events after suspend/resume. not every time, but roughly 3 out of 4 times." This seems to support your theory. But considering that two people have independently reported this as a 2.6.19-rc regression for similar hardware (Michael for a T60 and Martin for an X60), a problem in the kernel seems to be involved. Martin, Michael, can you send complete "dmesg -s 1000000" for both 2.6.18.1 and a non-working 2.6.19-rc kernel after resume? I don't have high hopes, but perhaps looking at the dmesg and/or diff'ing them might give a hint. > Linus cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3) 2006-10-30 18:35 ` Adrian Bunk @ 2006-10-30 19:00 ` Michael S. Tsirkin 2006-10-30 19:06 ` Hugh Dickins 2006-10-31 12:47 ` Martin Lorenz 2 siblings, 0 replies; 152+ messages in thread From: Michael S. Tsirkin @ 2006-10-30 19:00 UTC (permalink / raw) To: Adrian Bunk Cc: Linus Torvalds, Jun'ichi Nomura, Martin Lorenz, Pavel Machek, Andrew Morton, Linux Kernel Mailing List, len.brown, linux-acpi, linux-pm, Randy.Dunlap Quoting r. Adrian Bunk <bunk@stusta.de>: > Martin, Michael, can you send complete "dmesg -s 1000000" for both > 2.6.18.1 and a non-working 2.6.19-rc kernel after resume? > I don't have high hopes, but perhaps looking at the dmesg and/or > diff'ing them might give a hint. OK, I'll try to go back to this, just not today. -- MST ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3) 2006-10-30 18:35 ` Adrian Bunk 2006-10-30 19:00 ` Michael S. Tsirkin @ 2006-10-30 19:06 ` Hugh Dickins 2006-10-31 12:47 ` Martin Lorenz 2 siblings, 0 replies; 152+ messages in thread From: Hugh Dickins @ 2006-10-30 19:06 UTC (permalink / raw) To: Adrian Bunk Cc: Linus Torvalds, Jun'ichi Nomura, Michael S. Tsirkin, Martin Lorenz, Pavel Machek, Andrew Morton, Linux Kernel Mailing List, len.brown, linux-acpi, linux-pm, Randy.Dunlap On Mon, 30 Oct 2006, Adrian Bunk wrote: > > Martin's original bug report stated "now I loose ACPI events after > suspend/resume. not every time, but roughly 3 out of 4 times." > This seems to support your theory. > > But considering that two people have independently reported this as a > 2.6.19-rc regression for similar hardware (Michael for a T60 and Martin > for an X60), a problem in the kernel seems to be involved. Add me to the list, on a T43p. I believe it was happening in -rc1, but seems worse with -rc3 and current. But it's one of those things which doesn't happen if you just go to test it out, only when you need to suspend and resume for real. Hugh ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3) 2006-10-30 18:35 ` Adrian Bunk 2006-10-30 19:00 ` Michael S. Tsirkin 2006-10-30 19:06 ` Hugh Dickins @ 2006-10-31 12:47 ` Martin Lorenz 2 siblings, 0 replies; 152+ messages in thread From: Martin Lorenz @ 2006-10-31 12:47 UTC (permalink / raw) To: Adrian Bunk Cc: Linus Torvalds, Jun'ichi Nomura, Michael S. Tsirkin, Pavel Machek, Andrew Morton, Linux Kernel Mailing List, len.brown, linux-acpi, linux-pm, Randy.Dunlap On Mon, Oct 30, 2006 at 07:35:22PM +0100, Adrian Bunk wrote: > On Mon, Oct 30, 2006 at 10:16:34AM -0800, Linus Torvalds wrote: [...] > Martin, Michael, can you send complete "dmesg -s 1000000" for both > 2.6.18.1 and a non-working 2.6.19-rc kernel after resume? > I don't have high hopes, but perhaps looking at the dmesg and/or > diff'ing them might give a hint. > there are quite a few outputs from different kernels on my webpage www.lorenz.eu.org/~mlo/kernel/?C=M;O=D I hope I can go deeper into that tonight, but at the moment I can't promise anything. gruss mlo -- Dipl.-Ing. Martin Lorenz They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. Benjamin Franklin please encrypt your mail to me GnuPG key-ID: F1AAD37D get it here: http://blackhole.pca.dfn.de:11371/pks/lookup?op=get&search=0xF1AAD37D ICQ UIN: 33588107 ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3) 2006-10-30 18:16 ` Linus Torvalds (?) (?) @ 2006-10-30 18:58 ` Michael S. Tsirkin -1 siblings, 0 replies; 152+ messages in thread From: Michael S. Tsirkin @ 2006-10-30 18:58 UTC (permalink / raw) To: Linus Torvalds Cc: Jun'ichi Nomura, Martin Lorenz, Pavel Machek, Adrian Bunk, Andrew Morton, Linux Kernel Mailing List, len.brown, linux-acpi, linux-pm, Randy.Dunlap Quoting r. Linus Torvalds <torvalds@osdl.org>: > Subject: Re: 2.6.19-rc3: known unfixed regressions (v3) > > > > On Mon, 30 Oct 2006, Jun'ichi Nomura wrote: > > > > Please revert the patch. I'll fix the wrong error handling. > > > > I'm not sure reverting the patch solves the ACPI problem > > because Michael's kernel seems not having any user of > > bd_claim_by_kobject. > > Yeah, doing a grep does seem to imply that there is no way that those > changes could matter. > > Michael, can you double-check? I think Jun'ichi is right - in your kernel, > according to the config posted on bugzilla, I don't think there should be > a single caller of bd_claim_by_disk, since CONFIG_MD is disabled. I will, just maybe not today. > So it does seem strange. But if you bisected to that patch, and it > reliably does _not_ have problems with the patch reverted, maybe there is > some strange preprocessor thing that makes "grep" not find the caller. > > Michael, you also reported: > > > Reset to d7dd8fd9557840162b724a8ac1366dd78a12dff seems to hide part of > > the issue (I have ACPI after kernel build, but not after > > suspend/resume). Both reverting this patch, and reset to the parent of > > this patch seem to solve (or at least, hide) both problems for me (no > > ACPI after suspend/resume and no ACPI after kernel build). > > (where that "d7dd8f.." is actually missing the initial "4" - I think you > cut-and-pasted things incorrectly). Yes. > So I wonder.. You still had ACPI working _after_ the kernel build even > with that patch in place, and it seems that suspend/resume is the real > issue. Martin Lorenz reports on the same bugzilla entry, and he only has > problems with suspend/resume. > > I assume that "compile the kernel" just triggers some magic ACPI event > (probably fan-related due to heat), and I wonder if the bisection faked > you out because once you get "close enough" the differences are small > enough that the kernel compile is quick and the heat event doesn't > actually trigger? > > See what I'm saying? Maybe the act of bisecting itself changed the > results, and then when you just revert the patch, you end up in the same > situation: you only recompile a small part (you only recompile that > particular file), and the problem doesn't occur, so you'd think that the > revert "fixed" it. > > If it's heat-related, it should probably trigger by anything that does a > lot of CPU (and perhaps disk) accesses, not just kernel builds. It might > be good to try to find another test-case for it than a kernel recompile, > one that doesn't depend on how much changed in the kernel.. > > Linus > > Linus, I agree something fishy is going on, I'm just not sure how to debug. It kind of looks like some memory corruption, or something. I plan double-checking sometime later. 2 points I'd like to clarify: 1. When I git-bisected, I tested ACPI after suspend/resume, this is much faster to test but might be a separate issue. I really tested several times, and unless I repeated same mistake several times just switching between commit above and its parent made ACPI after resume work/not work. 2. When I test kernel compile, I do git clone -s ~/scm/linux-2.6 cd linux-2.6 make defconfig make -j 4 so the build I do in testing is repeatable. -- MST ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3) 2006-10-30 18:16 ` Linus Torvalds @ 2006-10-31 21:15 ` Michael S. Tsirkin -1 siblings, 0 replies; 152+ messages in thread From: Michael S. Tsirkin @ 2006-10-31 21:15 UTC (permalink / raw) To: Linus Torvalds Cc: Andrew Morton, len.brown, linux-pm, linux-acpi, Jun'ichi Nomura, Adrian Bunk, Martin Lorenz, Linux Kernel Mailing List Quoting r. Linus Torvalds <torvalds@osdl.org>: > Subject: Re: 2.6.19-rc3: known unfixed regressions (v3) > > > > On Mon, 30 Oct 2006, Jun'ichi Nomura wrote: > > > > Please revert the patch. I'll fix the wrong error handling. > > > > I'm not sure reverting the patch solves the ACPI problem > > because Michael's kernel seems not having any user of > > bd_claim_by_kobject. > > Yeah, doing a grep does seem to imply that there is no way that those > changes could matter. > > Michael, can you double-check? I think Jun'ichi is right - in your kernel, > according to the config posted on bugzilla, I don't think there should be > a single caller of bd_claim_by_disk, since CONFIG_MD is disabled. I double-checked, and of course you are right - the issues resurfaced after some more use, even with the patch reverted. I've written some scripts that do some compiles from scratch, and suspend/resume several times. Plan to try bi-secting with that and see what that will come up with. OTOH, from the discussion it seems just randomly pointing a finger at a patch has uncovered some bugs - so maybe we should do this a bit more :) -- MST ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc3: known unfixed regressions (v3) @ 2006-10-31 21:15 ` Michael S. Tsirkin 0 siblings, 0 replies; 152+ messages in thread From: Michael S. Tsirkin @ 2006-10-31 21:15 UTC (permalink / raw) To: Linus Torvalds Cc: Jun'ichi Nomura, Martin Lorenz, Pavel Machek, Adrian Bunk, Andrew Morton, Linux Kernel Mailing List, len.brown, linux-acpi, linux-pm, Randy.Dunlap Quoting r. Linus Torvalds <torvalds@osdl.org>: > Subject: Re: 2.6.19-rc3: known unfixed regressions (v3) > > > > On Mon, 30 Oct 2006, Jun'ichi Nomura wrote: > > > > Please revert the patch. I'll fix the wrong error handling. > > > > I'm not sure reverting the patch solves the ACPI problem > > because Michael's kernel seems not having any user of > > bd_claim_by_kobject. > > Yeah, doing a grep does seem to imply that there is no way that those > changes could matter. > > Michael, can you double-check? I think Jun'ichi is right - in your kernel, > according to the config posted on bugzilla, I don't think there should be > a single caller of bd_claim_by_disk, since CONFIG_MD is disabled. I double-checked, and of course you are right - the issues resurfaced after some more use, even with the patch reverted. I've written some scripts that do some compiles from scratch, and suspend/resume several times. Plan to try bi-secting with that and see what that will come up with. OTOH, from the discussion it seems just randomly pointing a finger at a patch has uncovered some bugs - so maybe we should do this a bit more :) -- MST ^ permalink raw reply [flat|nested] 152+ messages in thread
* 2.6.19-rc <-> ThinkPads 2006-10-30 13:56 ` Michael S. Tsirkin ` (2 preceding siblings ...) (?) @ 2006-11-01 3:01 ` Adrian Bunk 2006-11-01 3:15 ` Len Brown ` (2 more replies) -1 siblings, 3 replies; 152+ messages in thread From: Adrian Bunk @ 2006-11-01 3:01 UTC (permalink / raw) To: Hugh Dickins Cc: Michael S. Tsirkin, Pavel Machek, Linus Torvalds, Andrew Morton, Linux Kernel Mailing List, len.brown, linux-acpi, linux-pm, Martin Lorenz FYI: Subject : Thinkpad R50p: boot fail with (lapic && on_battery) References : http://lkml.org/lkml/2006/10/31/333 Submitter : Ernst Herzberg <earny@net4u.de> Status : submitter was asked to bisect It seems to be completely unrelated (except that it's also a ThinkPad), but it might be worth a try whether a (non-SMP) kernel without APIC support fixes the issues after resume. Hugh, your laptop seems to be a non-SMP laptop. Do you have APIC enabled, and if yes does disabling help? cu Adrian VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 19 EXTRAVERSION = -rc4 NAME=ThinkPad Killer ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads 2006-11-01 3:01 ` 2.6.19-rc <-> ThinkPads Adrian Bunk @ 2006-11-01 3:15 ` Len Brown 2006-11-01 16:36 ` Hugh Dickins 2006-11-04 3:49 ` 2.6.19-rc <-> ThinkPads, summary Adrian Bunk 2 siblings, 0 replies; 152+ messages in thread From: Len Brown @ 2006-11-01 3:15 UTC (permalink / raw) To: Adrian Bunk Cc: Andrew Morton, linux-acpi, linux-pm, Michael S. Tsirkin, Hugh Dickins, Linus Torvalds, Martin Lorenz, Linux Kernel Mailing List The BIOS disables the LAPIC for a reason. A couple of years ago Linux made the mistake of enabling the LAPIC that the BIOS disabled, and all hell broke loose. We fixed that bug about a year ago, but left "lapic" to force it on for those where forcing it to be enabled actually works (eg. some folks want the NMI profiling on their IOAPIC-less laptop) But if you force the lapic to be enabled, you are running the system in a mode not supported by the manufacturer and you are on your own. I don't see an indication that this is a bug. If it used to work and it is important to you, then run the old software where it used to work -- because chances are good that it worked by accident. -Len On Tuesday 31 October 2006 22:01, Adrian Bunk wrote: > FYI: > > Subject : Thinkpad R50p: boot fail with (lapic && on_battery) > References : http://lkml.org/lkml/2006/10/31/333 > Submitter : Ernst Herzberg <earny@net4u.de> > Status : submitter was asked to bisect > > It seems to be completely unrelated (except that it's also a ThinkPad), > but it might be worth a try whether a (non-SMP) kernel without APIC > support fixes the issues after resume. > > Hugh, your laptop seems to be a non-SMP laptop. > Do you have APIC enabled, and if yes does disabling help? > > cu > Adrian > > > VERSION = 2 > PATCHLEVEL = 6 > SUBLEVEL = 19 > EXTRAVERSION = -rc4 > NAME=ThinkPad Killer > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads @ 2006-11-01 3:15 ` Len Brown 0 siblings, 0 replies; 152+ messages in thread From: Len Brown @ 2006-11-01 3:15 UTC (permalink / raw) To: Adrian Bunk Cc: Hugh Dickins, Michael S. Tsirkin, Pavel Machek, Linus Torvalds, Andrew Morton, Linux Kernel Mailing List, linux-acpi, linux-pm, Martin Lorenz The BIOS disables the LAPIC for a reason. A couple of years ago Linux made the mistake of enabling the LAPIC that the BIOS disabled, and all hell broke loose. We fixed that bug about a year ago, but left "lapic" to force it on for those where forcing it to be enabled actually works (eg. some folks want the NMI profiling on their IOAPIC-less laptop) But if you force the lapic to be enabled, you are running the system in a mode not supported by the manufacturer and you are on your own. I don't see an indication that this is a bug. If it used to work and it is important to you, then run the old software where it used to work -- because chances are good that it worked by accident. -Len On Tuesday 31 October 2006 22:01, Adrian Bunk wrote: > FYI: > > Subject : Thinkpad R50p: boot fail with (lapic && on_battery) > References : http://lkml.org/lkml/2006/10/31/333 > Submitter : Ernst Herzberg <earny@net4u.de> > Status : submitter was asked to bisect > > It seems to be completely unrelated (except that it's also a ThinkPad), > but it might be worth a try whether a (non-SMP) kernel without APIC > support fixes the issues after resume. > > Hugh, your laptop seems to be a non-SMP laptop. > Do you have APIC enabled, and if yes does disabling help? > > cu > Adrian > > > VERSION = 2 > PATCHLEVEL = 6 > SUBLEVEL = 19 > EXTRAVERSION = -rc4 > NAME=ThinkPad Killer > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads 2006-11-01 3:15 ` Len Brown (?) @ 2006-11-01 5:11 ` Ernst Herzberg 2006-11-01 5:26 ` Linus Torvalds -1 siblings, 1 reply; 152+ messages in thread From: Ernst Herzberg @ 2006-11-01 5:11 UTC (permalink / raw) To: Len Brown Cc: Adrian Bunk, Hugh Dickins, Michael S. Tsirkin, Pavel Machek, Linus Torvalds, Andrew Morton, Linux Kernel Mailing List, linux-acpi, linux-pm, Martin Lorenz On Wednesday 01 November 2006 04:15, Len Brown wrote: > The BIOS disables the LAPIC for a reason. > A couple of years ago Linux made the mistake of enabling the LAPIC > that the BIOS disabled, and all hell broke loose. > We fixed that bug about a year ago, but left "lapic" > to force it on for those where forcing it to be enabled actually > works (eg. some folks want the NMI profiling on their IOAPIC-less laptop) > > But if you force the lapic to be enabled, you are running the system > in a mode not supported by the manufacturer and you are on your own. > > I don't see an indication that this is a bug. > If it used to work and it is important to you, > then run the old software where it used to work -- > because chances are good that it worked by accident. Maybe. But why does it boot with AC connected and lapic enabled, bot not if AC is disconnected and lapic enabled? If have no problem to run this laptop without lapic, i don't relly need it. But i wondering that this happens only if the machine runs (by accident:) on battery. still bisecting, will report the result. <earny> ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads 2006-11-01 5:11 ` Ernst Herzberg @ 2006-11-01 5:26 ` Linus Torvalds 0 siblings, 0 replies; 152+ messages in thread From: Linus Torvalds @ 2006-11-01 5:26 UTC (permalink / raw) To: Ernst Herzberg Cc: Andrew Morton, linux-acpi, linux-pm, Michael S. Tsirkin, Hugh Dickins, Linux Kernel Mailing List, Martin Lorenz, Adrian Bunk On Wed, 1 Nov 2006, Ernst Herzberg wrote: > > still bisecting, will report the result. Figuring out what caused an apparent change of behaviour is definitely a good idea - it might give us some clue to what really is going on. (Or it might not. Sometimes the patch that triggers changes really doesn't seem to have anything to do with anything, and it literally was just a latent bug that just happened to be exposed by something that had nothing to do with anything at all but perhaps timing. But that's pretty rare in the end. It happens, but it's definitely not the common case at all, and I think it's great that you're bisecting even if there is a possibility that we'll be left with a big "Huh? Whaa?" as the end result ;^) Linus ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads @ 2006-11-01 5:26 ` Linus Torvalds 0 siblings, 0 replies; 152+ messages in thread From: Linus Torvalds @ 2006-11-01 5:26 UTC (permalink / raw) To: Ernst Herzberg Cc: Len Brown, Adrian Bunk, Hugh Dickins, Michael S. Tsirkin, Pavel Machek, Andrew Morton, Linux Kernel Mailing List, linux-acpi, linux-pm, Martin Lorenz On Wed, 1 Nov 2006, Ernst Herzberg wrote: > > still bisecting, will report the result. Figuring out what caused an apparent change of behaviour is definitely a good idea - it might give us some clue to what really is going on. (Or it might not. Sometimes the patch that triggers changes really doesn't seem to have anything to do with anything, and it literally was just a latent bug that just happened to be exposed by something that had nothing to do with anything at all but perhaps timing. But that's pretty rare in the end. It happens, but it's definitely not the common case at all, and I think it's great that you're bisecting even if there is a possibility that we'll be left with a big "Huh? Whaa?" as the end result ;^) Linus ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads 2006-11-01 5:26 ` Linus Torvalds @ 2006-11-01 5:54 ` Michael S. Tsirkin -1 siblings, 0 replies; 152+ messages in thread From: Michael S. Tsirkin @ 2006-11-01 5:54 UTC (permalink / raw) To: Linus Torvalds Cc: Andrew Morton, linux-pm, Ernst Herzberg, Andi Kleen, Linux Kernel Mailing List, linux-acpi, Hugh Dickins, Adrian Bunk, Martin Lorenz Quoting r. Linus Torvalds <torvalds@osdl.org>: > Subject: Re: 2.6.19-rc <-> ThinkPads > > > > On Wed, 1 Nov 2006, Ernst Herzberg wrote: > > > > still bisecting, will report the result. > > Figuring out what caused an apparent change of behaviour is definitely a > good idea - it might give us some clue to what really is going on. I've been bisecting ACPI/suspend thinkpad issue myself and I seem to get eea0e11c1f0d6ef89e64182b2f1223a4ca2b74a2 good, cf4c6a2f27f5db810b69dcb1da7f194489e8ff88 bad. At least this makes some sense since the log speaks about suspend. Problem is, ACPI issues are in rare cases going away for a while for me so this needs more testing before I can say for sure about the good part - I already had one false negative. What I plan to do is using eea0e11c1f0d6ef89e64182b2f1223a4ca2b74a2 for a couple of days and see how this works out. -- MST ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads @ 2006-11-01 5:54 ` Michael S. Tsirkin 0 siblings, 0 replies; 152+ messages in thread From: Michael S. Tsirkin @ 2006-11-01 5:54 UTC (permalink / raw) To: Linus Torvalds Cc: Ernst Herzberg, Len Brown, Adrian Bunk, Hugh Dickins, Pavel Machek, Andrew Morton, Linux Kernel Mailing List, linux-acpi, linux-pm, Martin Lorenz, Andi Kleen Quoting r. Linus Torvalds <torvalds@osdl.org>: > Subject: Re: 2.6.19-rc <-> ThinkPads > > > > On Wed, 1 Nov 2006, Ernst Herzberg wrote: > > > > still bisecting, will report the result. > > Figuring out what caused an apparent change of behaviour is definitely a > good idea - it might give us some clue to what really is going on. I've been bisecting ACPI/suspend thinkpad issue myself and I seem to get eea0e11c1f0d6ef89e64182b2f1223a4ca2b74a2 good, cf4c6a2f27f5db810b69dcb1da7f194489e8ff88 bad. At least this makes some sense since the log speaks about suspend. Problem is, ACPI issues are in rare cases going away for a while for me so this needs more testing before I can say for sure about the good part - I already had one false negative. What I plan to do is using eea0e11c1f0d6ef89e64182b2f1223a4ca2b74a2 for a couple of days and see how this works out. -- MST ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads 2006-11-01 5:54 ` Michael S. Tsirkin @ 2006-11-01 6:16 ` Linus Torvalds -1 siblings, 0 replies; 152+ messages in thread From: Linus Torvalds @ 2006-11-01 6:16 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Andrew Morton, linux-pm, Ernst Herzberg, Andi Kleen, Linux Kernel Mailing List, linux-acpi, Hugh Dickins, Adrian Bunk, Martin Lorenz On Wed, 1 Nov 2006, Michael S. Tsirkin wrote: > > I've been bisecting ACPI/suspend thinkpad issue myself and I seem to get > eea0e11c1f0d6ef89e64182b2f1223a4ca2b74a2 good, > cf4c6a2f27f5db810b69dcb1da7f194489e8ff88 bad. Very interesting.. That commit cf4c6a2f on the face of it looks like an obvious cleanup, but looking closer, it actually changes the order of the apic writes in many cases (high word first -> low word first). It also does something else that looks really really wrong: it turns an atomic "update ioapic and set irq-info" into two separate events, where interrupts can happen in between. Same goes for resume (instead of atomically changing all entries with the ioapic lock held, it now does them individually, and locks them individually). I wonder if the order matters more, though. Andi? We _used_ to write the high word first, and I think the order matters. The low word contains the enable bit, for example, so when enabling an interrupt, you should write the low word last, when you disable it you should write the low word first. And that's exactly what we _used_ to do, and it's what that particular commit totally and utterly _broke_. I think that commit should either be reverted, or the code should be fixed to do the writes in the proper order. I suspect reverting it is the right thing to do - the patch only introduces bugs, an doesn't actually _fix_ anything, it just "cleans things up". Andi, you need to be a hell of a lot more careful! Apparently x86-64 is also totally broken in this regard, because somebody didn't realize that the ordering _matters_. Linus ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads @ 2006-11-01 6:16 ` Linus Torvalds 0 siblings, 0 replies; 152+ messages in thread From: Linus Torvalds @ 2006-11-01 6:16 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Ernst Herzberg, Len Brown, Adrian Bunk, Hugh Dickins, Pavel Machek, Andrew Morton, Linux Kernel Mailing List, linux-acpi, linux-pm, Martin Lorenz, Andi Kleen On Wed, 1 Nov 2006, Michael S. Tsirkin wrote: > > I've been bisecting ACPI/suspend thinkpad issue myself and I seem to get > eea0e11c1f0d6ef89e64182b2f1223a4ca2b74a2 good, > cf4c6a2f27f5db810b69dcb1da7f194489e8ff88 bad. Very interesting.. That commit cf4c6a2f on the face of it looks like an obvious cleanup, but looking closer, it actually changes the order of the apic writes in many cases (high word first -> low word first). It also does something else that looks really really wrong: it turns an atomic "update ioapic and set irq-info" into two separate events, where interrupts can happen in between. Same goes for resume (instead of atomically changing all entries with the ioapic lock held, it now does them individually, and locks them individually). I wonder if the order matters more, though. Andi? We _used_ to write the high word first, and I think the order matters. The low word contains the enable bit, for example, so when enabling an interrupt, you should write the low word last, when you disable it you should write the low word first. And that's exactly what we _used_ to do, and it's what that particular commit totally and utterly _broke_. I think that commit should either be reverted, or the code should be fixed to do the writes in the proper order. I suspect reverting it is the right thing to do - the patch only introduces bugs, an doesn't actually _fix_ anything, it just "cleans things up". Andi, you need to be a hell of a lot more careful! Apparently x86-64 is also totally broken in this regard, because somebody didn't realize that the ordering _matters_. Linus ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads 2006-11-01 6:16 ` Linus Torvalds (?) @ 2006-11-01 17:25 ` Andi Kleen 2006-11-01 18:12 ` Michael S. Tsirkin 2006-11-01 18:25 ` Linus Torvalds -1 siblings, 2 replies; 152+ messages in thread From: Andi Kleen @ 2006-11-01 17:25 UTC (permalink / raw) To: Linus Torvalds Cc: Michael S. Tsirkin, Ernst Herzberg, Len Brown, Adrian Bunk, Hugh Dickins, Pavel Machek, Andrew Morton, Linux Kernel Mailing List, linux-acpi, linux-pm, Martin Lorenz > I suspect reverting it is the right thing to do - the patch only > introduces bugs, an doesn't actually _fix_ anything, it just "cleans > things up". Ok please revert the i386 patch for now then if it fixes the ThinkPads. The x86-64 version should be probably fixed too, but doesn't cleanly. I will send you later a patch to fix this there properly. -Andi ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads 2006-11-01 17:25 ` Andi Kleen @ 2006-11-01 18:12 ` Michael S. Tsirkin 2006-11-01 18:25 ` Linus Torvalds 1 sibling, 0 replies; 152+ messages in thread From: Michael S. Tsirkin @ 2006-11-01 18:12 UTC (permalink / raw) To: Andi Kleen Cc: Andrew Morton, linux-pm, Ernst Herzberg, Linux Kernel Mailing List, linux-acpi, Linus Torvalds, Hugh Dickins, Adrian Bunk, Martin Lorenz Quoting r. Andi Kleen <ak@suse.de>: > Subject: Re: 2.6.19-rc <-> ThinkPads > > > > I suspect reverting it is the right thing to do - the patch only > > introduces bugs, an doesn't actually _fix_ anything, it just "cleans > > things up". > > Ok please revert the i386 patch for now then if it fixes the ThinkPads. > The x86-64 version should be probably fixed too, but doesn't cleanly. I will > send you later a patch to fix this there properly. Could you sent the patch so I can test it, pls? git revert creates conflicts. -- MST ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads @ 2006-11-01 18:12 ` Michael S. Tsirkin 0 siblings, 0 replies; 152+ messages in thread From: Michael S. Tsirkin @ 2006-11-01 18:12 UTC (permalink / raw) To: Andi Kleen Cc: Linus Torvalds, Ernst Herzberg, Len Brown, Adrian Bunk, Hugh Dickins, Pavel Machek, Andrew Morton, Linux Kernel Mailing List, linux-acpi, linux-pm, Martin Lorenz Quoting r. Andi Kleen <ak@suse.de>: > Subject: Re: 2.6.19-rc <-> ThinkPads > > > > I suspect reverting it is the right thing to do - the patch only > > introduces bugs, an doesn't actually _fix_ anything, it just "cleans > > things up". > > Ok please revert the i386 patch for now then if it fixes the ThinkPads. > The x86-64 version should be probably fixed too, but doesn't cleanly. I will > send you later a patch to fix this there properly. Could you sent the patch so I can test it, pls? git revert creates conflicts. -- MST ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads 2006-11-01 17:25 ` Andi Kleen @ 2006-11-01 18:25 ` Linus Torvalds 2006-11-01 18:25 ` Linus Torvalds 1 sibling, 0 replies; 152+ messages in thread From: Linus Torvalds @ 2006-11-01 18:25 UTC (permalink / raw) To: Andi Kleen Cc: Andrew Morton, linux-pm, Ernst Herzberg, Linux Kernel Mailing List, Adrian Bunk, linux-acpi, Michael S. Tsirkin, Hugh Dickins, Martin Lorenz On Wed, 1 Nov 2006, Andi Kleen wrote: > > Ok please revert the i386 patch for now then if it fixes the ThinkPads. > The x86-64 version should be probably fixed too, but doesn't cleanly. I will > send you later a patch to fix this there properly. Actually, I should have just fixed the ordering. I did some cleanups too, but those are unrelated (except in the sense that I wanted to look at the assembly code, and the cleanups made the code generation at least half-way sane!) I've pushed out the changes, but here is the part that may or may not matter for anybody who wants to test it if they don't use git or if it hasn't mirrored out yet. Michael? Martin? Andi: I think the patches should work pretty much as-is for x86-64 too, since all the issues would seem to be similar. I'm not entirely happy with "ioapic_write_entry()" now either (if we change an entry that was already unmasked, we should probably mask it first by writing the low word with the mask bit set, then write the high word, and then write the low word again), but - this makes us match the ordering we _used_ to have, so if the cleanup broke things for people, this should unbreak it, and at least not be any worse than it used to be. - when we write new unmasked entries, they all _should_ have been masked before, so hopefully the "change a unmasked entry while it's unmasked" case doesn't actually ever happen. But I didn't actually _check_. Somebody should look into that case. Does anybody feel like they want to learn more about the IO-APIC? Halloween is over and gone, but if you want to scare small children _next_ year, telling them about the IO-APIC is likely a good strategy. Linus --- commit f9dadfa71bc594df09044da61d1c72701121d802 Author: Linus Torvalds <torvalds@macmini.osdl.org> Date: Wed Nov 1 10:05:35 2006 -0800 i386: write IO APIC irq routing entries in correct order Since the "mask" bit is in the low word, when we write a new entry, we need to write the high word first, before we potentially unmask it. The exception is when we actually want to mask the interrupt, in which case we want to write the low word first to make sure that the high word doesn't change while the interrupt routing is still active. Signed-off-by: Linus Torvalds <torvalds@osdl.org> diff --git a/arch/i386/kernel/io_apic.c b/arch/i386/kernel/io_apic.c index eb10bd5..507983c 100644 --- a/arch/i386/kernel/io_apic.c +++ b/arch/i386/kernel/io_apic.c @@ -147,12 +147,34 @@ static struct IO_APIC_route_entry ioapic return eu.entry; } +/* + * When we write a new IO APIC routing entry, we need to write the high + * word first! If the mask bit in the low word is clear, we will enable + * the interrupt, and we need to make sure the entry is fully populated + * before that happens. + */ static void ioapic_write_entry(int apic, int pin, struct IO_APIC_route_entry e) { unsigned long flags; union entry_union eu; eu.entry = e; spin_lock_irqsave(&ioapic_lock, flags); + io_apic_write(apic, 0x11 + 2*pin, eu.w2); + io_apic_write(apic, 0x10 + 2*pin, eu.w1); + spin_unlock_irqrestore(&ioapic_lock, flags); +} + +/* + * When we mask an IO APIC routing entry, we need to write the low + * word first, in order to set the mask bit before we change the + * high bits! + */ +static void ioapic_mask_entry(int apic, int pin) +{ + unsigned long flags; + union entry_union eu = { .entry.mask = 1 }; + + spin_lock_irqsave(&ioapic_lock, flags); io_apic_write(apic, 0x10 + 2*pin, eu.w1); io_apic_write(apic, 0x11 + 2*pin, eu.w2); spin_unlock_irqrestore(&ioapic_lock, flags); @@ -274,9 +296,7 @@ static void clear_IO_APIC_pin(unsigned i /* * Disable it in the IO-APIC irq-routing table: */ - memset(&entry, 0, sizeof(entry)); - entry.mask = 1; - ioapic_write_entry(apic, pin, entry); + ioapic_mask_entry(apic, pin); } static void clear_IO_APIC (void) ^ permalink raw reply related [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads @ 2006-11-01 18:25 ` Linus Torvalds 0 siblings, 0 replies; 152+ messages in thread From: Linus Torvalds @ 2006-11-01 18:25 UTC (permalink / raw) To: Andi Kleen Cc: Michael S. Tsirkin, Ernst Herzberg, Len Brown, Adrian Bunk, Hugh Dickins, Pavel Machek, Andrew Morton, Linux Kernel Mailing List, linux-acpi, linux-pm, Martin Lorenz On Wed, 1 Nov 2006, Andi Kleen wrote: > > Ok please revert the i386 patch for now then if it fixes the ThinkPads. > The x86-64 version should be probably fixed too, but doesn't cleanly. I will > send you later a patch to fix this there properly. Actually, I should have just fixed the ordering. I did some cleanups too, but those are unrelated (except in the sense that I wanted to look at the assembly code, and the cleanups made the code generation at least half-way sane!) I've pushed out the changes, but here is the part that may or may not matter for anybody who wants to test it if they don't use git or if it hasn't mirrored out yet. Michael? Martin? Andi: I think the patches should work pretty much as-is for x86-64 too, since all the issues would seem to be similar. I'm not entirely happy with "ioapic_write_entry()" now either (if we change an entry that was already unmasked, we should probably mask it first by writing the low word with the mask bit set, then write the high word, and then write the low word again), but - this makes us match the ordering we _used_ to have, so if the cleanup broke things for people, this should unbreak it, and at least not be any worse than it used to be. - when we write new unmasked entries, they all _should_ have been masked before, so hopefully the "change a unmasked entry while it's unmasked" case doesn't actually ever happen. But I didn't actually _check_. Somebody should look into that case. Does anybody feel like they want to learn more about the IO-APIC? Halloween is over and gone, but if you want to scare small children _next_ year, telling them about the IO-APIC is likely a good strategy. Linus --- commit f9dadfa71bc594df09044da61d1c72701121d802 Author: Linus Torvalds <torvalds@macmini.osdl.org> Date: Wed Nov 1 10:05:35 2006 -0800 i386: write IO APIC irq routing entries in correct order Since the "mask" bit is in the low word, when we write a new entry, we need to write the high word first, before we potentially unmask it. The exception is when we actually want to mask the interrupt, in which case we want to write the low word first to make sure that the high word doesn't change while the interrupt routing is still active. Signed-off-by: Linus Torvalds <torvalds@osdl.org> diff --git a/arch/i386/kernel/io_apic.c b/arch/i386/kernel/io_apic.c index eb10bd5..507983c 100644 --- a/arch/i386/kernel/io_apic.c +++ b/arch/i386/kernel/io_apic.c @@ -147,12 +147,34 @@ static struct IO_APIC_route_entry ioapic return eu.entry; } +/* + * When we write a new IO APIC routing entry, we need to write the high + * word first! If the mask bit in the low word is clear, we will enable + * the interrupt, and we need to make sure the entry is fully populated + * before that happens. + */ static void ioapic_write_entry(int apic, int pin, struct IO_APIC_route_entry e) { unsigned long flags; union entry_union eu; eu.entry = e; spin_lock_irqsave(&ioapic_lock, flags); + io_apic_write(apic, 0x11 + 2*pin, eu.w2); + io_apic_write(apic, 0x10 + 2*pin, eu.w1); + spin_unlock_irqrestore(&ioapic_lock, flags); +} + +/* + * When we mask an IO APIC routing entry, we need to write the low + * word first, in order to set the mask bit before we change the + * high bits! + */ +static void ioapic_mask_entry(int apic, int pin) +{ + unsigned long flags; + union entry_union eu = { .entry.mask = 1 }; + + spin_lock_irqsave(&ioapic_lock, flags); io_apic_write(apic, 0x10 + 2*pin, eu.w1); io_apic_write(apic, 0x11 + 2*pin, eu.w2); spin_unlock_irqrestore(&ioapic_lock, flags); @@ -274,9 +296,7 @@ static void clear_IO_APIC_pin(unsigned i /* * Disable it in the IO-APIC irq-routing table: */ - memset(&entry, 0, sizeof(entry)); - entry.mask = 1; - ioapic_write_entry(apic, pin, entry); + ioapic_mask_entry(apic, pin); } static void clear_IO_APIC (void) ^ permalink raw reply related [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads 2006-11-01 18:25 ` Linus Torvalds @ 2006-11-01 19:33 ` Michael S. Tsirkin -1 siblings, 0 replies; 152+ messages in thread From: Michael S. Tsirkin @ 2006-11-01 19:33 UTC (permalink / raw) To: Linus Torvalds Cc: Andrew Morton, linux-pm, Ernst Herzberg, Andi Kleen, Linux Kernel Mailing List, linux-acpi, Hugh Dickins, Adrian Bunk, Martin Lorenz Quoting r. Linus Torvalds <torvalds@osdl.org>: > Subject: Re: 2.6.19-rc <-> ThinkPads > > > > On Wed, 1 Nov 2006, Andi Kleen wrote: > > > > Ok please revert the i386 patch for now then if it fixes the ThinkPads. > > The x86-64 version should be probably fixed too, but doesn't cleanly. I will > > send you later a patch to fix this there properly. > > Actually, I should have just fixed the ordering. I did some cleanups too, > but those are unrelated (except in the sense that I wanted to look at the > assembly code, and the cleanups made the code generation at least half-way > sane!) > > I've pushed out the changes, but here is the part that may or may not > matter for anybody who wants to test it if they don't use git or if it > hasn't mirrored out yet. Michael? Martin? I pulled the latest git, and seems to work for me, thanks. This still could be a false negative (happened already) so I'll continue using this, and will post the results. > Andi: I think the patches should work pretty much as-is for x86-64 too, > since all the issues would seem to be similar. > > I'm not entirely happy with "ioapic_write_entry()" now either (if we > change an entry that was already unmasked, we should probably mask it > first by writing the low word with the mask bit set, then write the high > word, and then write the low word again), but > > - this makes us match the ordering we _used_ to have, so if the cleanup > broke things for people, this should unbreak it, and at least not be > any worse than it used to be. > > - when we write new unmasked entries, they all _should_ have been masked > before, so hopefully the "change a unmasked entry while it's unmasked" > case doesn't actually ever happen. But I didn't actually _check_. > > Somebody should look into that case. Does anybody feel like they want to > learn more about the IO-APIC? Halloween is over and gone, but if you want > to scare small children _next_ year, telling them about the IO-APIC is > likely a good strategy. > > Linus Hmm, sounds interesting :) Is this a good place to start (I'm feeling lucky hit for IO-APIC)? http://www.intel.com/design/chipsets/datashts/290566.htm -- MST ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads @ 2006-11-01 19:33 ` Michael S. Tsirkin 0 siblings, 0 replies; 152+ messages in thread From: Michael S. Tsirkin @ 2006-11-01 19:33 UTC (permalink / raw) To: Linus Torvalds Cc: Andi Kleen, Ernst Herzberg, Len Brown, Adrian Bunk, Hugh Dickins, Pavel Machek, Andrew Morton, Linux Kernel Mailing List, linux-acpi, linux-pm, Martin Lorenz Quoting r. Linus Torvalds <torvalds@osdl.org>: > Subject: Re: 2.6.19-rc <-> ThinkPads > > > > On Wed, 1 Nov 2006, Andi Kleen wrote: > > > > Ok please revert the i386 patch for now then if it fixes the ThinkPads. > > The x86-64 version should be probably fixed too, but doesn't cleanly. I will > > send you later a patch to fix this there properly. > > Actually, I should have just fixed the ordering. I did some cleanups too, > but those are unrelated (except in the sense that I wanted to look at the > assembly code, and the cleanups made the code generation at least half-way > sane!) > > I've pushed out the changes, but here is the part that may or may not > matter for anybody who wants to test it if they don't use git or if it > hasn't mirrored out yet. Michael? Martin? I pulled the latest git, and seems to work for me, thanks. This still could be a false negative (happened already) so I'll continue using this, and will post the results. > Andi: I think the patches should work pretty much as-is for x86-64 too, > since all the issues would seem to be similar. > > I'm not entirely happy with "ioapic_write_entry()" now either (if we > change an entry that was already unmasked, we should probably mask it > first by writing the low word with the mask bit set, then write the high > word, and then write the low word again), but > > - this makes us match the ordering we _used_ to have, so if the cleanup > broke things for people, this should unbreak it, and at least not be > any worse than it used to be. > > - when we write new unmasked entries, they all _should_ have been masked > before, so hopefully the "change a unmasked entry while it's unmasked" > case doesn't actually ever happen. But I didn't actually _check_. > > Somebody should look into that case. Does anybody feel like they want to > learn more about the IO-APIC? Halloween is over and gone, but if you want > to scare small children _next_ year, telling them about the IO-APIC is > likely a good strategy. > > Linus Hmm, sounds interesting :) Is this a good place to start (I'm feeling lucky hit for IO-APIC)? http://www.intel.com/design/chipsets/datashts/290566.htm -- MST ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads 2006-11-01 19:33 ` Michael S. Tsirkin @ 2006-11-01 19:44 ` Linus Torvalds -1 siblings, 0 replies; 152+ messages in thread From: Linus Torvalds @ 2006-11-01 19:44 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Andrew Morton, linux-pm, Ernst Herzberg, Andi Kleen, Linux Kernel Mailing List, linux-acpi, Hugh Dickins, Adrian Bunk, Martin Lorenz On Wed, 1 Nov 2006, Michael S. Tsirkin wrote: > > I've pushed out the changes, but here is the part that may or may not > > matter for anybody who wants to test it if they don't use git or if it > > hasn't mirrored out yet. Michael? Martin? > > I pulled the latest git, and seems to work for me, thanks. > This still could be a false negative (happened already) so I'll > continue using this, and will post the results. Ok, thanks. > > Somebody should look into that case. Does anybody feel like they want to > > learn more about the IO-APIC? Halloween is over and gone, but if you want > > to scare small children _next_ year, telling them about the IO-APIC is > > likely a good strategy. > > Hmm, sounds interesting :) > Is this a good place to start (I'm feeling lucky hit for IO-APIC)? > http://www.intel.com/design/chipsets/datashts/290566.htm Yeah, that's the datasheet. Note that a lot of the IO-APIC complexity is not so much in the programming interfaces themselves, but in keeping track of how the heck the thing is connected (ie ExtINT vs SCI vs "normal apic interrupt" etc). Linus ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads @ 2006-11-01 19:44 ` Linus Torvalds 0 siblings, 0 replies; 152+ messages in thread From: Linus Torvalds @ 2006-11-01 19:44 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Andi Kleen, Ernst Herzberg, Len Brown, Adrian Bunk, Hugh Dickins, Pavel Machek, Andrew Morton, Linux Kernel Mailing List, linux-acpi, linux-pm, Martin Lorenz On Wed, 1 Nov 2006, Michael S. Tsirkin wrote: > > I've pushed out the changes, but here is the part that may or may not > > matter for anybody who wants to test it if they don't use git or if it > > hasn't mirrored out yet. Michael? Martin? > > I pulled the latest git, and seems to work for me, thanks. > This still could be a false negative (happened already) so I'll > continue using this, and will post the results. Ok, thanks. > > Somebody should look into that case. Does anybody feel like they want to > > learn more about the IO-APIC? Halloween is over and gone, but if you want > > to scare small children _next_ year, telling them about the IO-APIC is > > likely a good strategy. > > Hmm, sounds interesting :) > Is this a good place to start (I'm feeling lucky hit for IO-APIC)? > http://www.intel.com/design/chipsets/datashts/290566.htm Yeah, that's the datasheet. Note that a lot of the IO-APIC complexity is not so much in the programming interfaces themselves, but in keeping track of how the heck the thing is connected (ie ExtINT vs SCI vs "normal apic interrupt" etc). Linus ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads 2006-11-01 18:25 ` Linus Torvalds (?) (?) @ 2006-11-01 19:34 ` Andi Kleen 2006-11-01 19:52 ` Linus Torvalds -1 siblings, 1 reply; 152+ messages in thread From: Andi Kleen @ 2006-11-01 19:34 UTC (permalink / raw) To: Linus Torvalds Cc: Michael S. Tsirkin, Ernst Herzberg, Len Brown, Adrian Bunk, Hugh Dickins, Pavel Machek, Andrew Morton, Linux Kernel Mailing List, linux-acpi, linux-pm, Martin Lorenz On Wednesday 01 November 2006 19:25, Linus Torvalds wrote: > > On Wed, 1 Nov 2006, Andi Kleen wrote: > > > > Ok please revert the i386 patch for now then if it fixes the ThinkPads. > > The x86-64 version should be probably fixed too, but doesn't cleanly. I will > > send you later a patch to fix this there properly. > > Actually, I should have just fixed the ordering. I did some cleanups too, > but those are unrelated (except in the sense that I wanted to look at the > assembly code, and the cleanups made the code generation at least half-way > sane!) Thanks. Some of them are still different than the old code now, but that's probably ok. But the irq race you pointed out is still there (unless you fixed it in a differnet patch) I don't know if it makes a difference, but here is a patch to fix it. -Andi Fix race in IO-APIC routing entry setup. Interrupt could happen between setting the IO-APIC entry and setting its interrupt data. Pointed out by Linus. Signed-off-by: Andi Kleen <ak@suse.de> Index: linux/arch/i386/kernel/io_apic.c =================================================================== --- linux.orig/arch/i386/kernel/io_apic.c +++ linux/arch/i386/kernel/io_apic.c @@ -1298,10 +1298,12 @@ static void __init setup_IO_APIC_irqs(vo if (!apic && (irq < 16)) disable_8259A_irq(irq); } + local_irq_save(flags); ioapic_write_entry(apic, pin, entry); - spin_lock_irqsave(&ioapic_lock, flags); + spin_lock(&ioapic_lock); set_native_irq_info(irq, TARGET_CPUS); - spin_unlock_irqrestore(&ioapic_lock, flags); + spin_unlock(&ioapic_lock); + local_irq_restore(flags); } } ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads 2006-11-01 19:34 ` Andi Kleen @ 2006-11-01 19:52 ` Linus Torvalds 0 siblings, 0 replies; 152+ messages in thread From: Linus Torvalds @ 2006-11-01 19:52 UTC (permalink / raw) To: Andi Kleen Cc: Andrew Morton, linux-pm, Ernst Herzberg, Linux Kernel Mailing List, Adrian Bunk, linux-acpi, Michael S. Tsirkin, Hugh Dickins, Martin Lorenz On Wed, 1 Nov 2006, Andi Kleen wrote: > > Fix race in IO-APIC routing entry setup. > > Interrupt could happen between setting the IO-APIC entry > and setting its interrupt data. This doesn't fix anything at all. The interrupt can come in on another CPU, and if we end up having an affinity change due to that, we then have "set_ioapic_affinity_irq()" called on that other irq, and it might get to mess with the cpumask because we dropped the ioapic_lock. In other words, the problem is not that interrupts were re-enabled, the problem is literally that the locking is _wrong_. It's a small window, but we simply should not release the ioapic_lock in between setting the routing and doing the "set_native_irq_info()" call. So I think doing the locking inside "ioapic_write_entry()" is simply fundamentally wrong. When you did the cleanup, your commit message talked about how it might add a few more lock/unlock things: In a few cases the IO APIC lock is taken more often now, but this isn't a problem because it's all initialization/shutdown only slow path code. but the point is, this is not about "performance". It's about _correctness_. Linus ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads @ 2006-11-01 19:52 ` Linus Torvalds 0 siblings, 0 replies; 152+ messages in thread From: Linus Torvalds @ 2006-11-01 19:52 UTC (permalink / raw) To: Andi Kleen Cc: Michael S. Tsirkin, Ernst Herzberg, Len Brown, Adrian Bunk, Hugh Dickins, Pavel Machek, Andrew Morton, Linux Kernel Mailing List, linux-acpi, linux-pm, Martin Lorenz On Wed, 1 Nov 2006, Andi Kleen wrote: > > Fix race in IO-APIC routing entry setup. > > Interrupt could happen between setting the IO-APIC entry > and setting its interrupt data. This doesn't fix anything at all. The interrupt can come in on another CPU, and if we end up having an affinity change due to that, we then have "set_ioapic_affinity_irq()" called on that other irq, and it might get to mess with the cpumask because we dropped the ioapic_lock. In other words, the problem is not that interrupts were re-enabled, the problem is literally that the locking is _wrong_. It's a small window, but we simply should not release the ioapic_lock in between setting the routing and doing the "set_native_irq_info()" call. So I think doing the locking inside "ioapic_write_entry()" is simply fundamentally wrong. When you did the cleanup, your commit message talked about how it might add a few more lock/unlock things: In a few cases the IO APIC lock is taken more often now, but this isn't a problem because it's all initialization/shutdown only slow path code. but the point is, this is not about "performance". It's about _correctness_. Linus ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads 2006-11-01 19:52 ` Linus Torvalds @ 2006-11-01 21:15 ` Andi Kleen -1 siblings, 0 replies; 152+ messages in thread From: Andi Kleen @ 2006-11-01 21:15 UTC (permalink / raw) To: Linus Torvalds Cc: Andrew Morton, linux-pm, Ernst Herzberg, Linux Kernel Mailing List, Adrian Bunk, linux-acpi, Michael S. Tsirkin, Hugh Dickins, Martin Lorenz On Wednesday 01 November 2006 20:52, Linus Torvalds wrote: > > On Wed, 1 Nov 2006, Andi Kleen wrote: > > > > Fix race in IO-APIC routing entry setup. > > > > Interrupt could happen between setting the IO-APIC entry > > and setting its interrupt data. > > This doesn't fix anything at all. > > The interrupt can come in on another CPU, Only BP should be active at this point. At least not until we implement IO-APIC hotplug, but so far that isn't there. Ok in theory the BIOS could have put the other CPUs into weird states where they are still doing something and causing interrupts, but that would be a BIOS bug. I suppose it could happen with kexec, but that has still other problems anyways. The common case of no kexec shouldn't be affected at least. -Andi ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads @ 2006-11-01 21:15 ` Andi Kleen 0 siblings, 0 replies; 152+ messages in thread From: Andi Kleen @ 2006-11-01 21:15 UTC (permalink / raw) To: Linus Torvalds Cc: Michael S. Tsirkin, Ernst Herzberg, Len Brown, Adrian Bunk, Hugh Dickins, Pavel Machek, Andrew Morton, Linux Kernel Mailing List, linux-acpi, linux-pm, Martin Lorenz On Wednesday 01 November 2006 20:52, Linus Torvalds wrote: > > On Wed, 1 Nov 2006, Andi Kleen wrote: > > > > Fix race in IO-APIC routing entry setup. > > > > Interrupt could happen between setting the IO-APIC entry > > and setting its interrupt data. > > This doesn't fix anything at all. > > The interrupt can come in on another CPU, Only BP should be active at this point. At least not until we implement IO-APIC hotplug, but so far that isn't there. Ok in theory the BIOS could have put the other CPUs into weird states where they are still doing something and causing interrupts, but that would be a BIOS bug. I suppose it could happen with kexec, but that has still other problems anyways. The common case of no kexec shouldn't be affected at least. -Andi ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads 2006-11-01 6:16 ` Linus Torvalds @ 2006-11-01 22:35 ` Bill Davidsen -1 siblings, 0 replies; 152+ messages in thread From: Bill Davidsen @ 2006-11-01 22:35 UTC (permalink / raw) To: Linus Torvalds Cc: Andrew Morton, linux-pm, Martin Lorenz, linux-acpi, Ernst Herzberg, Hugh Dickins, Adrian Bunk, Andi Kleen, Linux Kernel Mailing List Linus Torvalds wrote: > I wonder if the order matters more, though. Andi? We _used_ to write the > high word first, and I think the order matters. The low word contains the > enable bit, for example, so when enabling an interrupt, you should write > the low word last, when you disable it you should write the low word > first. > Although you can argue that anyone coding here should be a guru, in practice things this subtle really would be helped by a comment in the initial code. I don't agree that "if it was hard to write it should be hard to understand." Clearly several competent people missed this dependency, or the patch would not have gone in. -- Bill Davidsen <davidsen@tmr.com> Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a normal user and is setuid root, with the "vi" line edit mode selected, and the character set is "big5," an off-by-one errors occurs during wildcard (glob) expansion. ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads @ 2006-11-01 22:35 ` Bill Davidsen 0 siblings, 0 replies; 152+ messages in thread From: Bill Davidsen @ 2006-11-01 22:35 UTC (permalink / raw) To: Linus Torvalds Cc: Andrew Morton, linux-pm, Ernst Herzberg, Andi Kleen, Linux Kernel Mailing List, linux-acpi, Hugh Dickins, Adrian Bunk, Martin Lorenz Linus Torvalds wrote: > I wonder if the order matters more, though. Andi? We _used_ to write the > high word first, and I think the order matters. The low word contains the > enable bit, for example, so when enabling an interrupt, you should write > the low word last, when you disable it you should write the low word > first. > Although you can argue that anyone coding here should be a guru, in practice things this subtle really would be helped by a comment in the initial code. I don't agree that "if it was hard to write it should be hard to understand." Clearly several competent people missed this dependency, or the patch would not have gone in. -- Bill Davidsen <davidsen@tmr.com> Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a normal user and is setuid root, with the "vi" line edit mode selected, and the character set is "big5," an off-by-one errors occurs during wildcard (glob) expansion. ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads 2006-11-01 5:54 ` Michael S. Tsirkin @ 2006-11-01 6:18 ` Michael S. Tsirkin -1 siblings, 0 replies; 152+ messages in thread From: Michael S. Tsirkin @ 2006-11-01 6:18 UTC (permalink / raw) To: Linus Torvalds Cc: Andrew Morton, linux-pm, Ernst Herzberg, Andi Kleen, Linux Kernel Mailing List, linux-acpi, Hugh Dickins, Adrian Bunk, Martin Lorenz Quoting r. Michael S. Tsirkin <mst@mellanox.co.il>: > What I plan to do is using eea0e11c1f0d6ef89e64182b2f1223a4ca2b74a2 > for a couple of days and see how this works out. Ugh. Unfortunately in that kernel version, the e1000 driver says the eeprom checksum is bad (works fine with 2.6.19-rc3). So, I tried some suspends/resumes and things seem to work, but I won't be able to test it under real use conditions. But maybe its another red herring? Andi, could you maybe look at that commit and tell me whether it could cause troubles with ACPI after suspend/resume even theoretically? -- MST ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads @ 2006-11-01 6:18 ` Michael S. Tsirkin 0 siblings, 0 replies; 152+ messages in thread From: Michael S. Tsirkin @ 2006-11-01 6:18 UTC (permalink / raw) To: Linus Torvalds Cc: Ernst Herzberg, Len Brown, Adrian Bunk, Hugh Dickins, Pavel Machek, Andrew Morton, Linux Kernel Mailing List, linux-acpi, linux-pm, Martin Lorenz, Andi Kleen Quoting r. Michael S. Tsirkin <mst@mellanox.co.il>: > What I plan to do is using eea0e11c1f0d6ef89e64182b2f1223a4ca2b74a2 > for a couple of days and see how this works out. Ugh. Unfortunately in that kernel version, the e1000 driver says the eeprom checksum is bad (works fine with 2.6.19-rc3). So, I tried some suspends/resumes and things seem to work, but I won't be able to test it under real use conditions. But maybe its another red herring? Andi, could you maybe look at that commit and tell me whether it could cause troubles with ACPI after suspend/resume even theoretically? -- MST ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads 2006-11-01 6:18 ` Michael S. Tsirkin (?) @ 2006-11-01 9:33 ` Pavel Machek 2006-11-01 12:02 ` Michael S. Tsirkin -1 siblings, 1 reply; 152+ messages in thread From: Pavel Machek @ 2006-11-01 9:33 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Linus Torvalds, Ernst Herzberg, Len Brown, Adrian Bunk, Hugh Dickins, Andrew Morton, Linux Kernel Mailing List, linux-acpi, linux-pm, Martin Lorenz, Andi Kleen On Wed 2006-11-01 08:18:57, Michael S. Tsirkin wrote: > Quoting r. Michael S. Tsirkin <mst@mellanox.co.il>: > > What I plan to do is using eea0e11c1f0d6ef89e64182b2f1223a4ca2b74a2 > > for a couple of days and see how this works out. > > Ugh. Unfortunately in that kernel version, the e1000 driver says > the eeprom checksum is bad (works fine with 2.6.19-rc3). > So, I tried some suspends/resumes and things seem to work, but > I won't be able to test it under real use conditions. Just comment out the eeprom checksum check... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads 2006-11-01 9:33 ` Pavel Machek @ 2006-11-01 12:02 ` Michael S. Tsirkin 0 siblings, 0 replies; 152+ messages in thread From: Michael S. Tsirkin @ 2006-11-01 12:02 UTC (permalink / raw) To: Pavel Machek Cc: Andrew Morton, linux-pm, Ernst Herzberg, Andi Kleen, Linux Kernel Mailing List, linux-acpi, Linus Torvalds, Hugh Dickins, Adrian Bunk, Martin Lorenz Quoting Pavel Machek <pavel@ucw.cz>: > > > What I plan to do is using eea0e11c1f0d6ef89e64182b2f1223a4ca2b74a2 > > > for a couple of days and see how this works out. > > > > Ugh. Unfortunately in that kernel version, the e1000 driver says > > the eeprom checksum is bad (works fine with 2.6.19-rc3). > > So, I tried some suspends/resumes and things seem to work, but > > I won't be able to test it under real use conditions. > > Just comment out the eeprom checksum check... > Right, that worked, thanks. I'm running on eea0e11c1f0d6ef89e64182b2f1223a4ca2b74a2 now, seems to be fine so far. -- MST ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads @ 2006-11-01 12:02 ` Michael S. Tsirkin 0 siblings, 0 replies; 152+ messages in thread From: Michael S. Tsirkin @ 2006-11-01 12:02 UTC (permalink / raw) To: Pavel Machek Cc: Linus Torvalds, Ernst Herzberg, Len Brown, Adrian Bunk, Hugh Dickins, Andrew Morton, Linux Kernel Mailing List, linux-acpi, linux-pm, Martin Lorenz, Andi Kleen Quoting Pavel Machek <pavel@ucw.cz>: > > > What I plan to do is using eea0e11c1f0d6ef89e64182b2f1223a4ca2b74a2 > > > for a couple of days and see how this works out. > > > > Ugh. Unfortunately in that kernel version, the e1000 driver says > > the eeprom checksum is bad (works fine with 2.6.19-rc3). > > So, I tried some suspends/resumes and things seem to work, but > > I won't be able to test it under real use conditions. > > Just comment out the eeprom checksum check... > Right, that worked, thanks. I'm running on eea0e11c1f0d6ef89e64182b2f1223a4ca2b74a2 now, seems to be fine so far. -- MST ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads 2006-11-01 6:18 ` Michael S. Tsirkin (?) (?) @ 2006-11-01 17:17 ` Andi Kleen -1 siblings, 0 replies; 152+ messages in thread From: Andi Kleen @ 2006-11-01 17:17 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Linus Torvalds, Ernst Herzberg, Len Brown, Adrian Bunk, Hugh Dickins, Pavel Machek, Andrew Morton, Linux Kernel Mailing List, linux-acpi, linux-pm, Martin Lorenz On Wednesday 01 November 2006 07:18, Michael S. Tsirkin wrote: > Quoting r. Michael S. Tsirkin <mst@mellanox.co.il>: > > What I plan to do is using eea0e11c1f0d6ef89e64182b2f1223a4ca2b74a2 > > for a couple of days and see how this works out. > > Ugh. Unfortunately in that kernel version, the e1000 driver says > the eeprom checksum is bad (works fine with 2.6.19-rc3). > So, I tried some suspends/resumes and things seem to work, but > I won't be able to test it under real use conditions. > > But maybe its another red herring? > Andi, could you maybe look at that commit and tell me whether > it could cause troubles with ACPI after suspend/resume even > theoretically? It touches suspend/resume so it could break something theoretically. -Andi ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads 2006-11-01 5:26 ` Linus Torvalds @ 2006-11-01 13:50 ` Stefan Seyfried -1 siblings, 0 replies; 152+ messages in thread From: Stefan Seyfried @ 2006-11-01 13:50 UTC (permalink / raw) To: Linus Torvalds Cc: Andrew Morton, linux-acpi, linux-pm, Michael S. Tsirkin, Hugh Dickins, Linux Kernel Mailing List, Martin Lorenz, Adrian Bunk, Ernst Herzberg On Tue, Oct 31, 2006 at 09:26:12PM -0800, Linus Torvalds wrote: > (Or it might not. Sometimes the patch that triggers changes really doesn't > seem to have anything to do with anything, and it literally was just a > latent bug that just happened to be exposed by something that had nothing > to do with anything at all but perhaps timing. Especially when "booting on AC works, but on battery it doesn't", (or the other way round), looking at timing problems seems sane to me. -- Stefan Seyfried QA / R&D Team Mobile Devices | "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads @ 2006-11-01 13:50 ` Stefan Seyfried 0 siblings, 0 replies; 152+ messages in thread From: Stefan Seyfried @ 2006-11-01 13:50 UTC (permalink / raw) To: Linus Torvalds Cc: Andrew Morton, linux-acpi, linux-pm, Michael S. Tsirkin, Hugh Dickins, Linux Kernel Mailing List, Martin Lorenz, Adrian Bunk, Ernst Herzberg On Tue, Oct 31, 2006 at 09:26:12PM -0800, Linus Torvalds wrote: > (Or it might not. Sometimes the patch that triggers changes really doesn't > seem to have anything to do with anything, and it literally was just a > latent bug that just happened to be exposed by something that had nothing > to do with anything at all but perhaps timing. Especially when "booting on AC works, but on battery it doesn't", (or the other way round), looking at timing problems seems sane to me. -- Stefan Seyfried QA / R&D Team Mobile Devices | "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads 2006-11-01 3:01 ` 2.6.19-rc <-> ThinkPads Adrian Bunk @ 2006-11-01 16:36 ` Hugh Dickins 2006-11-01 16:36 ` Hugh Dickins 2006-11-04 3:49 ` 2.6.19-rc <-> ThinkPads, summary Adrian Bunk 2 siblings, 0 replies; 152+ messages in thread From: Hugh Dickins @ 2006-11-01 16:36 UTC (permalink / raw) To: Adrian Bunk Cc: Andrew Morton, len.brown, linux-pm, linux-acpi, Michael S. Tsirkin, Linus Torvalds, Martin Lorenz, Linux Kernel Mailing List On Wed, 1 Nov 2006, Adrian Bunk wrote: > > Subject : Thinkpad R50p: boot fail with (lapic && on_battery) > References : http://lkml.org/lkml/2006/10/31/333 > Submitter : Ernst Herzberg <earny@net4u.de> > Status : submitter was asked to bisect > > It seems to be completely unrelated (except that it's also a ThinkPad), > but it might be worth a try whether a (non-SMP) kernel without APIC > support fixes the issues after resume. > > Hugh, your laptop seems to be a non-SMP laptop. That's right. > Do you have APIC enabled, and if yes does disabling help? Yes, I do. But I've just tried booting with "noapic" and with "nolapic" and with "noapic nolapic", but none of those make any difference. (That is, they make no difference to the FnF4-ineffective-after-resume behaviour that I'm finding fairly easy to reproduce at will today on 2.6.19-rc4; whereas yesterday it was seeming to me that -rc4 was much better than -rc3 in this regard. Something I have learnt today is that the key is ineffective "for a while", but may become effective later. It's conceivable that the behaviour I'm reproducing today is not quite the same as what I was experiencing earlier with real-life suspends.) More to the point, with great hope in my heart, I've tried backing out Andi's git-cf4c6a2f27f5db810b69dcb1da7f194489e8ff88.patch to arch/i386/kernel/io_apic.c, the one which Michael and Linus have homed in on. But sadly that makes no difference for me: I'd better get down to my own bisection. Hugh ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads @ 2006-11-01 16:36 ` Hugh Dickins 0 siblings, 0 replies; 152+ messages in thread From: Hugh Dickins @ 2006-11-01 16:36 UTC (permalink / raw) To: Adrian Bunk Cc: Michael S. Tsirkin, Pavel Machek, Linus Torvalds, Andrew Morton, Linux Kernel Mailing List, len.brown, linux-acpi, linux-pm, Martin Lorenz On Wed, 1 Nov 2006, Adrian Bunk wrote: > > Subject : Thinkpad R50p: boot fail with (lapic && on_battery) > References : http://lkml.org/lkml/2006/10/31/333 > Submitter : Ernst Herzberg <earny@net4u.de> > Status : submitter was asked to bisect > > It seems to be completely unrelated (except that it's also a ThinkPad), > but it might be worth a try whether a (non-SMP) kernel without APIC > support fixes the issues after resume. > > Hugh, your laptop seems to be a non-SMP laptop. That's right. > Do you have APIC enabled, and if yes does disabling help? Yes, I do. But I've just tried booting with "noapic" and with "nolapic" and with "noapic nolapic", but none of those make any difference. (That is, they make no difference to the FnF4-ineffective-after-resume behaviour that I'm finding fairly easy to reproduce at will today on 2.6.19-rc4; whereas yesterday it was seeming to me that -rc4 was much better than -rc3 in this regard. Something I have learnt today is that the key is ineffective "for a while", but may become effective later. It's conceivable that the behaviour I'm reproducing today is not quite the same as what I was experiencing earlier with real-life suspends.) More to the point, with great hope in my heart, I've tried backing out Andi's git-cf4c6a2f27f5db810b69dcb1da7f194489e8ff88.patch to arch/i386/kernel/io_apic.c, the one which Michael and Linus have homed in on. But sadly that makes no difference for me: I'd better get down to my own bisection. Hugh ^ permalink raw reply [flat|nested] 152+ messages in thread
* 2.6.19-rc <-> ThinkPads, summary 2006-11-01 3:01 ` 2.6.19-rc <-> ThinkPads Adrian Bunk 2006-11-01 3:15 ` Len Brown 2006-11-01 16:36 ` Hugh Dickins @ 2006-11-04 3:49 ` Adrian Bunk 2006-11-04 13:51 ` Hugh Dickins ` (2 more replies) 2 siblings, 3 replies; 152+ messages in thread From: Adrian Bunk @ 2006-11-04 3:49 UTC (permalink / raw) To: Hugh Dickins, Michael S. Tsirkin, Pavel Machek, Linus Torvalds, Andrew Morton, Linux Kernel Mailing List, len.brown, linux-acpi, linux-pm, Martin Lorenz, Andi Kleen, discuss, Russell King, linux-serial, linux-thinkpad, Ernst Herzberg As far as I can see, the 2.6.19-rc ThinkPad situation is still confusing and we don't even know how many different bugs we are chasing... Below is all the information I have found, plus some questions for the four people who reported problems that might hopefully bring us nearer to solutions. Michael S. Tsirkin: - ThinkPad T60 not coming out of suspend to RAM - broken by commit cf4c6a2f27f5db810b69dcb1da7f194489e8ff88 ("i386: Factor out common io apic routing entry access") - question: Did the post -rc4 arch/i386/kernel/io_apic.c changes fix it? Ernst Herzberg: - ThinkPad R50p: boot fail with (lapic && on_battery) - kernel compiled without cardbus support works - question: Does reverting the bisected commit 1fbbac4bcb03033d325c71fc7273aa0b9c1d9a03 ("serial_cs: convert multi-port table to quirk table") fix the problem? - question: Does reverting commit cf4c6a2f27f5db810b69dcb1da7f194489e8ff88 ("i386: Factor out common io apic routing entry access") help? - question: If yes, did the post -rc4 arch/i386/kernel/io_apic.c changes fix it? Hugh Dickins: - ThinkPad T43p - booting with "noapic nolapic" didn't make any difference - reverting commit cf4c6a2f27f5db810b69dcb1da7f194489e8ff88 ("i386: Factor out common io apic routing entry access") didn't help - question: Was your bisecting successful? Martin Lorenz: - ThinkPad X60: lose ACPI events after suspend/resume not every time, but roughly 3 out of 4 times - question: Does reverting commit cf4c6a2f27f5db810b69dcb1da7f194489e8ff88 ("i386: Factor out common io apic routing entry access") in -rc4 help? - question: If yes, did the post -rc4 arch/i386/kernel/io_apic.c changes fix it? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads, summary 2006-11-04 3:49 ` 2.6.19-rc <-> ThinkPads, summary Adrian Bunk @ 2006-11-04 13:51 ` Hugh Dickins 2006-11-04 14:04 ` Russell King 2006-11-17 1:53 ` 2.6.19-rc <-> ThinkPads, (related Ubuntu bug report) Mark Stosberg 2 siblings, 0 replies; 152+ messages in thread From: Hugh Dickins @ 2006-11-04 13:51 UTC (permalink / raw) To: Adrian Bunk Cc: Michael S. Tsirkin, Pavel Machek, Linus Torvalds, Andrew Morton, Linux Kernel Mailing List, len.brown, linux-acpi, linux-pm, Martin Lorenz, Andi Kleen, discuss, Russell King, linux-serial, linux-thinkpad, Ernst Herzberg On Sat, 4 Nov 2006, Adrian Bunk wrote: > > Hugh Dickins: > - ThinkPad T43p > - booting with "noapic nolapic" didn't make any difference > - reverting commit cf4c6a2f27f5db810b69dcb1da7f194489e8ff88 > ("i386: Factor out common io apic routing entry access") didn't help > - question: Was your bisecting successful? Not quite what I'd call successful, but I think I've just about arrived at some kind of conclusion. Short summary: forget my complaint, assume it's fixed in current -git. Boring version: I think I have two slightly different, perhaps not unrelated, issues. One manifested in habitual usage, to and from work, suspending for quiet at home, etc, etc. As 2.6.19-rc progressed, I more and more often found it impossible to re-suspend after the first time: suspend key ignored. rc3 seemed worst, rc4 at first seemed okay, then not, perhaps because... In order to bisect on this, I had to speed up the testing from a day or two to a few minutes; and I'm now thinking that this may have focussed on a different problem. After several reset bisections converging on absurd patches (e.g. sparse annotations or unbuilt sources), I grew even more suspicious of my "good" cases, and yesterday found even 2.6.18 and 2.6.17 (didn't try earlier) behave like this: occasionally the suspend key gets ignored for about one minute (in the few cases I timed). So whatever I was bisecting on, it's not a regression in 2.6.19. It may be a software bug, it would be worth fixing if I can work it out (though the pleasure of bisection was not having to think, I've grown addicted); but it's not anything to hold up 2.6.19. And as far as habitual usage goes, experience so far with -gits post rc4 suggests that that problem has gone away: it's a little too early to tell for sure, but I've not had to go back to using 2.6.18 to avoid it yet. Hugh ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads, summary 2006-11-04 3:49 ` 2.6.19-rc <-> ThinkPads, summary Adrian Bunk 2006-11-04 13:51 ` Hugh Dickins @ 2006-11-04 14:04 ` Russell King 2006-11-05 6:23 ` Adrian Bunk 2006-11-17 1:53 ` 2.6.19-rc <-> ThinkPads, (related Ubuntu bug report) Mark Stosberg 2 siblings, 1 reply; 152+ messages in thread From: Russell King @ 2006-11-04 14:04 UTC (permalink / raw) To: Adrian Bunk Cc: Hugh Dickins, Michael S. Tsirkin, Pavel Machek, Linus Torvalds, Andrew Morton, Linux Kernel Mailing List, len.brown, linux-acpi, linux-pm, Martin Lorenz, Andi Kleen, discuss, linux-serial, linux-thinkpad, Ernst Herzberg On Sat, Nov 04, 2006 at 04:49:07AM +0100, Adrian Bunk wrote: > As far as I can see, the 2.6.19-rc ThinkPad situation is still > confusing and we don't even know how many different bugs we are > chasing... Why am I copied on this? Nothing jumps out as being in any area of my interest (which today is limited to ARM architecture only.) -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads, summary 2006-11-04 14:04 ` Russell King @ 2006-11-05 6:23 ` Adrian Bunk 2006-11-07 20:06 ` Russell King 0 siblings, 1 reply; 152+ messages in thread From: Adrian Bunk @ 2006-11-05 6:23 UTC (permalink / raw) To: Hugh Dickins, Michael S. Tsirkin, Pavel Machek, Linus Torvalds, Andrew Morton, Linux Kernel Mailing List, len.brown, linux-acpi, linux-pm, Martin Lorenz, Andi Kleen, discuss, linux-serial, linux-thinkpad, Ernst Herzberg On Sat, Nov 04, 2006 at 02:04:40PM +0000, Russell King wrote: > On Sat, Nov 04, 2006 at 04:49:07AM +0100, Adrian Bunk wrote: > > As far as I can see, the 2.6.19-rc ThinkPad situation is still > > confusing and we don't even know how many different bugs we are > > chasing... > > Why am I copied on this? Nothing jumps out as being in any area of my > interest (which today is limited to ARM architecture only.) Ernst bisected his problem to your commit 1fbbac4bcb03033d325c71fc7273aa0b9c1d9a03 ("serial_cs: convert multi-port table to quirk table"). It might be a false positive of the bisecting, but if it turns out to actually cause problems it was your commit. > Russell King cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads, summary 2006-11-05 6:23 ` Adrian Bunk @ 2006-11-07 20:06 ` Russell King 2006-11-07 20:19 ` Ernst Herzberg 0 siblings, 1 reply; 152+ messages in thread From: Russell King @ 2006-11-07 20:06 UTC (permalink / raw) To: Adrian Bunk; +Cc: Andrew Morton, Linux Kernel Mailing List, Ernst Herzberg On Sun, Nov 05, 2006 at 07:23:30AM +0100, Adrian Bunk wrote: > On Sat, Nov 04, 2006 at 02:04:40PM +0000, Russell King wrote: > > On Sat, Nov 04, 2006 at 04:49:07AM +0100, Adrian Bunk wrote: > > > As far as I can see, the 2.6.19-rc ThinkPad situation is still > > > confusing and we don't even know how many different bugs we are > > > chasing... > > > > Why am I copied on this? Nothing jumps out as being in any area of my > > interest (which today is limited to ARM architecture only.) > > Ernst bisected his problem to your > commit 1fbbac4bcb03033d325c71fc7273aa0b9c1d9a03 > ("serial_cs: convert multi-port table to quirk table"). > > It might be a false positive of the bisecting, but if it turns out to > actually cause problems it was your commit. No idea, sorry. No information if a serial card was in the PCMCIA slot. If there's no _PCMCIA_ serial card inserted, the code in that patch will not be run. Also no indication if serial_cs was built into Earnst's kernel. If it wasn't, this commit couldn't be the cause. NeedMoreInformation. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads, summary 2006-11-07 20:06 ` Russell King @ 2006-11-07 20:19 ` Ernst Herzberg 0 siblings, 0 replies; 152+ messages in thread From: Ernst Herzberg @ 2006-11-07 20:19 UTC (permalink / raw) To: Russell King; +Cc: Adrian Bunk, Andrew Morton, Linux Kernel Mailing List On Tuesday 07 November 2006 21:06, Russell King wrote: > On Sun, Nov 05, 2006 at 07:23:30AM +0100, Adrian Bunk wrote: > > On Sat, Nov 04, 2006 at 02:04:40PM +0000, Russell King wrote: > > > On Sat, Nov 04, 2006 at 04:49:07AM +0100, Adrian Bunk wrote: > > > > As far as I can see, the 2.6.19-rc ThinkPad situation is still > > > > confusing and we don't even know how many different bugs we are > > > > chasing... > > > > > > Why am I copied on this? Nothing jumps out as being in any area of > > > my interest (which today is limited to ARM architecture only.) > > > > Ernst bisected his problem to your > > commit 1fbbac4bcb03033d325c71fc7273aa0b9c1d9a03 > > ("serial_cs: convert multi-port table to quirk table"). > > > > It might be a false positive of the bisecting, but if it turns out to > > actually cause problems it was your commit. > > No idea, sorry. > > No information if a serial card was in the PCMCIA slot. If there's > no _PCMCIA_ serial card inserted, the code in that patch will not be > run. > > Also no indication if serial_cs was built into Earnst's kernel. If > it wasn't, this commit couldn't be the cause. > > NeedMoreInformation. It was a false positive of the bisecting. Now i can reproduce the problem without Cardbus/PCMCIA complied in. So you are now allowed to remove yoursef from the distribution list ;-) Sorry, <earny> ^ permalink raw reply [flat|nested] 152+ messages in thread
* Re: 2.6.19-rc <-> ThinkPads, (related Ubuntu bug report) 2006-11-04 3:49 ` 2.6.19-rc <-> ThinkPads, summary Adrian Bunk 2006-11-04 13:51 ` Hugh Dickins 2006-11-04 14:04 ` Russell King @ 2006-11-17 1:53 ` Mark Stosberg 2 siblings, 0 replies; 152+ messages in thread From: Mark Stosberg @ 2006-11-17 1:53 UTC (permalink / raw) To: linux-thinkpad; +Cc: linux-kernel, linux-acpi, linux-pm, discuss 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... Hello, I just hoped on this list to see what "ThinkPad" discussion there was. Here my own observations: Using Mandriva 2006 with 2.6.12, ACPI suspend/resume works great on a ThinkPad T20. It didn't work with 2.6.14, and it doesn't work with 2.6.17 with Mandriva. Further, it doesn't seem to work with on some ThinkPads with Ubuntu and 2.6.15 and 2.6.17 either, as this now-lengthy bug report documents: https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/+bug/50031 I added a comment there encouraging the other bug reporters to include the kind of information requested on the ACPI website, but so far no have. Personally, I'm still using 2.6.12 daily because of this regression. I'm interested to help resolve it, but am not currently tracking the latest kernel sources. I realize this bug report is a bit out of date with respect to 2.6.19, but as another poster suggested, this could simply indicate that at least one regressions may not be recent. Mark -- The linux-thinkpad mailing list home page is at: http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad ^ permalink raw reply [flat|nested] 152+ messages in thread
end of thread, other threads:[~2006-11-17 1:53 UTC | newest] Thread overview: 152+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2006-10-23 23:22 Linux 2.6.19-rc3 Linus Torvalds 2006-10-24 2:24 ` Gene Heskett 2006-10-24 7:46 ` Muli Ben-Yehuda 2006-10-24 18:07 ` Badari Pulavarty 2006-10-24 20:21 ` 2.6.19-rc3: known unfixed regressions Adrian Bunk 2006-10-24 20:21 ` Adrian Bunk 2006-10-24 20:21 ` Adrian Bunk 2006-10-24 21:44 ` 2.6.19-rc3: known unfixed regressions: confirmations teunis 2006-10-26 15:31 ` Adrian Bunk 2006-10-26 15:54 ` teunis 2006-10-25 1:51 ` 2.6.19-rc3: known regressions with patches Adrian Bunk 2006-10-25 1:51 ` Adrian Bunk 2006-10-25 11:25 ` Linux 2.6.19-rc3 Jean Delvare 2006-10-25 12:01 ` Damien Wyart 2006-10-25 16:25 ` Auke Kok 2006-10-26 7:20 ` Jean Delvare 2006-10-25 20:13 ` Linux 2.6.19-rc3: !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB Athanasius 2006-10-25 22:17 ` [PATCH] " Randy Dunlap 2006-10-25 22:27 ` David Brownell 2006-10-25 22:27 ` David Brownell 2006-10-25 23:58 ` [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled Randy Dunlap 2006-10-26 2:22 ` David Brownell 2006-11-02 7:15 ` Greg KH 2006-11-02 20:29 ` David Brownell 2006-11-03 2:27 ` Adrian Bunk 2006-11-03 2:47 ` David Brownell 2006-11-03 2:58 ` Randy.Dunlap 2006-11-04 2:51 ` [2.6 patch] USB_RTL8150 must select MII Adrian Bunk 2006-10-26 15:46 ` [PATCH 2/2] usbnet: use MII hooks only if CONFIG_MII is enabled Adrian Bunk 2006-10-26 15:51 ` Randy.Dunlap 2006-10-28 11:21 ` Christoph Hellwig 2006-10-28 21:10 ` David Brownell 2006-10-28 21:13 ` Christoph Hellwig 2006-10-28 22:30 ` David Brownell 2006-10-28 21:39 ` Adrian Bunk 2006-10-31 17:40 ` [linux-usb-devel] " David Brownell 2006-10-31 18:07 ` Adrian Bunk 2006-10-31 19:36 ` David Brownell 2006-11-01 1:23 ` Adrian Bunk 2006-11-02 20:19 ` David Brownell 2006-10-25 23:59 ` [PATCH 1/2] !CONFIG_NET_ETHERNET unsets CONFIG_PHYLIB, but CONFIG_USB_USBNET also needs CONFIG_PHYLIB Randy Dunlap 2006-10-25 23:59 ` Randy Dunlap 2006-10-26 2:24 ` David Brownell 2006-10-26 5:05 ` Randy.Dunlap 2006-10-26 5:24 ` David Brownell 2006-10-26 22:45 ` 2.6.19-rc3: known unfixed regressions (v2) Adrian Bunk 2006-10-26 22:45 ` Adrian Bunk 2006-10-26 22:45 ` Adrian Bunk 2006-10-27 1:02 ` [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN Adrian Bunk 2006-10-27 1:20 ` Matthew Wilcox 2006-10-27 1:28 ` Andrew Morton 2006-10-27 2:11 ` Stephen Hemminger 2006-10-27 17:07 ` Greg KH 2006-10-27 17:22 ` Pavel Machek 2006-10-27 18:39 ` Andrew Morton 2006-10-27 18:41 ` vmlinux.lds: consolidate initcall sections Andrew Morton 2006-10-27 18:42 ` [patch] drivers: wait for threaded probes between initcall levels Andrew Morton 2006-10-27 18:47 ` Stephen Hemminger 2006-10-27 20:15 ` Andrew Morton 2006-10-27 20:42 ` Linus Torvalds 2006-10-27 20:48 ` Linus Torvalds 2006-10-28 1:11 ` Greg KH 2006-10-28 1:50 ` Linus Torvalds 2006-10-27 22:59 ` Alan Cox 2006-10-27 23:06 ` Andrew Morton 2006-10-28 5:09 ` Grant Grundler 2006-10-28 5:19 ` Andrew Morton 2006-10-28 5:32 ` Andrew Morton 2006-10-28 6:08 ` Grant Grundler 2006-10-28 20:48 ` Stefan Richter 2006-10-28 23:34 ` Alan Cox 2006-10-29 2:01 ` Randy Dunlap 2006-10-30 9:44 ` Cornelia Huck 2006-10-30 10:48 ` Alan Cox 2006-10-30 12:29 ` Matthew Wilcox 2006-10-27 23:12 ` Olaf Hering 2006-10-27 19:31 ` vmlinux.lds: consolidate initcall sections Haavard Skinnemoen 2006-10-29 10:21 ` Geert Uytterhoeven 2006-10-27 19:44 ` Matthew Wilcox 2006-10-27 20:17 ` Andrew Morton 2006-10-27 20:27 ` Matthew Wilcox 2006-10-27 22:23 ` [RFC: 2.6.19 patch] let PCI_MULTITHREAD_PROBE depend on BROKEN Adrian Bunk 2006-10-27 22:38 ` Andrew Morton 2006-10-28 1:08 ` Greg KH 2006-10-27 23:03 ` Alan Cox 2006-10-27 22:57 ` Alan Cox 2006-10-27 8:27 ` Pavel Machek 2006-10-29 23:13 ` 2.6.19-rc3: known unfixed regressions (v3) Adrian Bunk 2006-10-29 23:13 ` Adrian Bunk 2006-10-30 13:56 ` Michael S. Tsirkin 2006-10-30 13:56 ` Michael S. Tsirkin 2006-10-30 15:27 ` Martin Lorenz 2006-10-30 16:17 ` Jun'ichi Nomura 2006-10-30 16:32 ` Michael S. Tsirkin 2006-10-30 17:20 ` Jun'ichi Nomura 2006-10-30 17:20 ` Jun'ichi Nomura 2006-10-30 17:54 ` Michael S. Tsirkin 2006-10-30 17:54 ` Michael S. Tsirkin 2006-10-30 16:44 ` Linus Torvalds 2006-10-30 17:34 ` Jun'ichi Nomura 2006-10-30 18:16 ` Linus Torvalds 2006-10-30 18:16 ` Linus Torvalds 2006-10-30 18:35 ` Adrian Bunk 2006-10-30 19:00 ` Michael S. Tsirkin 2006-10-30 19:06 ` Hugh Dickins 2006-10-31 12:47 ` Martin Lorenz 2006-10-30 18:58 ` Michael S. Tsirkin 2006-10-31 21:15 ` Michael S. Tsirkin 2006-10-31 21:15 ` Michael S. Tsirkin 2006-11-01 3:01 ` 2.6.19-rc <-> ThinkPads Adrian Bunk 2006-11-01 3:15 ` Len Brown 2006-11-01 3:15 ` Len Brown 2006-11-01 5:11 ` Ernst Herzberg 2006-11-01 5:26 ` Linus Torvalds 2006-11-01 5:26 ` Linus Torvalds 2006-11-01 5:54 ` Michael S. Tsirkin 2006-11-01 5:54 ` Michael S. Tsirkin 2006-11-01 6:16 ` Linus Torvalds 2006-11-01 6:16 ` Linus Torvalds 2006-11-01 17:25 ` Andi Kleen 2006-11-01 18:12 ` Michael S. Tsirkin 2006-11-01 18:12 ` Michael S. Tsirkin 2006-11-01 18:25 ` Linus Torvalds 2006-11-01 18:25 ` Linus Torvalds 2006-11-01 19:33 ` Michael S. Tsirkin 2006-11-01 19:33 ` Michael S. Tsirkin 2006-11-01 19:44 ` Linus Torvalds 2006-11-01 19:44 ` Linus Torvalds 2006-11-01 19:34 ` Andi Kleen 2006-11-01 19:52 ` Linus Torvalds 2006-11-01 19:52 ` Linus Torvalds 2006-11-01 21:15 ` Andi Kleen 2006-11-01 21:15 ` Andi Kleen 2006-11-01 22:35 ` Bill Davidsen 2006-11-01 22:35 ` Bill Davidsen 2006-11-01 6:18 ` Michael S. Tsirkin 2006-11-01 6:18 ` Michael S. Tsirkin 2006-11-01 9:33 ` Pavel Machek 2006-11-01 12:02 ` Michael S. Tsirkin 2006-11-01 12:02 ` Michael S. Tsirkin 2006-11-01 17:17 ` Andi Kleen 2006-11-01 13:50 ` Stefan Seyfried 2006-11-01 13:50 ` Stefan Seyfried 2006-11-01 16:36 ` Hugh Dickins 2006-11-01 16:36 ` Hugh Dickins 2006-11-04 3:49 ` 2.6.19-rc <-> ThinkPads, summary Adrian Bunk 2006-11-04 13:51 ` Hugh Dickins 2006-11-04 14:04 ` Russell King 2006-11-05 6:23 ` Adrian Bunk 2006-11-07 20:06 ` Russell King 2006-11-07 20:19 ` Ernst Herzberg 2006-11-17 1:53 ` 2.6.19-rc <-> ThinkPads, (related Ubuntu bug report) Mark Stosberg
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.