Ok,
it's a couple of days delayed, because we've been trying to figure out
what is up with the rtorrent hash failures since 2.6.18.3. I don't think
we've made any progress, but we've cleaned up a number of suspects in the
meantime.
It's a bit sad, if only because I was really hoping to make 2.6.20 an easy
release, and held back on merging some stuff during the merge window for
that reason. And now we're battling something that was introduced much
earlier..
Now, practically speaking this isn't likely to affect a lot of people, but
it's still a worrisome problem, and we've had "top people" looking at it.
And they'll continue, but xmas is coming.
In the meantime, we'll continue with the stabilization, and this mainly
does some driver updates (usb, sound, dri, pci hotplug) and ACPI updates
(much of the latter syntactic cleanups). And arm and powerpc updates.
Shortlog appended.
For developers: if you sent me a patch, and I didn't apply it, it was
probably just missed because I concentrated on other issues. So pls
re-send.. Unless I explicitly told you that I'm not going to pull it due
to the merge window being over, of course ;)
Linus
---
Adrian Bunk (10):
ACPI: make drivers/acpi/ec.c:ec_ecdt static
ACPI: fix NULL check in drivers/acpi/osl.c
[ALSA] sound/core/control.c: remove dead code
PCI: don't export device IDs to userspace
Driver core: proper prototype for drivers/base/init.c:driver_init()
make kernel/printk.c:ignore_loglevel_setup() static
fs/sysv/: proper prototypes for 2 functions
[ATM]: Remove dead ATM_TNETA1570 option.
[ATM] drivers/atm/fore200e.c: Cleanups.
[SCTP]: make 2 functions static
Akinobu Mita (9):
drm: fix return value check
ata: fix platform_device_register_simple() error check
ACPI: fix single linked list manipulation
ACPI: prevent processor module from loading on failures
[ALSA] sound: initialize rawmidi substream list
[ALSA] sound: fix PCM substream list
audit: fix kstrdup() error check
gss_spkm3: fix error handling in module init
tlclk: delete unnecessary sysfs_remove_group
Al Viro (4):
m68k trivial build fixes
more work_struct fixes: tas300x sound drivers
fix leaks on pipe(2) failure exits
[IPV6]: Dumb typo in generic csum_ipv6_magic()
Alan Cox (5):
Fix help text for CONFIG_ATA_PIIX
pata_via: Cable detect error
usb serial: Eliminate bogus ioctl code
pci: Introduce pci_find_present
PCI: Fix multiple problems with VIA hardware
Alan Stern (1):
UHCI: module parameter to ignore overcurrent changes
Alexey Starikovskiy (15):
ACPI: ec: Allow for write semantics in any command.
ACPI: ec: Enable EC GPE at beginning of transaction
ACPI: ec: Increase timeout from 50 to 500 ms to handle old slow machines.
ACPI: ec: Read status register from check_status() function
ACPI: ec: Remove expect_event and all races around it.
ACPI: ec: Remove calls to clear_gpe() and enable_gpe(), as these are handled at
ACPI: ec: Query only single query at a time.
ACPI: ec: Change semaphore to mutex.
ACPI: ec: Rename gpe_bit to gpe
ACPI: ec: Drop udelay() from poll mode. Loop by reading status field instead.
ACPI: ec: Acquire Global Lock under EC mutex.
ACPI: ec: Style changes.
ACPI: ec: Change #define to enums there possible.
ACPI: ec: Lindent once again
ACPI: ibm_acpi: allow clean removal
Andreas Mohr (1):
[ALSA] via82xx: add __devinitdata
Andrew Morton (15):
ACPI: uninline ACPI global locking functions
ACPI: acpi-cpufreq: remove unused data when !CONFIG_SMP
ACPI: Kconfig - depend on PM rather than selecting it
[libata] pata_cs5530: suspend/resume support tweak
[libata] pata_via: suspend/resume support fix
USB: Nokia E70 is an unusual device
USB: Nokia E70 is an unusual device
truncate: clear page dirtiness before running try_to_free_buffers()
truncate: dirty memory accounting fix
rtc warning fix
smc911 workqueue fixes
schedule_timeout(): improve warning message
relay: remove inlining
increase CARDBUS_MEM_SIZE
build compile.h earlier
Andrew Victor (3):
USB: ohci at91 warning fix
USB: at91 udc, support at91sam926x addresses
USB: at91_udc, misc fixes
Aneesh Kumar K.V (1):
kobject: kobject_uevent() returns manageable value
Arnd Bergmann (4):
[POWERPC] cell: update cell_defconfig
[POWERPC] cell: add forward struct declarations to spu.h
[POWERPC] spufs: fix assignment of node numbers
[POWERPC] powerpc: add scanning of ebc bus to of_platform
Avi Kivity (4):
KVM: AMD SVM: handle MSR_STAR in 32-bit mode
KVM: AMD SVM: Save and restore the floating point unit state
KVM: Use more traditional error handling in kvm_mmu_init()
KVM: API versioning
Badari Pulavarty (1):
Fix for shmem_truncate_range() BUG_ON()
Ben Collins (1):
ib_verbs: Use explicit if-else statements to avoid errors with do-while macros
Ben Dooks (18):
[ARM] 4038/1: S3C24XX: Fix copyrights in include/asm-arm/arch-s3c2410 (core)
[ARM] 4039/1: S3C24XX: Fix copyrights in include/asm-arm/arch-s3c2410 (mach)
[ARM] 4040/1: S3C24XX: Fix copyrights in arch/arm/mach-s3c2410
[ARM] 4041/1: S3C24XX: Fix sparse errors from VA addresses
[ARM] 4042/1: H1940: Fix sparse errors from VA addresses
[ARM] 4043/1: S3C24XX: fix sparse warnings in arch/arm/mach-s3c2410/s3c2440-clock.c
[ARM] 4044/1: S3C24XX: fix sparse warnings in arch/arm/mach-s3c2410/s3c2442-clock.c
[ARM] 4045/1: S3C24XX: remove old VA for non-shared areas
[ARM] 4046/1: S3C24XX: fix sparse errors arch/arm/mach-s3c2410
[ARM] 4048/1: S3C24XX: make s3c2410_pm_resume() static
[ARM] 4049/1: S3C24XX: fix sparse warning due to upf_t in regs-serial.h
[ARM] 4050/1: S3C24XX: remove old changelogs in arch/arm/mach-s3c2410
[ARM] 4051/1: S3C24XX: clean includes in S3C2440 and S3C2442 support
[ARM] 4052/1: S3C24XX: Fix PM in arch/arm/mach-s3c2410/Kconfig
[ARM] 4059/1: VR1000: fix LED3's platform device number
[ARM] 4062/1: S3C24XX: Anubis and Osiris shuld have CONFIG_PM_SIMTEC
MAINTAINERS: fix email for S3C2410 and S3C2440
fix s3c24xx gpio driver (include linux/workqueue.h)
Benjamin Herrenschmidt (3):
[POWERPC] cell: Fix spufs with "new style" device-tree
[POWERPC] Workaround oldworld OF bug with IRQs & P2P bridges
[POWERPC] Fix build of cell zImage.initrd
Burman Yan (2):
USB AUERSWALD: replace kmalloc+memset with kzalloc
ACPI: replace kmalloc+memset with kzalloc
Chen, Justin (1):
ACPI: optimize pci_rootbridge search
Chris Frey (1):
USB: fix to usbfs_snoop logging of user defined control urbs
Christian Borntraeger (2):
[S390] hypfs fixes
[S390] sclp_cpi module license.
Christian Hesse (1):
[ALSA] hda-codec - fix typo in PCI IDs
Christoph Lameter (1):
slab: fix kmem_ptr_validate definition
Clemens Ladisch (3):
[ALSA] use the ALIGN macro
[ALSA] use the roundup macro
[ALSA] pcm core: fix silence_start calculations
Conke Hu (1):
PCI: ATI sb600 sata quirk
Dan Williams (1):
[ARM] 4022/1: iop13xx: generic irq fixups
Dave Airlie (3):
drm: fixup comment header style
drm: make kernel context switch same as for drm git tree.
drm: r128: comment aligment with drm git
Dave Jones (2):
[CPUFREQ] Advise not to use longhaul on VIA C7.
[CPUFREQ] longhaul compile fix.
Dave Kleikamp (1):
Fix JFS after clear_page_dirty() removal
David Brownell (3):
USB: gadget driver unbind() is optional; section fixes; misc
USB: MAINTAINERS update, EHCI and OHCI
USB: ohci whitespace/comment fixups
David Chinner (1):
Fix XFS after clear_page_dirty() removal
David Clare (1):
USB: Prevent the funsoft serial device from entering raw mode
David Rientjes (1):
PCI quirks: remove redundant check
David S. Miller (8):
[SPARC64]: Kill no-remapping-needed code in head.S
[SPARC64]: Minor irq handling cleanups.
[DocBook]: Fix two typos in generic IRQ docs.
[SPARC64]: Mirror x86_64's PERCPU_ENOUGH_ROOM definition.
[SPARC]: Update defconfig.
[SPARC]: Make bitops use same spinlocks as atomics.
[NETFILTER] IPV6: Fix dependencies.
[UDP]: Fix reversed logic in udp_get_port().
David Woodhouse (1):
[POWERPC] Probe Efika platform before CHRP.
Dhaval Giani (1):
[CPUFREQ] fixes typo in cpufreq.c
Dmitry Torokhov (1):
ACPI: button: register with input layer
Eagle Jones (1):
USB: airprime: add device id for dell wireless 5500 hsdpa card
Ed L. Cashin (1):
fix aoe without scatter-gather [Bug 7662]
Eric Anholt (1):
drm: savage: compat fix from drm git.
Eric Smith (1):
usb serial: add support for Novatel S720/U720 CDMA/EV-DO modems
Eric W. Biederman (1):
Fix reparenting to the same thread group. (take 2)
Evgeniy Polyakov (2):
[CONNECTOR]: Fix compilation breakage introduced recently.
[CONNECTOR]: Replace delayed work with usual work queue.
Fabrice Knevez (1):
[SUNKBD]: Fix sunkbd_enable(sunkbd, 0); obvious.
Florian Festi (1):
input/hid: Supporting more keys from the HUT Consumer Page
Geert Uytterhoeven (1):
__set_irq_handler bogus space
Gerrit Renker (1):
[TCP]: Fix ambiguity in the `before' relation.
Glen Masgai (1):
[ALSA] ymfpci: fix swap_rear for S/PDIF passthrough
Greg Kroah-Hartman (1):
USB Storage: remove duplicate Nokia entry in unusual_devs.h
Henrique de Moraes Holschuh (22):
ACPI: ibm-acpi: new ibm-acpi maintainer
ACPI: ibm-acpi: do not use / in driver names
ACPI: ibm-acpi: trivial Lindent cleanups
ACPI: ibm-acpi: Use a enum to select the thermal sensor reading strategy
ACPI: ibm-acpi: Implement direct-ec-access thermal reading modes for up to 16 sensors
ACPI: ibm-acpi: document thermal sensor locations for the A31
ACPI: ibm-acpi: prepare to cleanup fan_read and fan_write
ACPI: ibm-acpi: clean up fan_read
ACPI: ibm-acpi: break fan_read into separate functions
ACPI: ibm-acpi: cleanup fan_write
ACPI: ibm-acpi: document fan control
ACPI: ibm-acpi: extend fan status functions
ACPI: ibm-acpi: fix and extend fan enable
ACPI: ibm-acpi: fix and extend fan control functions
ACPI: ibm-acpi: store embedded controller firmware version for matching
ACPI: ibm-acpi: workaround for EC 0x2f initialization bug
ACPI: ibm-acpi: implement fan watchdog command
ACPI: ibm-acpi: add support for the ultrabay on the T60,X60
ACPI: ibm-acpi: make non-generic bay support optional
ACPI: ibm-acpi: backlight device cleanup
ACPI: ibm-acpi: style fixes and cruft removal
ACPI: ibm-acpi: update version and copyright
Hisashi Hifumi (1):
jbd: wait for already submitted t_sync_datalist buffer to complete
Holger Macht (3):
ACPI: ibm_acpi: Add support for the generic backlight device
ACPI: asus_acpi: Add support for the generic backlight device
ACPI: toshiba_acpi: Add support for the generic backlight device
Inaky Perez-Gonzalez (1):
pci: add class codes for Wireless RF controllers
Ingo Molnar (6):
x86_64: fix boot hang caused by CALGARY_IOMMU_ENABLED_BY_DEFAULT
x86_64: fix boot time hang in detect_calgary()
workqueue: fix schedule_on_each_cpu()
lock debugging: fix DEBUG_LOCKS_WARN_ON() & debug_locks_silent
sched: fix bad missed wakeups in the i386, x86_64, ia64, ACPI and APM idle code
suspend: fix suspend on single-CPU systems
Ira Snyder (1):
initializer entry defined twice in pata_rz1000
Ivan Skytte Jorgensen (1):
[SCTP]: Fix typo adaption -> adaptation as per the latest API draft.
James C Georgas (1):
[ALSA] ac97_codec - trivial fix for bit update functions
James Courtier-Dutton (3):
[ALSA] snd-ca0106: Add new card variant.
[ALSA] snd-ca0106: Fix typos.
[ALSA] ac97: Identify CMI9761 chips.
James Morris (1):
KVM: add valid_vcpu() helper
James Simmons (1):
fbdev: update after backlight argument change
Jan Capek (1):
USB: ftdi_sio - MachX product ID added
Jan Engelhardt (1):
ACPI: Remove unnecessary from/to-void* and to-void casts in drivers/acpi
Jaroslav Kysela (2):
[ALSA] ac97_codec (ALC655): add EAPD hack for MSI L725 laptop
[ALSA] version 1.0.14rc1
Jason Gaston (1):
ata_piix: IDE mode SATA patch for Intel ICH9
Jean Delvare (3):
drm: Stop defining pci_pretty_name
[ALSA] sound: Don't include i2c-dev.h
microcode: fix mc_cpu_notifier section warning
Jeff Garzik (5):
DRM: handle pci_enable_device failure
[libata] use kmap_atomic(KM_IRQ0) in SCSI simulator
[libata] sata_svw: Disable ATAPI DMA on current boards (errata workaround)
USB: fix ohci.h over-use warnings
[libata] sata_svw, sata_vsc: kill iomem warnings
Jens Axboe (9):
->nr_sectors and ->hard_nr_sectors are not used for BLOCK_PC requests
Remove queue merging hooks
__blk_rq_map_user() doesn't need to grab the queue_lock
__blk_rq_unmap_user() fails to return error
Fixup blk_rq_unmap_user() API
cfq-iosched: don't allow sync merges across queues
block: document io scheduler allow_merge_fn hook
elevator: fixup typo in merge logic
cfq-iosched: tighten allow merge criteria
Jens Osterkamp (1):
[POWERPC] cell: Enable spider workarounds on all PCI buses
Jeremy Fitzhardinge (1):
ptrace: Fix EFL_OFFSET value according to i386 pda changes
Jesper Juhl (2):
ACPI: Get rid of 'unused variable' warning in acpi_ev_global_lock_handler()
PCI: Be a bit defensive in quirk_nvidia_ck804() so we don't risk dereferencing a NULL pdev.
Jiri Kosina (2):
Generic HID layer - build: USB_HID should select HID
Generic HID layer - update MAINTAINERS
Johann Wilhelm (2):
usb-storage: Ignore the virtual cd-drive of the Huawei E220 USB Modem
usb-gsm-driver: Added VendorId and ProductId for Huawei E220 USB Modem
Johannes Hoelzl (1):
Add Baltech Reader ID to CP2101 driver
John Keller (1):
ACPI: Add support for acpi_load_table/acpi_unload_table_id
Josh Boyer (1):
Make JFFS depend on CONFIG_BROKEN
Kenji Kaneshige (5):
PCI: pcieport-driver: remove invalid warning message
shpchp: remove unnecessary struct php_ctlr
shpchp: cleanup struct controller
shpchp: remove shpchprm_get_physical_slot_number
shpchp: cleanup shpchp.h
Kristen Carlson Accardi (4):
ACPI: dock: use mutex instead of spinlock
ACPI: dock: Make the dock station driver a platform device driver.
ACPI: dock: add uevent to indicate change in device status
acpiphp: Link-time error for PCI Hotplug
Krzysztof Helt (1):
[ARM] 4015/1: s3c2410 cpu ifdefs
Leigh Brown (2):
[TCP]: Fix oops caused by tcp_v4_md5_do_del
[TCP]: Trivial fix to message in tcp_v4_inbound_md5_hash
Len Brown (3):
ACPI: dock: fix build warning
ACPI: ibm_acpi: respond to workqueue update
ACPI: fix git automerge failure
Lennert Buytenhek (6):
[ARM] 4054/1: ep93xx: add HWCAP_CRUNCH
[ARM] 4055/1: iop13xx: fix phys_io/io_pg_offst for iq81340mc/sc
[ARM] 4056/1: iop13xx: fix resource.end off-by-one in flash setup
[ARM] 4057/1: ixp23xx: unconditionally enable hardware coherency
[ARM] 4061/1: xsc3: change of maintainer
[ARM] 4060/1: update several ARM defconfigs
Leonid Arsh (1):
IB/mthca: Add HCA profile module parameters
Li Yewang (1):
[IPV4]: Fix BUG of ip_rt_send_redirect()
Linas Vepstas (2):
[POWERPC] Fix PCI device channel state initialization
rpaphp: compiler warning cleanup
Linus Torvalds (11):
Remove stack unwinder for now
Fix "delayed_work_pending()" macro expansion
Fix incorrect user space access locking in mincore()
Make workqueue bit operations work on "atomic_long_t"
Fix up mm/mincore.c error value cases
Clean up and make try_to_free_buffers() not race with dirty pages
VM: Remove "clear_page_dirty()" and "test_clear_page_dirty()" functions
Clean up and export cancel_dirty_page() to modules
Fix reiserfs after "test_clear_page_dirty()" removal
Fix up CIFS for "test_clear_page_dirty()" removal
Linux 2.6.20-rc2
Maciej W. Rozycki (1):
mips: if_fddi.h: Add a missing inclusion
Magnus Damm (1):
fix vm_events_fold_cpu() build breakage
Marcel Holtmann (1):
Call init_timer() for ISDN PPP CCP reset state timer
Mark Fasheh (1):
Conditionally check expected_preempt_count in __resched_legal()
Martin Bligh (1):
ACPI: avoid gcc warnings in ACPI mutex debug code
Martin Schwidefsky (1):
[S390] update default configuration
Martin Waitz (1):
kernel-doc: remove Martin from MAINTAINERS
Mattia Dongili (1):
[CPUFREQ] set policy->curfreq on initialization
Michael Chan (7):
[BNX2]: Fix panic in bnx2_tx_int().
[BNX2]: Fix bug in bnx2_nvram_write().
[BNX2]: Fix minor loopback problem.
[TG3]: Assign tp->link_config.orig_* values.
[TG3]: Fix race condition when calling register_netdev().
[TG3]: Power down/up 5906 PHY correctly.
[TG3]: Update version and reldate.
Michel D?nzer (2):
i915_vblank_tasklet: Try harder to avoid tearing.
drm: Unify radeon offset checking.
Michael Ellerman (6):
PCI: Create __pci_bus_find_cap_start() from __pci_bus_find_cap()
PCI: Add pci_find_ht_capability() for finding Hypertransport capabilities
PCI: Use pci_find_ht_capability() in drivers/pci/htirq.c
PCI: Add #defines for Hypertransport MSI fields
PCI: Use pci_find_ht_capability() in drivers/pci/quirks.c
PCI: Only check the HT capability bits in mpic.c
Michael Halcrow (1):
fsstack: Remove inode copy
Michael Holzheu (3):
[S390] Fix reboot hang on LPARs
[S390] Fix reboot hang
[S390] Save prefix register for dump on panic
Michael Riepe (3):
KVM: Do not export unsupported msrs to userspace
KVM: Force real-mode cs limit to 64K
KVM: Handle p5 mce msrs
Mike Miller (2):
cciss: set default raid level when reading geometry fails
cciss: fix XFER_READ/XFER_WRITE in do_cciss_request
Miklos Szeredi (1):
fuse: remove clear_page_dirty() call
NeilBrown (1):
md: fix a few problems with the interface (sysfs and ioctl) to md
Nick Piggin (1):
mm: more rmap debugging
Nickolay V. Shmyrev (1):
[ALSA] snd_hda_intel 3stack mode for ASUS P5P-L2
Nigel Cunningham (1):
Fix swapped parameters in mm/vmscan.c
OGAWA Hirofumi (1):
arch/i386/pci/mmconfig.c tlb flush fix
Oleg Nesterov (1):
sys_mincore: s/max/min/
Oliver Neukum (3):
USB: fix transvibrator disconnect race
USB: removing ifdefed code from gl620a
USB: mutexification of usblp
Olivier Galibert (1):
bluetooth: add support for another Kensington dongle
Patrick Caulfield (1):
[DLM] fix compile warning
Paul Jackson (1):
CONFIG_VM_EVENT_COUNTER comment decrustify
Paul Mackerras (2):
[POWERPC] Fix register save area alignment for swapcontext syscall
gxt4500: Fix colormap and PLL setting, support GXT6000P
Paul Moore (2):
NetLabel: perform input validation earlier on CIPSOv4 DOI add ops
NetLabel: correctly fill in unused CIPSOv4 level and category mappings
Pavel Machek (1):
[ARM] 4035/1: fix collie compilation
Peer Chen (1):
[libata] Move some PCI IDs from sata_nv to ahci
Peter Korsgaard (1):
serial/uartlite: Only enable port if request_port succeeded
Peter Williams (1):
sched: improve efficiency of sched_fork()
Peter Zijlstra (1):
Fix up page_mkclean_one(): virtual caches, s390
Petko Manolov (1):
USB: rtl8150 new device id
Ping Cheng (1):
USB: fix Wacom Intuos3 4x6 bugs
Prarit Bhargava (1):
ACPI: dock: Fix symbol conflict between acpiphp and dock
Rafael J. Wysocki (1):
ACPI: S4: Use "platform" rather than "shutdown" mode by default
Ralf Baechle (8):
[AX.25]: Mark all kmalloc users __must_check
[AX.25]: Fix unchecked ax25_protocol_register uses.
[AX.25]: Fix unchecked ax25_listen_register uses
[AX.25]: Fix unchecked nr_add_node uses.
[AX.25]: Fix unchecked ax25_linkfail_register uses
[AX.25]: Fix unchecked rose_add_loopback_node uses
[AX.25]: Fix unchecked rose_add_loopback_neigh uses
PCI legacy resource fix
Ralph Wuerthner (1):
[S390] zcrypt: module unload fixes.
Randy Dunlap (3):
ACPI: make ec_transaction not extern
fix kernel-doc warnings in 2.6.20-rc1
kernel-doc: allow unnamed structs/unions
Remy Bruno (1):
[ALSA] hdsp: precise_ptr control switched off by default
Richard Purdie (1):
[ARM] 4034/1: pxafb: Fix compile errors
Robert P. J. Day (1):
Add a new section to CodingStyle, promoting include/linux/kernel.h
Roland Dreier (3):
IB: Fix ib_dma_alloc_coherent() wrapper
IB/srp: Fix FMR mapping for 32-bit kernels and addresses above 4G
IB/mthca: Use DEFINE_MUTEX() instead of mutex_init()
Russell King (4):
[ARM] Add more syscalls
[ARM] Fix BUG()s in ioremap() code
[ARM] Fix warnings from asm/system.h
PCI: use /sys/bus/pci/drivers/<driver>/new_id first
Satoru Takeuchi (1):
ACPI: update comment
Sean Young (1):
USB: Fix oops in PhidgetServo
Sridhar Samudrala (1):
[SCTP]: Don't export include/linux/sctp.h to userspace.
Stefan Bader (1):
[S390] cio: css_register_subchannel race.
Stephen Rothwell (6):
[POWERPC] iSeries: fix viodasd init
[POWERPC] iSeries: fix viotape init
[POWERPC] iSeries: fix iseries_veth init
[POWERPC] iSeries: fix viocd init
[POWERPC] iSeries: fix viocons init
[POWERPC] iSeries: fix CONFIG_VIOPATH dependency
Steven Whitehouse (1):
[GFS2] Fix Kconfig
Takamasa Ohtake (1):
USB: ohci handles hardware faults during root port resets
Takashi Iwai (11):
[ALSA] hda-codec - Fix wrong error checks in patch_{realtek,analog}.c
[ALSA] hda-codec - Don't return error at initialization of modem codec
[ALSA] hda-codec - Fix a typo
[ALSA] hda-codec - Add model for HP q965
[ALSA] hda-codec - Fix model for ASUS V1j laptop
[ALSA] hda-codec - Fix detection of supported sample rates
[ALSA] hda-codec - Verbose proc output for PCM parameters
[ALSA] ac97 - Fix potential negative array index
[ALSA] Fix races in PCM OSS emulation
[ALSA] Fix invalid assignment of PCI revision
[ALSA] Remove IRQF_DISABLED for shared PCI irqs
Tejun Heo (6):
ata_piix: use piix_host_stop() in ich_pata_ops
libata: don't initialize sg in ata_exec_internal() if DMA_NONE (take #2)
ahci: do not mangle saved HOST_CAP while resetting controller
libata: clean up variable name usage in xlat related functions
libata: kill @cdb argument from xlat methods
libata: take scmd->cmd_len into account when translating SCSI commands
Thomas Gleixner (1):
genirq: fix irq flow handler uninstall
Thomas Tuttle (1):
ACPI: Implement acpi_video_get_next_level()
Tim Chen (1):
sched: remove __cpuinitdata anotation to cpu_isolated_map
Tobias Klauser (2):
[ALSA] sound/usb/usbaudio: Handle return value of usb_register()
Add cscope generated files to .gitignore
Tony Olech (1):
USB: u132-hcd/ftdi-elan: add support for Option GT 3G Quad card
Ursula Braun (1):
[S390] Hipersocket multicast queue: make sure outbound handler is called
Vadim Lobanov (1):
fdtable: Provide free_fdtable() wrapper
Venkatesh Pallipadi (2):
[CPUFREQ] Trivial cleanup for acpi read/write port in acpi-cpufreq.c
kref refcnt and false positives
Vitaly Wool (3):
[POWERPC] Update MTD OF documentation
USB: OHCI support for PNX8550
smc911x: fix netpoll compilation faliure
Wojtek Kaniewski (3):
USB: at91_udc: allow drivers that support high speed
USB: at91_udc: Cleanup variables after failure in usb_gadget_register_driver()
USB: at91_udc: Additional checks
Yan Burman (1):
[TG3]: replace kmalloc+memset with kzalloc
Yasunori Goto (3):
handle SLOB with sparsemen
compile error of register_memory()
memory hotplug: fix compile error for i386 with NUMA config
Yu Luming (1):
ACPI: video: Add dev argument for backlight_device_register
[email protected] (1):
ACPI: dock: Add a docked sysfs file to the dock driver.
On 12/24/06, Linus Torvalds <[email protected]> wrote:
>
> Ok,
> it's a couple of days delayed, because we've been trying to figure out
> what is up with the rtorrent hash failures since 2.6.18.3. I don't think
> we've made any progress, but we've cleaned up a number of suspects in the
> meantime.
>
> It's a bit sad, if only because I was really hoping to make 2.6.20 an easy
> release, and held back on merging some stuff during the merge window for
> that reason. And now we're battling something that was introduced much
> earlier..
>
> Now, practically speaking this isn't likely to affect a lot of people, but
> it's still a worrisome problem, and we've had "top people" looking at it.
> And they'll continue, but xmas is coming.
>
> In the meantime, we'll continue with the stabilization, and this mainly
> does some driver updates (usb, sound, dri, pci hotplug) and ACPI updates
> (much of the latter syntactic cleanups). And arm and powerpc updates.
>
> Shortlog appended.
>
> For developers: if you sent me a patch, and I didn't apply it, it was
> probably just missed because I concentrated on other issues. So pls
> re-send.. Unless I explicitly told you that I'm not going to pull it due
> to the merge window being over, of course ;)
>
> Linus
[shortlog snipped]
As already reported multiple times, including at -rc1 time...
still need this libata-sff.c patch:
http://marc.theaimsgroup.com/?l=linux-kernel&m=116343564202844&q=raw
to have my root device detected, ata_piix probe would otherwise
fail as described in this thread:
http://www.ussg.iu.edu/hypermail/linux/kernel/0612.0/0690.html
Enjoy the holiday season,
--alessandro
"...when I get it, I _get_ it"
(Lara Eidemiller)
Alessandro Suardi wrote:
> On 12/24/06, Linus Torvalds <[email protected]> wrote:
>>
>> Ok,
>> it's a couple of days delayed, because we've been trying to figure out
>> what is up with the rtorrent hash failures since 2.6.18.3. I don't think
>> we've made any progress, but we've cleaned up a number of suspects in the
>> meantime.
>>
>> It's a bit sad, if only because I was really hoping to make 2.6.20 an
>> easy
>> release, and held back on merging some stuff during the merge window for
>> that reason. And now we're battling something that was introduced much
>> earlier..
>>
>> Now, practically speaking this isn't likely to affect a lot of people,
>> but
>> it's still a worrisome problem, and we've had "top people" looking at it.
>> And they'll continue, but xmas is coming.
>>
>> In the meantime, we'll continue with the stabilization, and this mainly
>> does some driver updates (usb, sound, dri, pci hotplug) and ACPI updates
>> (much of the latter syntactic cleanups). And arm and powerpc updates.
>>
>> Shortlog appended.
>>
>> For developers: if you sent me a patch, and I didn't apply it, it was
>> probably just missed because I concentrated on other issues. So pls
>> re-send.. Unless I explicitly told you that I'm not going to pull it due
>> to the merge window being over, of course ;)
>>
>> Linus
>
> [shortlog snipped]
>
> As already reported multiple times, including at -rc1 time...
>
> still need this libata-sff.c patch:
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=116343564202844&q=raw
>
> to have my root device detected, ata_piix probe would otherwise
> fail as described in this thread:
>
> http://www.ussg.iu.edu/hypermail/linux/kernel/0612.0/0690.html
I've got a patch that should work for those cases. Alan's patch
contained some bugs.
Jeff
Linus Torvalds <[email protected]> writes:
> Yu Luming (1):
> ACPI: video: Add dev argument for backlight_device_register
Fix compilation of via-pmu-backlight.
Signed-off-by: Andreas Schwab <[email protected]>
---
drivers/macintosh/via-pmu-backlight.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.20-rc2/drivers/macintosh/via-pmu-backlight.c
===================================================================
--- linux-2.6.20-rc2.orig/drivers/macintosh/via-pmu-backlight.c 2006-11-30 23:33:39.000000000 +0100
+++ linux-2.6.20-rc2/drivers/macintosh/via-pmu-backlight.c 2006-12-24 17:58:18.000000000 +0100
@@ -147,7 +147,7 @@ void __init pmu_backlight_init()
snprintf(name, sizeof(name), "pmubl");
- bd = backlight_device_register(name, NULL, &pmu_backlight_data);
+ bd = backlight_device_register(name, NULL, NULL, &pmu_backlight_data);
if (IS_ERR(bd)) {
printk("pmubl: Backlight registration failed\n");
goto error;
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Hi!
> Rafael J. Wysocki (1):
> ACPI: S4: Use "platform" rather than "shutdown" mode by default
...platform is right thing to do, but it is also "more aggresive" than
"shutdown" -- it needs bigger chunk of ACPI BIOS to work properly.
So, it would be nice to test 2.6.20-rc2 on your favourite system (if
it breaks, try if echo "shutdown" > /sys/power/disk fixes it), and
report results. Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> The dmesg from the client machine is attached.
Now, really.
BTW, I am using NFSv4 exported async from the server and mounted
without any extra options on the client.
florin
--
Bruce Schneier expects the Spanish Inquisition.
http://geekz.co.uk/schneierfacts/fact/163
On Mon, 2006-12-25 at 16:56 -0600, Florin Iucha wrote:
> > The dmesg from the client machine is attached.
>
> Now, really.
>
> BTW, I am using NFSv4 exported async from the server and mounted
> without any extra options on the client.
>
> florin
Doesn't look like it has much to do with NFS. The Oopses appear mainly
to be occurring when assorted ext3 code calls submit_bio(). Was that the
entire Oops text?
Cheers
Trond
On Tue, Dec 26, 2006 at 12:06:58AM +0100, Trond Myklebust wrote:
> On Mon, 2006-12-25 at 16:56 -0600, Florin Iucha wrote:
> > BTW, I am using NFSv4 exported async from the server and mounted
> > without any extra options on the client.
>
> Doesn't look like it has much to do with NFS. The Oopses appear mainly
> to be occurring when assorted ext3 code calls submit_bio(). Was that the
> entire Oops text?
Yes, that was the entire oops text. NFS appeared on the stack trace
and I thought I might be useful to know more about the code paths.
florin
--
Bruce Schneier expects the Spanish Inquisition.
http://geekz.co.uk/schneierfacts/fact/163
On Mon, 25 Dec 2006 16:56:16 -0600
[email protected] (Florin Iucha) wrote:
> > The dmesg from the client machine is attached.
>
> Now, really.
>
> BTW, I am using NFSv4 exported async from the server and mounted
> without any extra options on the client.
>
> florin
>
> --
> Bruce Schneier expects the Spanish Inquisition.
> http://geekz.co.uk/schneierfacts/fact/163
>
>
> [the_oops text/plain (9.9KB)]
> [ 2844.871895] BUG: scheduling while atomic: cp/0x20000000/2965
> [ 2844.871900]
> [ 2844.871901] Call Trace:
> [ 2844.871910] [<ffffffff8015b97d>] __sched_text_start+0x5d/0x7a6
> [ 2844.871914] [<ffffffff8012f6b0>] submit_bio+0x84/0x8b
> [ 2844.871918] [<ffffffff801f8ea6>] ext3_get_block+0x0/0xe4
> [ 2844.871922] [<ffffffff80112933>] __pagevec_lru_add+0xb6/0xc6
> [ 2844.871927] [<ffffffff801c02f0>] mpage_bio_submit+0x22/0x26
> [ 2844.871931] [<ffffffff8012cb30>] unix_poll+0x0/0xa4
> [ 2844.871936] [<ffffffff8017d801>] __cond_resched+0x1c/0x44
> [ 2844.871940] [<ffffffff8015c1d0>] cond_resched+0x29/0x30
> [ 2844.871943] [<ffffffff8015dd92>] __reacquire_kernel_lock+0x26/0x44
> [ 2844.871948] [<ffffffff8015c169>] thread_return+0xa3/0xe1
> [ 2844.871953] [<ffffffff80116664>] unlock_page+0x9/0x26
> [ 2844.871957] [<ffffffff8017d801>] __cond_resched+0x1c/0x44
> [ 2844.871961] [<ffffffff8015c1d0>] cond_resched+0x29/0x30
> [ 2844.871965] [<ffffffff8019e8b6>] generic_writepages+0x113/0x2d8
> [ 2844.871970] [<ffffffff8022771c>] nfs_writepage+0x0/0x22
> [ 2844.871976] [<ffffffff802280ff>] nfs_writepages+0x45/0x13c
> [ 2844.871980] [<ffffffff801536e6>] do_writepages+0x20/0x2d
> [ 2844.871984] [<ffffffff801487be>] __filemap_fdatawrite_range+0x51/0x5b
> [ 2844.871989] [<ffffffff8019ca9b>] filemap_write_and_wait+0x17/0x31
> [ 2844.871993] [<ffffffff80220948>] nfs_setattr+0x98/0x108
> [ 2844.871996] [<ffffffff80129c6e>] mntput_no_expire+0x19/0x7b
> [ 2844.872000] [<ffffffff8010dab9>] link_path_walk+0xc5/0xd7
> [ 2844.872005] [<ffffffff8010d340>] current_fs_time+0x3b/0x40
> [ 2844.872009] [<ffffffff80129b48>] notify_change+0x122/0x22f
> [ 2844.872014] [<ffffffff801bb806>] do_utimes+0x106/0x129
> [ 2844.872019] [<ffffffff8010ac5b>] vfs_read+0xaa/0x152
> [ 2844.872023] [<ffffffff801bb865>] sys_futimesat+0x3c/0x4b
> [ 2844.872027] [<ffffffff8015671e>] system_call+0x7e/0x83
> [ 2844.872030]
This is the second report we've had where bit 29 of ->preempt_count is
getting set. I don't think there's any legitimate way in which that bit
can get set. (Ingo?)
I'd suggested that the first report (which was in i386 iirc) was due to
memory corruption (hardware or software). And this might also be a
hardware error, but that's looking pretty unlikely now.
If this is real, it's going to be hard to find, unless someone finds a
way to make it happen with some repeatability.
* Andrew Morton <[email protected]> wrote:
> > [ 2844.871895] BUG: scheduling while atomic: cp/0x20000000/2965
> This is the second report we've had where bit 29 of ->preempt_count is
> getting set. I don't think there's any legitimate way in which that
> bit can get set. (Ingo?)
It's not legitimate (the highest legitimate bit is PREEMPT_ACTIVE, bit
28). Nor can i think of any bug scenario barring outright memory
corruption (either hardware or kernel induced) that could cause this.
It's quite hard to trigger bit 29 there via any of the scheduling
mechanisms: either the preempt count would have to underflow massively
/and/ avoid detection during that undflow (sheer impossible) or the
HARDIRQ_COUNT would have to overflow to more than 4096 (again near
impossible to trigger), and simultaneously the softirq and preempt count
would have to overflow by 256 /at once/, or underflow by 1 at once. The
likelyhood of that makes the likelyhood of GPL-ed Windows a sure bet in
comparison.
So my guess would still be memory corruption of some sort, or some
really weird compiler bug. We just recently mandated REGPARM on i386 for
example, it would be interesting to know whether an older (say 2.6.18 or
19) config had CONFIG_REGPARM enabled or not? Regparm can also tax the
hardware (the CPU in particular) a bit more.
Ingo
On Tue, Dec 26, 2006 at 01:40:19PM +0100, Ingo Molnar wrote:
>
> * Andrew Morton <[email protected]> wrote:
>
> > > [ 2844.871895] BUG: scheduling while atomic: cp/0x20000000/2965
>
> > This is the second report we've had where bit 29 of ->preempt_count is
> > getting set. I don't think there's any legitimate way in which that
> > bit can get set. (Ingo?)
>
> It's not legitimate (the highest legitimate bit is PREEMPT_ACTIVE, bit
> 28). Nor can i think of any bug scenario barring outright memory
> corruption (either hardware or kernel induced) that could cause this.
> It's quite hard to trigger bit 29 there via any of the scheduling
> mechanisms: either the preempt count would have to underflow massively
> /and/ avoid detection during that undflow (sheer impossible) or the
> HARDIRQ_COUNT would have to overflow to more than 4096 (again near
> impossible to trigger), and simultaneously the softirq and preempt count
> would have to overflow by 256 /at once/, or underflow by 1 at once. The
> likelyhood of that makes the likelyhood of GPL-ed Windows a sure bet in
> comparison.
>
> So my guess would still be memory corruption of some sort, or some
> really weird compiler bug. We just recently mandated REGPARM on i386 for
> example, it would be interesting to know whether an older (say 2.6.18 or
> 19) config had CONFIG_REGPARM enabled or not? Regparm can also tax the
> hardware (the CPU in particular) a bit more.
This is my year-old workstation that I've build from good parts (Asus
A8N-SLI premium, OCZ memory), not overclocked, not overheated (it is
in a Antec P180 case with 12 cm fans -> CPU max is 43'C when not used
for my hour-long simulations). I will leave it do memtest for a
couple hours.
The compiler is "gcc version 4.1.2 20061028 (prerelease) (Debian
4.1.1-19)" and the .config is attached.
florin
--
Bruce Schneier expects the Spanish Inquisition.
http://geekz.co.uk/schneierfacts/fact/163
* Florin Iucha <[email protected]> wrote:
> This is my year-old workstation that I've build from good parts (Asus
> A8N-SLI premium, OCZ memory), not overclocked, not overheated (it is
> in a Antec P180 case with 12 cm fans -> CPU max is 43'C when not used
> for my hour-long simulations). I will leave it do memtest for a
> couple hours.
>
> The compiler is "gcc version 4.1.2 20061028 (prerelease) (Debian
> 4.1.1-19)" and the .config is attached.
could you send a config that you used with the 2.6.19 (or 2.6.18)
kernel?
Ingo
On Tue, 26 Dec 2006 13:40:19 +0100 Ingo Molnar wrote:
>
> * Andrew Morton <[email protected]> wrote:
>
> > > [ 2844.871895] BUG: scheduling while atomic: cp/0x20000000/2965
>
> > This is the second report we've had where bit 29 of ->preempt_count is
> > getting set. I don't think there's any legitimate way in which that
> > bit can get set. (Ingo?)
First one was me, on x86_64 UP. I ran memtest86 many hours
with no problems found. It's an almost-new system fwiw.
> It's not legitimate (the highest legitimate bit is PREEMPT_ACTIVE, bit
> 28). Nor can i think of any bug scenario barring outright memory
> corruption (either hardware or kernel induced) that could cause this.
> It's quite hard to trigger bit 29 there via any of the scheduling
> mechanisms: either the preempt count would have to underflow massively
> /and/ avoid detection during that undflow (sheer impossible) or the
> HARDIRQ_COUNT would have to overflow to more than 4096 (again near
> impossible to trigger), and simultaneously the softirq and preempt count
> would have to overflow by 256 /at once/, or underflow by 1 at once. The
> likelyhood of that makes the likelyhood of GPL-ed Windows a sure bet in
> comparison.
>
> So my guess would still be memory corruption of some sort, or some
> really weird compiler bug. We just recently mandated REGPARM on i386 for
> example, it would be interesting to know whether an older (say 2.6.18 or
> 19) config had CONFIG_REGPARM enabled or not? Regparm can also tax the
> hardware (the CPU in particular) a bit more.
I've had at least one more occurrence of it:
[ 78.804940] BUG: scheduling while atomic: kbd/0x20000000/3444
[ 78.804944]
[ 78.804945] Call Trace:
[ 78.804952] [<ffffffff80521ae0>] __sched_text_start+0x60/0xae0
[ 78.804958] [<ffffffff8022c2df>] default_wake_function+0xd/0xf
[ 78.804962] [<ffffffff80229504>] __wake_up_common+0x3e/0x68
[ 78.804966] [<ffffffff8022c72f>] __cond_resched+0x1c/0x44
[ 78.804969] [<ffffffff8052266b>] cond_resched+0x29/0x30
[ 78.804973] [<ffffffff805244d6>] __reacquire_kernel_lock+0x29/0x49
[ 78.804977] [<ffffffff80522603>] thread_return+0xa3/0xe2
[ 78.804981] [<ffffffff8022c72f>] __cond_resched+0x1c/0x44
[ 78.804985] [<ffffffff8052266b>] cond_resched+0x29/0x30
[ 78.804989] [<ffffffff803a8f6e>] device_add+0x3e1/0x53e
[ 78.804993] [<ffffffff803a90e4>] device_register+0x19/0x1d
[ 78.804996] [<ffffffff803a91c7>] device_create+0xdf/0x110
[ 78.805001] [<ffffffff8037fd67>] set_palette+0x5c/0x60
[ 78.805005] [<ffffffff8037fc38>] reset_terminal+0x1f0/0x1f5
[ 78.805010] [<ffffffff8037b78e>] vcs_make_sysfs+0x5e/0x62
[ 78.805014] [<ffffffff80380fc2>] con_open+0x88/0x9b
[ 78.805018] [<ffffffff803765b2>] tty_open+0x19c/0x310
[ 78.805022] [<ffffffff8027b4f9>] chrdev_open+0x164/0x19d
[ 78.805026] [<ffffffff8027b395>] chrdev_open+0x0/0x19d
[ 78.805030] [<ffffffff802772c9>] __dentry_open+0xe9/0x1ba
[ 78.805034] [<ffffffff8027742f>] nameidata_to_filp+0x2d/0x3f
[ 78.805038] [<ffffffff80277477>] do_filp_open+0x36/0x46
[ 78.805042] [<ffffffff8027714b>] get_unused_fd+0x70/0x105
[ 78.805046] [<ffffffff802774d6>] do_sys_open+0x4f/0xd7
[ 78.805050] [<ffffffff80277587>] sys_open+0x1b/0x1d
[ 78.805054] [<ffffffff8020996e>] system_call+0x7e/0x83
---
~Randy
* Randy Dunlap <[email protected]> wrote:
> I've had at least one more occurrence of it:
>
> [ 78.804940] BUG: scheduling while atomic: kbd/0x20000000/3444
> [ 78.804944]
> [ 78.804945] Call Trace:
ok, i can think of a simpler scenario: add_preempt_count(PREEMPT_ACTIVE)
/twice/, nested into each other.
Ingo
* Ingo Molnar <[email protected]> wrote:
> > I've had at least one more occurrence of it:
> >
> > [ 78.804940] BUG: scheduling while atomic: kbd/0x20000000/3444
> > [ 78.804944]
> > [ 78.804945] Call Trace:
>
> ok, i can think of a simpler scenario:
> add_preempt_count(PREEMPT_ACTIVE) /twice/, nested into each other.
doh - the BKL! That does a down() in a PREEMPT_ACTIVE section, which can
trigger cond_resched(). The fix is to check for PREEMPT_ACTIVE in
cond_resched(). (and only in cond_resched())
Updated fix (against -rc2) attached.
Ingo
---------------------->
Subject: [patch] sched: fix cond_resched_softirq() offset
From: Ingo Molnar <[email protected]>
remove the __resched_legal() check: it is conceptually broken.
The biggest problem it had is that it can mask buggy cond_resched()
calls. A cond_resched() call is only legal if we are not in an
atomic context, with two narrow exceptions:
- if the system is booting
- a reacquire_kernel_lock() down() done while PREEMPT_ACTIVE is set
But __resched_legal() hid this and just silently returned whenever
these primitives were called from invalid contexts. (Same goes for
cond_resched_locked() and cond_resched_softirq()).
furthermore, the __legal_resched(0) call was buggy in that it caused
unnecessarily long softirq latencies via cond_resched_softirq(). (which
is only called from softirq-off sections, hence the code did nothing.)
the fix is to resurrect the efficiency of the might_sleep checks and to
only allow the narrow exceptions.
Signed-off-by: Ingo Molnar <[email protected]>
---
kernel/sched.c | 18 ++++--------------
1 file changed, 4 insertions(+), 14 deletions(-)
Index: linux/kernel/sched.c
===================================================================
--- linux.orig/kernel/sched.c
+++ linux/kernel/sched.c
@@ -4617,17 +4617,6 @@ asmlinkage long sys_sched_yield(void)
return 0;
}
-static inline int __resched_legal(int expected_preempt_count)
-{
-#ifdef CONFIG_PREEMPT
- if (unlikely(preempt_count() != expected_preempt_count))
- return 0;
-#endif
- if (unlikely(system_state != SYSTEM_RUNNING))
- return 0;
- return 1;
-}
-
static void __cond_resched(void)
{
#ifdef CONFIG_DEBUG_SPINLOCK_SLEEP
@@ -4647,7 +4636,8 @@ static void __cond_resched(void)
int __sched cond_resched(void)
{
- if (need_resched() && __resched_legal(0)) {
+ if (need_resched() && !(preempt_count() & PREEMPT_ACTIVE) &&
+ system_state == SYSTEM_RUNNING) {
__cond_resched();
return 1;
}
@@ -4673,7 +4663,7 @@ int cond_resched_lock(spinlock_t *lock)
ret = 1;
spin_lock(lock);
}
- if (need_resched() && __resched_legal(1)) {
+ if (need_resched() && system_state == SYSTEM_RUNNING) {
spin_release(&lock->dep_map, 1, _THIS_IP_);
_raw_spin_unlock(lock);
preempt_enable_no_resched();
@@ -4689,7 +4679,7 @@ int __sched cond_resched_softirq(void)
{
BUG_ON(!in_softirq());
- if (need_resched() && __resched_legal(0)) {
+ if (need_resched() && system_state == SYSTEM_RUNNING) {
raw_local_irq_disable();
_local_bh_enable();
raw_local_irq_enable();
Hi.
Can you confirm that the problem I mentioned in
http://lkml.org/lkml/2006/12/24/32 is the same?
Best regards,
Fabio
On 12/26/06, Ingo Molnar <[email protected]> wrote:
>
> * Ingo Molnar <[email protected]> wrote:
>
> > > I've had at least one more occurrence of it:
> > >
> > > [ 78.804940] BUG: scheduling while atomic: kbd/0x20000000/3444
> > > [ 78.804944]
> > > [ 78.804945] Call Trace:
> >
> > ok, i can think of a simpler scenario:
> > add_preempt_count(PREEMPT_ACTIVE) /twice/, nested into each other.
>
> doh - the BKL! That does a down() in a PREEMPT_ACTIVE section, which can
> trigger cond_resched(). The fix is to check for PREEMPT_ACTIVE in
> cond_resched(). (and only in cond_resched())
>
> Updated fix (against -rc2) attached.
>
> Ingo
>
> ---------------------->
> Subject: [patch] sched: fix cond_resched_softirq() offset
> From: Ingo Molnar <[email protected]>
>
> remove the __resched_legal() check: it is conceptually broken.
> The biggest problem it had is that it can mask buggy cond_resched()
> calls. A cond_resched() call is only legal if we are not in an
> atomic context, with two narrow exceptions:
>
> - if the system is booting
> - a reacquire_kernel_lock() down() done while PREEMPT_ACTIVE is set
>
> But __resched_legal() hid this and just silently returned whenever
> these primitives were called from invalid contexts. (Same goes for
> cond_resched_locked() and cond_resched_softirq()).
>
> furthermore, the __legal_resched(0) call was buggy in that it caused
> unnecessarily long softirq latencies via cond_resched_softirq(). (which
> is only called from softirq-off sections, hence the code did nothing.)
>
> the fix is to resurrect the efficiency of the might_sleep checks and to
> only allow the narrow exceptions.
>
> Signed-off-by: Ingo Molnar <[email protected]>
> ---
> kernel/sched.c | 18 ++++--------------
> 1 file changed, 4 insertions(+), 14 deletions(-)
>
> Index: linux/kernel/sched.c
> ===================================================================
> --- linux.orig/kernel/sched.c
> +++ linux/kernel/sched.c
> @@ -4617,17 +4617,6 @@ asmlinkage long sys_sched_yield(void)
> return 0;
> }
>
> -static inline int __resched_legal(int expected_preempt_count)
> -{
> -#ifdef CONFIG_PREEMPT
> - if (unlikely(preempt_count() != expected_preempt_count))
> - return 0;
> -#endif
> - if (unlikely(system_state != SYSTEM_RUNNING))
> - return 0;
> - return 1;
> -}
> -
> static void __cond_resched(void)
> {
> #ifdef CONFIG_DEBUG_SPINLOCK_SLEEP
> @@ -4647,7 +4636,8 @@ static void __cond_resched(void)
>
> int __sched cond_resched(void)
> {
> - if (need_resched() && __resched_legal(0)) {
> + if (need_resched() && !(preempt_count() & PREEMPT_ACTIVE) &&
> + system_state == SYSTEM_RUNNING) {
> __cond_resched();
> return 1;
> }
> @@ -4673,7 +4663,7 @@ int cond_resched_lock(spinlock_t *lock)
> ret = 1;
> spin_lock(lock);
> }
> - if (need_resched() && __resched_legal(1)) {
> + if (need_resched() && system_state == SYSTEM_RUNNING) {
> spin_release(&lock->dep_map, 1, _THIS_IP_);
> _raw_spin_unlock(lock);
> preempt_enable_no_resched();
> @@ -4689,7 +4679,7 @@ int __sched cond_resched_softirq(void)
> {
> BUG_ON(!in_softirq());
>
> - if (need_resched() && __resched_legal(0)) {
> + if (need_resched() && system_state == SYSTEM_RUNNING) {
> raw_local_irq_disable();
> _local_bh_enable();
> raw_local_irq_enable();
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
This email lists some known regressions in 2.6.20-rc2 compared to 2.6.19
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 : selinux networking: sleeping function called from invalid context
References : http://lkml.org/lkml/2006/12/24/78
Submitter : "Adam J. Richter" <[email protected]>
Caused-By : Paul Moore <[email protected]>
Handled-By : Parag Warudkar <[email protected]>
Patch : http://lkml.org/lkml/2006/12/24/89
Status : patch available
Subject : KVM Oops
References : http://lkml.org/lkml/2006/12/27/171
Submitter : Parag Warudkar <[email protected]>
Handled-By : Avi Kivity <[email protected]>
Status : patch available
Subject : drivers/macintosh/via-pmu-backlight.c compilation broken
References : http://lkml.org/lkml/2006/12/24/49
Submitter : Andreas Schwab <[email protected]>
Caused-By : Yu Luming <[email protected]>
commit 519ab5f2be65b72cf12ae99c89752bbe79b44df6
Handled-By : Andreas Schwab <[email protected]>
Patch : http://lkml.org/lkml/2006/12/24/49
Status : patch available
Subject : NULL dereference in ieee80211softmac_get_network_by_bssid_locked
ieee80211softmac_wx.c typo: mutex_lock -> mutex_unlock
References : http://bugzilla.kernel.org/show_bug.cgi?id=7657
http://lkml.org/lkml/2006/12/16/141
http://lkml.org/lkml/2006/12/24/43
Submitter : Michael Bommarito <[email protected]>
Ben Collins <[email protected]>
Martin Pitt <[email protected]>
Handled-By : Michael Bommarito <[email protected]>
Larry Finger <[email protected]
Patch : http://bugzilla.kernel.org/show_bug.cgi?id=7657
Status : patches available
Subject : BUG at drivers/scsi/scsi_lib.c:1118 by "pktsetup dvd /dev/sr0"
References : http://bugzilla.kernel.org/show_bug.cgi?id=7667
Submitter : Laurent Riffard <[email protected]>
Caused-By : Christoph Hellwig <[email protected]>
commit 3b00315799d78f76531b71435fbc2643cd71ae4c
Handled-By : Christoph Hellwig <[email protected]>
Patch : http://bugzilla.kernel.org/show_bug.cgi?id=7667
Status : patch available
This email lists some known regressions in 2.6.20-rc2 compared to 2.6.19.
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_MULTITHREAD_PROBE breakage
References : http://lkml.org/lkml/2006/12/12/21
Submitter : Ben Castricum <[email protected]>
Caused-By : Greg Kroah-Hartman <[email protected]>
commit 009af1ff78bfc30b9a27807dd0207fc32848218a
Status : known to break many drivers; revert?
Subject : Acer Extensa 3002 WLMi: 'shutdown -h now' reboots the system
References : http://lkml.org/lkml/2006/12/25/40
Submitter : Berthold Cogel <[email protected]>
Status : unknown
Subject : i386: Oops in __find_get_block()
References : http://lkml.org/lkml/2006/12/16/138
Submitter : Ben Collins <[email protected]>
Daniel Holbach <[email protected]>
Status : unknown
Subject : ftp: get or put stops during file-transfer
References : http://lkml.org/lkml/2006/12/16/174
Submitter : Komuro <[email protected]>
Status : unknown
Subject : forcedeth.c 0.59: problem with sideband managment
References : http://bugzilla.kernel.org/show_bug.cgi?id=7684
Submitter : Michael Reske <[email protected]>
Handled-By : Ayaz Abdulla <[email protected]>
Status : problem is being debugged
Subject : x86_64 boot failure: "IO-APIC + timer doesn't work"
References : http://lkml.org/lkml/2006/12/16/101
Submitter : Tobias Diedrich <[email protected]>
Caused-By : Andi Kleen <[email protected]>
commit b026872601976f666bae77b609dc490d1834bf77
Handled-By : Yinghai Lu <[email protected]>
"Eric W. Biederman" <[email protected]>
Status : problem is being debugged
Subject : kernel panics on boot (libata-sff)
References : http://lkml.org/lkml/2006/12/3/99
http://lkml.org/lkml/2006/12/14/153
http://lkml.org/lkml/2006/12/24/33
Submitter : Alessandro Suardi <[email protected]>
Caused-By : Alan Cox <[email protected]>
commit 368c73d4f689dae0807d0a2aa74c61fd2b9b075f
Handled-By : Alan Cox <[email protected]>
Steve Wise <[email protected]>
Alessandro Suardi <[email protected]>
Status : people are working on a fix
On Thu, Dec 28, 2006 at 11:39:09PM +0100, Adrian Bunk wrote:
>
> Subject : PCI_MULTITHREAD_PROBE breakage
> References : http://lkml.org/lkml/2006/12/12/21
> Submitter : Ben Castricum <[email protected]>
> Caused-By : Greg Kroah-Hartman <[email protected]>
> commit 009af1ff78bfc30b9a27807dd0207fc32848218a
> Status : known to break many drivers; revert?
PCI_MULTITHREAD_PROBE is now only able to be enabled if you also enable
CONFIG_BROKEN, so this can be removed from your list.
thanks,
greg k-h
On Thu, Dec 28, 2006 at 02:57:06PM -0800, Greg KH wrote:
> On Thu, Dec 28, 2006 at 11:39:09PM +0100, Adrian Bunk wrote:
> >
> > Subject : PCI_MULTITHREAD_PROBE breakage
> > References : http://lkml.org/lkml/2006/12/12/21
> > Submitter : Ben Castricum <[email protected]>
> > Caused-By : Greg Kroah-Hartman <[email protected]>
> > commit 009af1ff78bfc30b9a27807dd0207fc32848218a
> > Status : known to break many drivers; revert?
>
> PCI_MULTITHREAD_PROBE is now only able to be enabled if you also enable
> CONFIG_BROKEN, so this can be removed from your list.
In Linus' tree, it currently only depends on EXPERIMENTAL.
It seems commit 009af1ff78bfc30b9a27807dd0207fc32848218a wasn't intended
for Linus?
> thanks,
>
> greg k-h
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Fri, 29 Dec 2006, Adrian Bunk wrote:
>
> In Linus' tree, it currently only depends on EXPERIMENTAL.
>
> It seems commit 009af1ff78bfc30b9a27807dd0207fc32848218a wasn't intended
> for Linus?
I think we should just remove it.
It's broken.
Nobody cares.
If people want to do concurrent stuff at bootup, it should be the _other_
buses (like USB, IDE or SCSI or anything like that, that actually has
operations that can delay) that end up asynchronous. And I think we could
have some generic functionality for the drivers themselves to do their
probing in parallel. But I think the PCI one was just a mistake.
Linus
On Thu, Dec 28, 2006 at 03:17:53PM -0800, Linus Torvalds wrote:
>
>
> On Fri, 29 Dec 2006, Adrian Bunk wrote:
> >
> > In Linus' tree, it currently only depends on EXPERIMENTAL.
> >
> > It seems commit 009af1ff78bfc30b9a27807dd0207fc32848218a wasn't intended
> > for Linus?
>
> I think we should just remove it.
>
> It's broken.
>
> Nobody cares.
I agree, that's why I thought I had added a patch in the last PCI queue
to you to just disable the config option and was going to rip out the
code entirely for the next release. I'll make sure to add the config
option patch to the next round of PCI patches to you.
thanks,
greg k-h
Adrian Bunk <[email protected]> wrote:
> This email lists some known regressions in 2.6.20-rc2 compared to 2.6.19.
Add that on SPARC64 boot fails due to missing /dev/root. Vanilla 2.6.19 and
2.6.19.1 work fine, before 2.6.20-rc1 it broke. I checked the initrds for
both versions, the only difference "diff -Nur" finds between the unpacked
initrds are the modules themselves (obviously).
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
From: "Horst H. von Brand" <[email protected]>
Date: Thu, 28 Dec 2006 22:36:02 -0300
> Adrian Bunk <[email protected]> wrote:
> > This email lists some known regressions in 2.6.20-rc2 compared to 2.6.19.
>
> Add that on SPARC64 boot fails due to missing /dev/root. Vanilla 2.6.19 and
> 2.6.19.1 work fine, before 2.6.20-rc1 it broke. I checked the initrds for
> both versions, the only difference "diff -Nur" finds between the unpacked
> initrds are the modules themselves (obviously).
Did you report this will all relevant details on sparclinux@vger
so that the sparc64 maintainers can analyze the problem?
I didn't see the report there else I would be looking into it.
Please don't report sparc64 bugs here, thanks.
On Thu, Dec 28, 2006 at 10:36:02PM -0300, Horst H. von Brand wrote:
> Adrian Bunk <[email protected]> wrote:
> > This email lists some known regressions in 2.6.20-rc2 compared to 2.6.19.
>
> Add that on SPARC64 boot fails due to missing /dev/root. Vanilla 2.6.19 and
> 2.6.19.1 work fine, before 2.6.20-rc1 it broke. I checked the initrds for
> both versions, the only difference "diff -Nur" finds between the unpacked
> initrds are the modules themselves (obviously).
Sorry, I knew about this and somehow forgot to add it to my list.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Thu, Dec 28, 2006 at 08:51:06PM -0800, David Miller wrote:
> From: "Horst H. von Brand" <[email protected]>
> Date: Thu, 28 Dec 2006 22:36:02 -0300
>
> > Adrian Bunk <[email protected]> wrote:
> > > This email lists some known regressions in 2.6.20-rc2 compared to 2.6.19.
> >
> > Add that on SPARC64 boot fails due to missing /dev/root. Vanilla 2.6.19 and
> > 2.6.19.1 work fine, before 2.6.20-rc1 it broke. I checked the initrds for
> > both versions, the only difference "diff -Nur" finds between the unpacked
> > initrds are the modules themselves (obviously).
>
> Did you report this will all relevant details on sparclinux@vger
> so that the sparc64 maintainers can analyze the problem?
>
> I didn't see the report there else I would be looking into it.
>...
I did copy the email to both sparclinux and you when I asked Horst
whether it's still present in the latest kernel, and therefore his
answer that it does the day before yesterday should have reached you.
The thread is "Re: 2.6.19 (current from git) on SPARC64: Can't mount /".
Is there anything I can improve to catch your intention?
Is "reply with fullquote + question + adding Cc's" somehow suboptimal?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Thu, 2006-12-28 at 23:39 +0100, Adrian Bunk wrote:
> This email lists some known regressions in 2.6.20-rc2 compared to 2.6.19.
>
> 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 : i386: Oops in __find_get_block()
> References : http://lkml.org/lkml/2006/12/16/138
> Submitter : Ben Collins <[email protected]>
> Daniel Holbach <[email protected]>
> Status : unknown
I believe this is the same bug as I've seen reported about gdb. I'd have
to find the thread/information regarding it. Not sure if it was fixed
already.
There's also http://lkml.org/lkml/2006/12/21/47; the included patch break
my nVidia devices and probably all PCIX devices, so it's not right, but
something has to be done to fix ATI. My guess is a quirk to say that
pci_intx doesn't work on certain devices and should just be skipped, but
I'm not sure if it's just in combination with MSI or not.
-Daniel
*This .sig left intentionally blank*
On Fri, Dec 29, 2006 at 01:14:13PM -0500, Daniel Barkalow wrote:
> There's also http://lkml.org/lkml/2006/12/21/47; the included patch break
> my nVidia devices and probably all PCIX devices, so it's not right, but
> something has to be done to fix ATI. My guess is a quirk to say that
> pci_intx doesn't work on certain devices and should just be skipped, but
> I'm not sure if it's just in combination with MSI or not.
This:
- does not seem to be a regression and
- missing MSI support is not such a big problem.
Considering how many problems patches in this area tend to cause on
different hardware, I'm even inclined to say that such patches should
only be added during the 2 weeks merge window before -rc1.
> -Daniel
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Fri, Dec 29, 2006 at 01:07:10PM -0500, Ben Collins wrote:
> On Thu, 2006-12-28 at 23:39 +0100, Adrian Bunk wrote:
> > This email lists some known regressions in 2.6.20-rc2 compared to 2.6.19.
> >
> > 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 : i386: Oops in __find_get_block()
> > References : http://lkml.org/lkml/2006/12/16/138
> > Submitter : Ben Collins <[email protected]>
> > Daniel Holbach <[email protected]>
> > Status : unknown
>
> I believe this is the same bug as I've seen reported about gdb. I'd have
> to find the thread/information regarding it. Not sure if it was fixed
> already.
Subject : BUG at fs/buffer.c:1235 when using gdb
References : http://lkml.org/lkml/2006/12/17/134
Submitter : Andrew J. Barr <[email protected]>
Fixed-By : Jeremy Fitzhardinge <[email protected]>
Commit : 8701ea957dd2a7c309e17c8dcde3a64b92d8aec0
Status : fixed in -rc2
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Fri, 29 Dec 2006, Adrian Bunk wrote:
> On Fri, Dec 29, 2006 at 01:14:13PM -0500, Daniel Barkalow wrote:
>
> > There's also http://lkml.org/lkml/2006/12/21/47; the included patch break
> > my nVidia devices and probably all PCIX devices, so it's not right, but
> > something has to be done to fix ATI. My guess is a quirk to say that
> > pci_intx doesn't work on certain devices and should just be skipped, but
> > I'm not sure if it's just in combination with MSI or not.
>
> This:
> - does not seem to be a regression and
> - missing MSI support is not such a big problem.
>
> Considering how many problems patches in this area tend to cause on
> different hardware, I'm even inclined to say that such patches should
> only be added during the 2 weeks merge window before -rc1.
(I was only talking about the first issue/patch as being a regression,
obviously, and forgot that there was more to the email I cited.)
Ah, okay. I somehow missed that all of the devices that were reported
to break with the MSI change in mainline doesn't support MSI in mainline.
Actually, I wouldn't be surprised if this issue applied to audio on ATI
SB450 and later, which (I think) use the hda_intel driver, which supports
MSI (although I guess it's still defaulting to disabled). If this is true,
it would be a regression since 2.6.19.
The addition of a quirk to not use pci_intx with MSI on ATI PCI devices
should be safe (until 2.6.20-rc1, this was the usual kernel behavior), but
is clearly not critical if mainline doesn't use MSI with any such devices
anyway.
-Daniel
*This .sig left intentionally blank*
Adrian Bunk <[email protected]> wrote:
[...]
> Subject : BUG at fs/buffer.c:1235 when using gdb
> References : http://lkml.org/lkml/2006/12/17/134
> Submitter : Andrew J. Barr <[email protected]>
> Fixed-By : Jeremy Fitzhardinge <[email protected]>
> Commit : 8701ea957dd2a7c309e17c8dcde3a64b92d8aec0
> Status : fixed in -rc2
This I see in Fedora rawhide i686 2.6.19-1.2891.fc7 (BZ'd at
<https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220855>
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
On Fri, Dec 29, 2006 at 10:21:36PM -0300, Horst H. von Brand wrote:
> Adrian Bunk <[email protected]> wrote:
>
> [...]
>
> > Subject : BUG at fs/buffer.c:1235 when using gdb
> > References : http://lkml.org/lkml/2006/12/17/134
> > Submitter : Andrew J. Barr <[email protected]>
> > Fixed-By : Jeremy Fitzhardinge <[email protected]>
> > Commit : 8701ea957dd2a7c309e17c8dcde3a64b92d8aec0
> > Status : fixed in -rc2
>
> This I see in Fedora rawhide i686 2.6.19-1.2891.fc7 (BZ'd at
> <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220855>
2.6.19-1.2891.fc7 is based on 2.6.20-rc1-git5, and it's therefore
expected that it contains this bug.
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
This email lists some known regressions in 2.6.20-rc2 compared to 2.6.19
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 : USB keyboard unresponsive after some time
References : http://lkml.org/lkml/2006/12/25/35
http://lkml.org/lkml/2006/12/26/106
Submitter : Florin Iucha <[email protected]>
Status : unknown
Subject : BUG: scheduling while atomic
References : http://lkml.org/lkml/2006/12/26/105
Submitter : Jon Smirl <[email protected]>
Status : unknown
Subject : ALSA: No sound in KDE with intel hda
References : http://lkml.org/lkml/2006/12/30/73
Submitter : Ismail D?nmez <[email protected]>
Status : unknown
Subject : SPARC64: Can't mount /
References : http://lkml.org/lkml/2006/12/13/181
Submitter : Horst H. von Brand <[email protected]>
Status : unknown
Subject : ftp: get or put stops during file-transfer
References : http://lkml.org/lkml/2006/12/16/174
Submitter : Komuro <[email protected]>
Caused-By : YOSHIFUJI Hideaki <[email protected]>
commit cfb6eeb4c860592edd123fdea908d23c6ad1c7dc
Handled-By : YOSHIFUJI Hideaki <[email protected]>
Status : problem is being debugged
Subject : forcedeth.c 0.59: problem with sideband managment
References : http://bugzilla.kernel.org/show_bug.cgi?id=7684
Submitter : Michael Reske <[email protected]>
Handled-By : Ayaz Abdulla <[email protected]>
Status : problem is being debugged
Subject : x86_64 boot failure: "IO-APIC + timer doesn't work"
References : http://lkml.org/lkml/2006/12/16/101
Submitter : Tobias Diedrich <[email protected]>
Caused-By : Andi Kleen <[email protected]>
commit b026872601976f666bae77b609dc490d1834bf77
Handled-By : Yinghai Lu <[email protected]>
Eric W. Biederman <[email protected]>
Status : problem is being debugged
Subject : kernel panics on boot (libata-sff)
References : http://lkml.org/lkml/2006/12/3/99
http://lkml.org/lkml/2006/12/14/153
http://lkml.org/lkml/2006/12/24/33
Submitter : Alessandro Suardi <[email protected]>
Caused-By : Alan Cox <[email protected]>
commit 368c73d4f689dae0807d0a2aa74c61fd2b9b075f
Handled-By : Alan Cox <[email protected]>
Status : people are working on a fix
Subject : Acer Extensa 3002 WLMi: 'shutdown -h now' reboots the system
References : http://lkml.org/lkml/2006/12/25/40
Submitter : Berthold Cogel <[email protected]>
Status : submitter was asked for more information
31 Ara 2006 Paz 02:47 tarihinde, Adrian Bunk şunları yazmıştı:
[...]
> Subject : ALSA: No sound in KDE with intel hda
> References : http://lkml.org/lkml/2006/12/30/73
> Submitter : Ismail Dönmez <[email protected]>
> Status : unknown
Just tried with 2.6.18.6 and aRts still have no sound, there must be something
else broken on my side.
Thanks,
ismail
--
2 + 2 = 5 for very large values of 2