Linux 2.6.15-rc6

Ok,
there it is.

Slightly delayed by me being away for a week, and now Andrew is gone, but looking at the changes, they all seem to be pretty trivial, so we're on well track for doing the final 2.6.15 this year, I think. People have probably already started over-feeding with the holidays just around the corner.

The shortlog really says it all. Apart from some sparse annotations from Al, it's all random small things. But do give it a try, because Santa Claus has his CIA spooks checking y'all out, and naughty people don't get any of the loot.

Linus

----
Adam Kropelin:
hid-core: Zero-pad truncated reports

Adrian Bunk:
allow KOBJECT_UEVENT=n only if EMBEDDED drivers/base/memory.c: unexport the static (sic) memory_sysdev_class

Al Viro:
fix iomem annotations in sparc32 pcic code
sparc: vfc __iomem annotations and fixes
sparc: jsflash __user annotations
sbus/char/uctrl: missing prototypes and NULL noise removal sparc/kernel/time: __iomem annotations
sparc: NULL noise removal (ebus.c)
sun4c_memerr_reg __iomem annotations arch/sparc/kernel/led.c __user annotations
iscsi gfp_t annotations
xfs: missing gfp_t annotations
s2io: __iomem annotations for recent changes auerswald.c: %zd for size_t
em28xx: %zd for size_t
i386,amd64: mmconfig __iomem annotations
i386,amd64: ioremap.c __iomem annotations
cm4000_cs: __user annotations
dell_rbu: NULL noise removal
wdrtas.c: fix __user annotations
cyber2000fb.c __iomem annotations
arcfb __user annotations
__user annotations (booke_wdt.c)
missing prototype (mm/page_alloc.c)
Address of void __user * is void __user * *, not void * __user * ia64 sn __iomem annotations
dst_ca __user annotations, portability fixes arch/alpha/kernel/machvec_impl.h: C99 struct initializer drivers/atm/adummy.c NULL noise removal
mwave: missing __user in ioctl struct declaration drivers/input/misc/wistron_btns.c NULL noise removal arch/powerpc/kernel/syscalls.c __user annotations
ppc: booke_wdt compile fix
ppc: ppc4xx_dma DMA_MODE_{READ,WRITE} fix

Alan Stern:
UHCI: add missing memory barriers

Andi Kleen:
x86_64: Make sure hpet_address is 0 when any part of HPET initialization fails i386/x86-64: Don't call change_page_attr with a spinlock held i386/x86-64 Fall back to type 1 access when no entry found i386/x86-64 Correct for broken MCFG tables on K8 systems
x86_64: Fix 32bit thread coredumps
PCI: Fix dumb bug in mmconfig fix

Andreas Gruenbacher:
ext3: fix mount options documentation

Andreas Schwab:
KERNELRELEASE depends on CONFIG_LOCALVERSION

Andrew Morton:
blkmtd: use clear_page_dirty()
raw driver: Kconfig fix

Andrew Vasquez:
[SCSI] qla2xxx: Correct mis-handling of AENs. [SCSI] qla2xxx: Correct short-WRITE status handling.

Antonino A. Daplas:
fbcon: fix complement_mask() with 512 character map
fbcon: Add ability to save/restore graphics state
fbdev: Pan display fixes
fbcon: Avoid illegal display panning
fbdev: Shift pixel value before entering loop in cfbimageblit
fbdev: Fix incorrect unaligned access in little-endian machines

Arnaldo Carvalho de Melo:
[TCPv6]: Fix skb leak

Bartlomiej Zolnierkiewicz:
ide-disk: flush cache after calling del_gendisk()
ide: cleanup ide.h
ide: cleanup ide_driver_t
ide-cd: remove write-only cmd field from struct cdrom_info

Ben Collins:
i2o: Do not disable pci device when it's in use

Benjamin Herrenschmidt:
powerpc: Fix a huge page bug
powerpc: Remove debug code in hash path
powerpc: Fix clock spreading setting on some powermacs radeon drm: fix agp aperture map offset

Brian King:
[SCSI] fix double free of scsi request queue Fix SCSI scanning slab corruption

Christoph Lameter:
[IA64] Fix missing parameter for local_add/sub [IA64] Add __read_mostly support for IA64

Daniel Drake:
Fix listxattr() for generic security attributes via82cxxx IDE: Add VT8251 ISA bridge

Daniel Jacobowitz:
[ARM] 3205/1: Handle new EABI relocations when loading kernel modules.

Dave Airlie:
[drm] fix radeon aperture issue

Dave C Boutcher:
[SCSI] ibmvscsi kexec fix

Dave Jones:
[SERIAL] 8250_pci: Remove redundant assignment, and mark fallthrough. broken cast in parport_pc
ACPI: fix sleeping whilst atomic warnings on resume

David Gibson:
powerpc: Add missing icache flushes for hugepages
powerpc: Fix SLB flushing path in hugepage

David S. Miller:
[TCP] Vegas: timestamp before clone
[AF_PACKET]: Convert PACKET_MMAP over to vm_insert_page(). [SBUSFB]: Kill 'list' member from foo_par structs, totally unused. [IPV6] addrconf: Do not print device pointer in privacy log message. [PKT_SCHED]: Disable debug tracing logs by default in packet action API.

Deepak Saxena:
[ARM] 3191/1: Mark I/O pointer as const in __raw_reads[bwl] [ARM] 3199/1: Remove bogus function prototype from arch-pxa/irq.h

Dipankar Sarma:
add rcu_barrier() synchronization point

Dmitry Torokhov:
Input: fix an OOPS in HID driver

Eric Dumazet:
x86_64: Bug correction in populate_memnodemap()

Hareesh Nagarajan:
[SBUSFB] tcx: Use FB_BLANK_UNBLANK instead of magic constant.

Haren Myneni:
fix in __alloc_bootmem_core() when there is no free page in first node's memory

[email protected]:

      [IA64-SGI] change default_sn2 to NR_CPUS==1024

Herbert Xu:
[GRE]: Fix hardware checksum modification

Hiroki Kaminaga:
[ARM] 3194/1: add pfn_to_kaddr macro for ARM take2

Hugh Dickins:
mips: setup_zero_pages count 1

Ingo Molnar:
add hlist_replace_rcu()

Jack Steiner:
[IA64] Limit the maximum NODEDATA_ALIGN() offset [IA64-SGI] Fix SN PTC deadlock recovery [IA64-SGI] Missed TLB flush

James Bottomley:
[SCSI] Consolidate REQ_BLOCK_PC handling path (fix ipod panic)

Jean Delvare:
radeon drm: fix compilation breakage with gcc 2.95.3

Jeff Dike:
uml skas0: stop gcc's insanity

Jeff Garzik:
[libata] mark certain hardware (or drivers) with a no-atapi flag [netdrvr skge] fix build

Jeff Mahoney:
reiserfs: skip commit on io error
reiserfs: close open transactions on error path

Jens Axboe:
[SCSI] fix panic when ejecting ieee1394 ipod
cciss: double put_disk()

Jeremy Higdon:
sgiioc4: check for no hwifs available

Jes Sorensen:
[IA64] uncached ref count leak

Johannes Berg:
ppc32: set smp_tb_synchronized on UP with SMP kernel

John Hawkes:
[IA64] disable preemption in udelay()

John Keller:
[IA64-SGI] altix: pci_window fixup

John McCutchan:
inotify: add two inotify_add_watch flags

john stultz:
x86_64: Fix collision between pmtimer and pit/hpet

Jordan Crouse:
ide: core modifications for AU1200
ide: AU1200 IDE update

Kazunori MIYAZAWA:
[IPv6] IPsec: fix pmtu calculation of esp

Keith Owens:
[IA64] Allow salinfo_decode to detect signals on read [IA64] Define an ia64 version of __raw_read_trylock

Keshavamurthy Anil S:
kprobes: fix race in aggregate kprobe registration
kprobes: no probes on critical path
kprobes: increment kprobe missed count for multiprobes

Knut Petersen:
fbdev: fix switch to KD_TEXT, enhanced version

Kyungmin Park:
mtd onenand driver: check correct manufacturer mtd onenand driver: fix unlock problem in DDP mtd onenand driver: reduce stack usage
mtd onenand driver: use platform_device.h instead device.h

Linus Torvalds:
Allow arbitrary shared PFNMAP's
Remove (at least temporarily) the "incomplete PFN mapping" support Allow arbitrary read-only shared pfn-remapping too
Revert revert of "[SCSI] fix usb storage oops"
get_user_pages: don't try to follow PFNMAP pages
Expose "Optimize for size" option for everybody
Move size optimization option outside of EMBEDDED menu, mark it EXPERIMENTAL Make sure we copy pages inserted with "vm_insert_page()" on fork Linux v2.6.15-rc6

Lothar Wassmann:
[ARM] 3201/1: PXA27x: Prevent hangup during resume due to inadvertedly enabling MBREQ (replaces: 3198/1)

Mao, Bibo:
Kprobes: Reference count the modules when probed on it

Marcelo Tosatti:
[ARM SMP] mpcore_wdt bogus fpos check
ide: MPC8xx IDE depends on IDE=y && BLK_DEV_IDE=y

Marcus Sundberg:
[NETFILTER]: ip_nat_tftp: Fix expectation NAT

Mark A. Greer:
i2c: Fix i2c-mv64xxx compilation error

Mark Lord:
[SCSI] Fix incorrect pointer in megaraid.c MODE_SENSE emulation libata-core.c: fix parameter bug on kunmap_atomic() calls

Martin Waitz:
[NET]: make function pointer argument parseable by kernel-doc

Matt Domsch:
ipmi: fix panic generator ID

Matt Helsley:
Add getnstimestamp function
Add timestamp field to process events

Matthew Wilcox:
[SCSI] Negotiate correctly with async-only devices

Mauro Carvalho Chehab:
V4L/DVB (3087) fix analog NTSC for pcHDTV 3000 V4L/DVB: (3086a) Whitespaces cleanups part 1 V4L/DVB: (3086b) Whitespaces cleanups part 2 V4L/DVB: (3086c) Whitespaces cleanups part 3 V4L/DVB: (3086c) Whitespaces cleanups part 4 V4L/DVB: (3151) I2C ID renamed to I2C_DRIVERID_INFRARED

Michael Chan:
[TG3]: Fix nvram arbitration bugs.
[TG3]: Fix suspend and resume
[TG3]: Fix 5704 single-port mode
[TG3]: Fix low power state

Michael Reed:
[SCSI] fix OOPS due to clearing eh_action prior to aborting eh command

Michal Ostrowski:
powerpc/pseries: Fix TCE building with 64k pagesize Fix windfarm model-id table

Mike Kravetz:
powerpc/pseries: boot failures on numa if no memory on node

Mike Miller:
cciss: fix for deregister_disk

Milton Miller:
PCI express must be initialized before PCI hotplug

NeilBrown:
md: fix a use-after-free bug in raid1
md: use correct size of raid5 stripe cache when measuring how full it is

Nicolas Pitre:
input: fix ucb1x00-ts breakage after conversion to dynamic input_dev allocation

Nikola Valerjev:
[ARM] 3200/1: Singlestep over ARM BX and BLX instructions using ptrace fix

Olaf Hering:
powerpc: correct the NR_CPUS description text
pcnet32: use MAC address from prom also on powerpc ieee80211_crypt_tkip depends on NET_RADIO

Ole Reinhardt:
fbdev: make pxafb more robust to errors with CONFIG_FB_PXA_PARAMETERS

Olof Johansson:
powerpc: remove redundant code in stab init
powerpc: Set cache info defaults

Pablo Neira Ayuso:
[NETFILTER]: Fix incorrect argument to ip_nat_initialized() in ctnetlink

Paolo 'Blaisorblade' Giarrusso:
uml: arch/um/scripts/Makefile.rules - remove duplicated code uml - fix some funkiness in Kconfig

Paolo Galtieri:
IPMI oops fix

Patrick McHardy:
[NETFILTER]: Fix ip_conntrack_flush abuse in ctnetlink [NETFILTER]: Fix CTA_PROTO_NUM attribute size in ctnetlink [NETFILTER]: Mark ctnetlink as EXPERIMENTAL
[NETFILTER]: Wait for untracked references in nf_conntrack module unload [NETFILTER]: Fix unbalanced read_unlock_bh in ctnetlink [NETFILTER]: Don't use conntrack entry after dropping the reference

Paul Jackson:
[SPARC]: atomic_clear_mask build fix
[SPARC]: block/ needed in final image link

Paul Mackerras:
powerpc/pseries: Optimize IOMMU setup
ppc: Build in all three of powermac, PREP and CHRP support

Pekka J Enberg:
uml: fix compile error for tt

Pierre Ossman:
[MMC] Proper check of SCR error code
Add try_to_freeze to kauditd

Ricardo Cerqueira:
V4L/DVB: (3135) Fix tuner init for Pinnacle PCTV Stereo

Rob Landley:
uml: fix dynamic linking on some 64-bit distros

Robin Holt:
[IA64] Updates to the sn2_defconfig for 2.6.15.
[IA64] Change SET_PERSONALITY to comply with comment in binfmt_elf.c. [IA64] fix for SET_PERSONALITY when CONFIG_IA32_SUPPORT is not set.

Russell King:
[ARM] Add memory.txt to 00-INDEX [MMC] Explain the internals of mmc_power_up()

Salyzyn, Mark:
dpt_i2o fix for deadlock condition

Sascha Sommer:
V4L/DVB: (3113) Convert em28xx to use vm_insert_page instead of remap_pfn_range

Sergei Shtylylov:
Au1550 AC'97 OSS driver spinlock fixes

Shaohua Li:
x86: fix NMI with CPU hotplug
i386/x86-64 disable LAPIC completely for offline CPU

Srivatsa Vaddagiri:
Fix bug in RCU torture test
Fix RCU race in access of nohz_cpu_mask

Stefan Richter:
ieee1394: resume remote ports when starting a host (fixes device recognition)
ieee1394: write broadcast_channel only to select nodes (fixes device recognition)

Stephen Hemminger:
sk98lin: rx checksum offset not set
[TG3]: remove warning on race
[NET]: Fix NULL pointer deref in checksum debugging.
skge: get rid of warning on race
[VLAN]: Fix hardware rx csum errors

Steven Whitehouse:
[DECNET]: add memory buffer settings

Thomas Young:
[TCP] Vegas: stop resetting rtt every ack [TCP] Vegas: Remove extra call to tcp_vegas_rtt_calc

Tony Luck:
[IA64] refresh tiger_defconfig ready for 2.6.15 [IA64] Split 16-bit severity field in sal_log_record_header

Vojtech Pavlik:
Dmitry Torokhov is input subsystem maintainer
Input: ALPS - correctly report button presses on Fujitsu Siemens S6010

Yasunori Goto:
Fix Kconfig of DMA32 for ia64
Fix calculation of grow_pgdat_span() in mm/memory_hotplug.c

Yasuyuki Kozakai:
[NETFILTER]: nf_conntrack: Fix missing check for ICMPv6 type [NETFILTER]: nfnetlink: Fix calculation of minimum message length

This last change (5650b736ad328f7f3e4120e8790940289b8ac144) "broke" a small process event connector test program (the one matt posted here
http://lkml.org/lkml/2005/9/28/347, slighty modified) due to a headers conflict. I think it's due to my setup, but...

@@ -26,6 +26,7 @@

#define CN_PROC_H
#include <linux/types.h>
+#include <linux/time.h>
#include <linux/connector.h>

and the program:
31: #include <stdio.h>
32: #include <stdlib.h>
33: #include <string.h>
34: #include <unistd.h>
35:
36: #include <sys/socket.h>
37: #include <sys/types.h>
38:
39: #include <linux/connector.h>
40: #include <linux/netlink.h>
41: #include <linux/cn_proc.h>

This gives me

diego@estel 2J2 ~/kernel # LC_ALL='C' make gcc -I 2.6/include test_cn_proc.c -o test_cn_proc In file included from 2.6/include/linux/cn_proc.h:29,

                 from test_cn_proc.c:41:
2.6/include/linux/time.h:12: error: redefinition of 'struct timespec'
2.6/include/linux/time.h:18: error: redefinition of 'struct timeval'
In file included from 2.6/include/linux/cn_proc.h:29,
                 from test_cn_proc.c:41:
2.6/include/linux/time.h:121:1: warning: "FD_SET" redefined
In file included from /usr/include/sys/types.h:216,
                 from /usr/include/stdlib.h:433,
                 from test_cn_proc.c:32:

/usr/include/sys/select.h:93:1: warning: this is the location of the previous definitio

(My "debian testing" box supplies an old and apparently incompatible version of connector.h so I had to point gcc to kernel's headers directly)

As a dirty trick, you should be able to avoid this by adding the following line just before #include <linux/cn_proc.h> :

   #define _LINUX_TIME_H

So that the preprocessor will think it has already included <linux/time.h> definitions and will not load them again. Of course, if they are needed, you're lost.

Willy

2.6.15-rc6 doesn't boot on my computer with an Oops that has drivers/media/video/saa7134/saa7134-alsa.c prominently in it's trace.

A picture of the Oops is at [1] (I won't get a price for the best picture for it, but it's readable...).

Kernels up to 2.6.14.4 boot fine, 2.6.15-rc1 is the one that introduced the problem.

I must give saa7134.card=6 at the lilo prompt for getting my card working.

The saa7134 part of the dmesg in 2.6.14.4:

<-- snip -->

saa7134[0]: found at 0000:00:0e.0, rev: 1, irq: 18, latency: 32, mmio: 0xed800000 saa7134[0]: subsystem: 1131:0000, board: Tevion MD 9717 [card=6,insmod option] saa7134[0]: board init: gpio is 100a0
saa7134[0]: Huh, no eeprom present (err=-5)?
saa7134[0]: registered device video0 [v4l2]
saa7134[0]: registered device vbi0
saa7134[0]: registered device radio0
tuner 4-0060: chip found @ 0xc0 (saa7134[0])
tuner 4-0060: All bytes are equal. It is not a TEA5767
tuner 4-0060: type set to 5 (Philips PAL_BG (FI1216 and compatibles))

<-- snip -->

cu
Adrian

[1] http://www.fs.tum.de/~bunk/TMP/bootcrash.jpg

       "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 SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

2.6.15-rc6 doesn't boot on my computer with an Oops that has drivers/media/video/saa7134/saa7134-alsa.c prominently in it's trace.

A picture of the Oops is at [1] (I won't get a price for the best picture for it, but it's readable...).

Kernels up to 2.6.14.4 boot fine, 2.6.15-rc1 is the one that introduced the problem.

I must give saa7134.card=6 at the lilo prompt for getting my card working.

The saa7134 part of the dmesg in 2.6.14.4:

<-- snip -->

saa7134[0]: found at 0000:00:0e.0, rev: 1, irq: 18, latency: 32, mmio: 0xed800000 saa7134[0]: subsystem: 1131:0000, board: Tevion MD 9717 [card=6,insmod option] saa7134[0]: board init: gpio is 100a0
saa7134[0]: Huh, no eeprom present (err=-5)?
saa7134[0]: registered device video0 [v4l2]
saa7134[0]: registered device vbi0
saa7134[0]: registered device radio0
tuner 4-0060: chip found @ 0xc0 (saa7134[0])
tuner 4-0060: All bytes are equal. It is not a TEA5767
tuner 4-0060: type set to 5 (Philips PAL_BG (FI1216 and compatibles))

<-- snip -->

cu
Adrian

[1] http://www.fs.tum.de/~bunk/TMP/bootcrash.jpg

       "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

saa7134-alsa is trying to initialize before the ALSA core has initialized. Probably no one has tested CONFIG_VIDEO_SAA7134=y.

There is some more brokenness there:

1) With CONFIG_VIDEO_SAA7134=y, both saa7134-alsa.o and saa7134-oss.o will be built into the kernel, but only the first of them has any chance to be used - the second will stay as dead code.

2) Both saa7134-alsa and saa7134-oss set dmasound_init and dmasound_exit function pointers to their functions (for handling of saa7134 cards hotplugged later), but they do not reset these pointers on unload - therefore if you load one of these modules, then unload it, then try to hotplug a saa7134-based card (apparently there are CardBus implementation), you will get oopses. These assignments in saa7134-alsa and saa7134-oss also stomp on each other.

-ECHEAPHARDWARE (sadly, boards without EEPROM are too common).

saa7134-alsa is trying to initialize before the ALSA core has initialized. Probably no one has tested CONFIG_VIDEO_SAA7134=y.

There is some more brokenness there:

1) With CONFIG_VIDEO_SAA7134=y, both saa7134-alsa.o and saa7134-oss.o will be built into the kernel, but only the first of them has any chance to be used - the second will stay as dead code.

2) Both saa7134-alsa and saa7134-oss set dmasound_init and dmasound_exit function pointers to their functions (for handling of saa7134 cards hotplugged later), but they do not reset these pointers on unload - therefore if you load one of these modules, then unload it, then try to hotplug a saa7134-based card (apparently there are CardBus implementation), you will get oopses. These assignments in saa7134-alsa and saa7134-oss also stomp on each other.

-ECHEAPHARDWARE (sadly, boards without EEPROM are too common).

Adrian, does it work if you change the "module_init()" in sound/sound_core.c into a "fs_initcall()"?

That should make sure that the sound core gets to initialize before normal drivers do.

Linus

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Adrian, does it work if you change the "module_init()" in sound/sound_core.c into a "fs_initcall()"?

That should make sure that the sound core gets to initialize before normal drivers do.

Linus

Sergey points out (but only to me) that sound/core/sound.c probably needs the same thing.

Sound people, can you pls check the dependencies? Are there any other "sound core" initialization that needs to happen early?

Linus

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Sergey points out (but only to me) that sound/core/sound.c probably needs the same thing.

Sound people, can you pls check the dependencies? Are there any other "sound core" initialization that needs to happen early?

Linus

No, this didn't work.

What did work was to leave sound/sound_core.c alone and make the module_init() in drivers/media/video/saa7134/saa7134-alsa.c a late_initcall() (plus disabling building of saa7134-oss.o because otherwise saa7134-alsa.o wouldn't do anything).

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 SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

No, this didn't work.

What did work was to leave sound/sound_core.c alone and make the module_init() in drivers/media/video/saa7134/saa7134-alsa.c a late_initcall() (plus disabling building of saa7134-oss.o because otherwise saa7134-alsa.o wouldn't do anything).

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

Em Ter, 2005-12-20 às 20:14 +0100, Adrian Bunk escreveu:

We have already a patch to solve -oss and -alsa conflict against
v4l-dvb tree. I'll prepare it against -git and submit in a few minutes to ML for you to test.

Cheers,
Mauro.

Can you do try the other way again, with sound/core/sound.c fixed too?

A regular driver really _should_ use the regular "module_init()" sequence (it is indeed just a compatibility define for "driver_init()").

The "late_init()" stuff is meant for stuff that literally runs after everything else is up and running, it might want all drivers functional (now, nobody really cares about a sound driver, so in that sense it would be ok..)

Thanks,

Linus

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

This works in the sense that the kernel boots and my saa7134 TV card is giving both audio and video output.

But the non-saa7134 access to my soundcard (e.g. rexima or xmms) is no longer working.

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 SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

This works in the sense that the kernel boots and my saa7134 TV card is giving both audio and video output.

But the non-saa7134 access to my soundcard (e.g. rexima or xmms) is no longer working.

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

Ahh. I assume it's the sequencer init etc that is missing.

Maybe we'll just have to do the late_init thing for at least the 2.6.15 timeframe.

Linus

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

But that's not really a useable fix. The problem is with almost all ALSA sound cards.

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

But that's not really a useable fix. The problem is with almost all ALSA sound cards.

Right. Which is why the _correct_ fix is certainly to just initialize the core functionality early.

So the fix is certainly _usable_ (and simple, and guaranteed to not break anything, which is why it's fine 2.6.15 material), but I certainly agree that a much better fix would be for a sound core person to walk through the subsystem initializers, and just mark _those_ early instead.

Hint hint ;)

Linus

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Right. Which is why the _correct_ fix is certainly to just initialize the core functionality early.

So the fix is certainly _usable_ (and simple, and guaranteed to not break anything, which is why it's fine 2.6.15 material), but I certainly agree that a much better fix would be for a sound core person to walk through the subsystem initializers, and just mark _those_ early instead.

Hint hint ;)

Linus

No, inside sound/ it's working due to the link order.

Thinking about this, what about the patch below?

I don't know whether this might break anything else, but it fixes my problem.

cu
Adrian

<-- snip -->

drivers might require an already initialized sound subsystem.

Fix the link order for a static sound subsystem.

@@ -470,7 +470,7 @@
 
 # Objects we will link into vmlinux / subdirs we need to visit
 init-y		:= init/
-drivers-y	:= drivers/ sound/
+drivers-y	:= sound/ drivers/
 net-y		:= net/
 libs-y		:= lib/
 core-y		:= usr/

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

No, inside sound/ it's working due to the link order.

Thinking about this, what about the patch below?

I don't know whether this might break anything else, but it fixes my problem.

cu
Adrian

<-- snip -->

drivers might require an already initialized sound subsystem.

Fix the link order for a static sound subsystem.

@@ -470,7 +470,7 @@
 
 # Objects we will link into vmlinux / subdirs we need to visit
 init-y		:= init/
-drivers-y	:= drivers/ sound/
+drivers-y	:= sound/ drivers/
 net-y		:= net/
 libs-y		:= lib/
 core-y		:= usr/

I'd be much more worried about this than about your patch that just modifies one driver.

Basically, this would make _all_ sound drivers initialize before the other drivers, and that just makes me suspect you'll have a lot of new bugs that get uncovered by the fact that the configuration changed radically.

So I'd much rather either fix one single sound driver (that can't mess up anything else), or fix the sound _core_ to just initialize in the right place. Moving _all_ sound drivers earlier sounds risky as hell, for no good reason.

Linus

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

At Tue, 20 Dec 2005 14:09:03 -0800 (PST),

Agreed, it looks too radical at this stage.

Another workaround is to move the relevant module to sound/* directory in order to get a sane initialization order. It's nothing but a workaround, though.

Takashi

Em Qua, 2005-12-21 às 15:21 +0100, Takashi Iwai escreveu:

Agreed.

hmmm... this may break saa7134 code, since alsa stuff is dependent of saa7134.ko.

Cheers,
Mauro.

At Wed, 21 Dec 2005 18:49:00 -0200,

If I understand correctly, it must be OK. Suppose that saa7134-alsa is moved to sound (only saa7134-alsa, other saa7134 stuff remains in drivers/media/video), the initialization order will be:
saa7134 -> sound core -> saa7134-alsa.

Or am I missing something else?

Takashi

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

At Wed, 21 Dec 2005 18:49:00 -0200,

If I understand correctly, it must be OK. Suppose that saa7134-alsa is moved to sound (only saa7134-alsa, other saa7134 stuff remains in drivers/media/video), the initialization order will be:
saa7134 -> sound core -> saa7134-alsa.

Or am I missing something else?

Takashi

Em Qui, 2005-12-22 às 16:32 +0100, Takashi Iwai escreveu:

	saa7134-oss.

Cheers,
Mauro.

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click

Em Qui, 2005-12-22 às 16:32 +0100, Takashi Iwai escreveu:

	saa7134-oss.

Cheers,
Mauro.

At Thu, 22 Dec 2005 14:06:57 -0200,

It's obsolete to me ;)

Takashi

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click

At Thu, 22 Dec 2005 14:06:57 -0200,

It's obsolete to me ;)

Takashi

Em Qui, 2005-12-22 às 17:17 +0100, Takashi Iwai escreveu:

He hope it will became obsolete soon, but saa-alsa needs more time to
became more mature :) 2.6.15 will be the first mainstream with this module. People still uses -oss...

Cheers,
Mauro.

At Tue, 20 Dec 2005 21:23:25 +0100,

What is missing there? No sound card entry in /proc/asound/cards? I thought the sequencer stuff Linus pointed out should be harmless as long as you use only PCM or mixer.

Takashi

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

At Tue, 20 Dec 2005 21:23:25 +0100,

What is missing there? No sound card entry in /proc/asound/cards? I thought the sequencer stuff Linus pointed out should be harmless as long as you use only PCM or mixer.

Takashi

<-- snip -->

0 [SAA7134 ]: SAA7134 - SAA7134

                     saa7134[0] at 0xed800000 irq 18
1 [V8237          ]: VIA8237 - VIA 8237
                     VIA 8237 with AD1888 at 0xe000, irq 21

<-- snip -->

What changed compared to the working setup (if the bug is really here) is the order of the two.

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

At Wed, 21 Dec 2005 19:22:14 +0100,

Well, that's not anyway guaranteed unless you pass the proper index options.

In the case above, snd_via82xx.index=0 saa7134.index=1 should work. Or you may tune with udev, too.

Takashi

I'm not sure whether this is really related to my problem:

No matter how they are ordered, shouldn't my soundcard still be accessible from xmms or rexima?

This results in my soundcard being no longer available:

<-- snip -->

...
Unknown boot option `saa7134.index=1': ignoring
...
cannot find the slot for index 0 (range 0-0)
VIA 82xx Audio: probe of 0000:00:11.5 failed with error -12 ALSA device list:
#0: saa7134[0] at 0xed800000 irq 18
NET: Registered protocol family 2
...

<-- snip -->

But as said above, I don't suspect the order of the devices being the problem.

-ENOUDEV

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 SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

I'm not sure whether this is really related to my problem:

No matter how they are ordered, shouldn't my soundcard still be accessible from xmms or rexima?

This results in my soundcard being no longer available:

<-- snip -->

...
Unknown boot option `saa7134.index=1': ignoring
...
cannot find the slot for index 0 (range 0-0)
VIA 82xx Audio: probe of 0000:00:11.5 failed with error -12 ALSA device list:
#0: saa7134[0] at 0xed800000 irq 18
NET: Registered protocol family 2
...

<-- snip -->

But as said above, I don't suspect the order of the devices being the problem.

-ENOUDEV

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

At Wed, 21 Dec 2005 23:40:25 +0100,

Yes, it is. You could have accessed to the secondary card from audio apps. In the case of ALSA, it's accessed via "default:1". For OSS, via /dev/dsp1.

Sorry, it should be "saa7134_alsa.index=1", of course.

I'm sure it is. The above shows simply confliction of indices.

Still you can remap the device files manually as you like :)

Takashi

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

At Wed, 21 Dec 2005 23:40:25 +0100,

Yes, it is. You could have accessed to the secondary card from audio apps. In the case of ALSA, it's accessed via "default:1". For OSS, via /dev/dsp1.

Sorry, it should be "saa7134_alsa.index=1", of course.

I'm sure it is. The above shows simply confliction of indices.

Still you can remap the device files manually as you like :)

Takashi

This is an interesting problem actually.
alsa consists of a number of different modules.
They all load in the correct order if they are modules. The problem comes when one compiles them into the kernel. They then load in the wrong order and bad things happen, resulting in the recommendation that alsa should always be modules. In this basis, we should not have to change the code in alsa at all, but instead change the kernel to understand the load order, even if compiled into the kernel and not as modules.

I have no idea how to get the kernel to do this though. Any pointers?

James

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Which, as a recommendation, is pure and utter crap.

NO.

The kernel does support this (and has supported for a long time).

First off, load order matters, even in the kernel. Within one "class" of initializers, you can just specify the right order in the Makefile, and it will honor them. Of course, that ends up often being hard to do across different directories, which is why there's another facility:

The kernel has several different classes of ordering. Anybody who thinks that "module_init()" is it, just hasn't looked at <linux/init.h>. There's seven different levels:

	#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)

where the next-to-last one is the regular "device_initcall()" (and this is what a "module_init()" in a compiled-in driver will use).

Now, something like the basic sound subsystem initialization should obviously NOT be a "device initcall". It's not a device. It's a subsystem that serves devices, and thus the basic sound initialization should probably use "subsys_initcall()" instead.

Now, if it's built as a module, that "subsys_initcall()" ends up doing exactly the same thing as a plain "module_init()", and you'll never see any difference. But when it's built into the kernel, it means that it gets initialized with the other subsystems.

Now, one thing to look out for is that if your "core sound initialization" depends on PCI probing having completed (ie it's not a pure subsystem with no dependencies on anything else), the common hack for that is to just use the "fs_initicall()" instead. But a truly independent subsystem (which sound hopefully is) should just use subsys_initcall(), and then, if that subsystem internally has more complex ordering, just use the link order in the Makefiles to indicate that.

The above should hopefully make the kernel support for this obvious.

I thought more people knew about all this. Forcing (or even just encouraging) people to use loadable modules is just horrible. I personally run a kernel with no modules at all: it makes for a simpler bootup, and in some situations (embedded) it has both security and size advantages.

Linus

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

With modules it's possible to test a new ALSA version without recompiling the kernel or even rebooting. Encouraging people to build it into the kernel would create a problematic barrier to entry for debugging. With the amount of poorly documented hardware we support, it's essential for preventing driver regressions for users to be able to easily test the latest ALSA version.

Lee

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

That's TOTALLY irrelevant.

Kernel modules work fine for developers. I'm not saying that _you_ shouldn't use modules.

I'm saying that you have absolutely no business telling others not to compile these things in. Statically compiled drivers have advantages.

Linus

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Users don't want to be testers when they report problems and no on responds to the problem report!

My $.02
Steve

At Tue, 20 Dec 2005 13:03:10 -0800 (PST),

As far as looking at the codes, it's OK for PCI. PCI is initialized in postcore, and the only device_initcall is for pci_init(), which calls fixup for each PCI device. This is no problem because fixup is called in pci_enable(), too.

But for other subsystems like ISA PnP, it may be broken since some codes are still using module_init().
(And, interestingly, fs_initcall() is rarely used in the whole fs/
codes! "grep -r fs_initcall linux/fs" hits only one file.)

So, a "safe" solution for the time being appears to be either
- to look through the whole codes and adjust *_initcall() levels,
- to force to build saa7134-alsa as a module, or
- to move saa7134-alsa.c to sound/ directory.

Yep. The driver must work both for modules and built-in. If it doesn't work, it's called a bug, as we all know :)

Takashi

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Yes. That thing was probably mis-named. It's much more commonly used for a "helper subsystem", ie things like pcmcia (that want PCI to be fully initialized and probed, but want to run before the actual device drivers start probing).

Well, you dropped the easiest: make saa7134 just use "late_initcall()".

It's not "correct", but it's certainly no less correct than just forcing a driver to be moved for link order reasons.

Linus

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

At Wed, 21 Dec 2005 10:32:41 -0800 (PST),

I see. Thanks for clarification.

Yep, that's obviously the easiest one. I'd vote for this, at least for 2.6.15, once after it's confirmed to work.

Takashi

I've already stated somewhere in this thread that this did fix it for me.

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 SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Hi all;

I've just confirmed it works with rc6-git2. The driver activates properly and works as expected.
I've just commited the changes to v4l, Mauro should send them upstream later.

--
RC

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Hi all;

I've just confirmed it works with rc6-git2. The driver activates properly and works as expected.
I've just commited the changes to v4l, Mauro should send them upstream later.

--
RC

Linus,

I'm glad you said that and I have to second that opinion.

On our current product, we compile everything we need into the kernel; we don't use Alsa as modules at all. Our system is "embedded" as far as the user is concerned (though in many ways is just a general purpose computer running a custom stripped down distribution), and the monolithic kernel is critical to our boot speed (under 1 minute till all services are running) and filesystem size.

In addition, it makes maintenance and porting much easier: Step 1 - reconfigure and recompile the kernel; Step 2 - put bzImage in our update tarball. Easy. I can't imagine what a pain it would be to have to "install" the modules in our filesystem image.

Thankfully, we've never had to deal with this sort of failure; all of our Alsa drivers and services have been well behaved (mostly).

- Steve

Yes, I think the common case is that built-in _does_ work. I certainly have used sound that way. This one case is a bit special just because it's not under the sound/ directory, but I suspect that may be true of some USB sound"cards" too.

Now, hot-plug devices tend to have a stronger case for being built as modules, although even there I personally actually end up just building in the devices I have (whether cardbus cards or things like the USB printer/mouse/keyboard).

So I don't think sound is terminally broken here, just a few small details that it gets wrong that causes some odder drivers to not like being built in.

Linus

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

At Wed, 21 Dec 2005 10:32:05 -0800 (PST),

Don't worry, the usb audio/midi drivers are in sound/usb :) drivers/usb/class/audio and usb-midi are OSS-only and deprecated.

Takashi

Em Ter, 2005-12-20 às 20:14 +0100, Adrian Bunk escreveu:

This patch should fix alsa-oss incompatibilities when both are linked
as module. It will also require either -oss or -alsa if it is statically linked.

It doesn't address the OOPS because of sound late init.

Adrian,

Please test and give us some feedback.

Cheers,
Mauro.

V4L/DVB (3200): Fix saa7134 ALSA/OSS collisions

From: Ricardo Cerqueira <[email protected]>

- When ALSA or OSS are loaded, check if the other is present Fixed hotplug notifiers cleanup on module removal
- The saa7134 DMA sound modules now have their own Kconfig entries, and if built statically enforce exclusivity
- SND_PCM_OSS isn't necessary for the OSS driver

---

 drivers/media/video/saa7134/Kconfig        |   26 ++++++++++++++++++++++++--
 drivers/media/video/saa7134/Makefile       |    7 +++++--
 drivers/media/video/saa7134/saa7134-alsa.c |   13 ++++++++++---
 drivers/media/video/saa7134/saa7134-oss.c  |   15 ++++++++++++---
 4 files changed, 51 insertions(+), 10 deletions(-)

index c512c44..c0f604a 100644
@@ -1,11 +1,10 @@
 config VIDEO_SAA7134
 	tristate "Philips SAA7134 support"
-	depends on VIDEO_DEV && PCI && I2C && SOUND && SND
+	depends on VIDEO_DEV && PCI && I2C
 	select VIDEO_BUF
 	select VIDEO_IR
 	select VIDEO_TUNER
 	select CRC32
-	select SND_PCM_OSS
 	---help---
 	  This is a video4linux driver for Philips SAA713x based
 	  TV cards.

@@ -13,6 +12,29 @@ config VIDEO_SAA7134
 	  To compile this driver as a module, choose M here: the
 	  module will be called saa7134.
 
+config VIDEO_SAA7134_ALSA
+	tristate "Philips SAA7134 DMA audio support"
+	depends on VIDEO_SAA7134 && SOUND && SND && (!VIDEO_SAA7134_OSS || VIDEO_SAA7134_OSS = m)
+	select SND_PCM_OSS
+	---help---
+	  This is a video4linux driver for direct (DMA) audio in
+	  Philips SAA713x based TV cards using ALSA
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called saa7134-alsa.
+
+config VIDEO_SAA7134_OSS
+	tristate "Philips SAA7134 DMA audio support (OSS, DEPRECATED)"
+	depends on VIDEO_SAA7134 && SOUND_PRIME && (!VIDEO_SAA7134_ALSA || VIDEO_SAA7134_ALSA = m)
+	---help---
+	  This is a video4linux driver for direct (DMA) audio in
+	  Philips SAA713x based TV cards using OSS
+
+	  This is deprecated in favor of the ALSA module
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called saa7134-oss.
+
 config VIDEO_SAA7134_DVB
 	tristate "DVB/ATSC Support for saa7134 based TV cards"
 	depends on VIDEO_SAA7134 && DVB_CORE

index 134f83a..1ba9984 100644
@@ -4,8 +4,11 @@ saa7134-objs :=	saa7134-cards.o saa7134-
 		saa7134-video.o saa7134-input.o
 
 obj-$(CONFIG_VIDEO_SAA7134) +=  saa7134.o saa7134-empress.o \
-				saa6752hs.o saa7134-alsa.o \
-				saa7134-oss.o
+				saa6752hs.o
+
+obj-$(CONFIG_VIDEO_SAA7134_ALSA) += saa7134-alsa.o
+obj-$(CONFIG_VIDEO_SAA7134_OSS) += saa7134-oss.o
+
 obj-$(CONFIG_VIDEO_SAA7134_DVB) += saa7134-dvb.o
 
 EXTRA_CFLAGS += -I$(src)/..

index 953d5fe..ac608b1 100644
@@ -989,6 +989,14 @@ static int saa7134_alsa_init(void)
 	struct saa7134_dev *dev = NULL;
 	struct list_head *list;
 
+	if (!dmasound_init && !dmasound_exit) {
+		dmasound_init = alsa_device_init;
+		dmasound_exit = alsa_device_exit;
+	} else {
+		printk(KERN_WARNING "saa7134 ALSA: can't load, DMA sound handler already assigned (probably to OSS)\n");
+		return -EBUSY;
+	}
+
 	printk(KERN_INFO "saa7134 ALSA driver for DMA sound loaded\n");
 
 	list_for_each(list,&saa7134_devlist) {

@@ -1001,9 +1009,6 @@ static int saa7134_alsa_init(void)
 		}
 	}
 
-	dmasound_init = alsa_device_init;
-	dmasound_exit = alsa_device_exit;
-
 	if (dev == NULL)
 		printk(KERN_INFO "saa7134 ALSA: no saa7134 cards found\n");
 

@@ -1023,6 +1028,8 @@ static void saa7134_alsa_exit(void)
 		snd_card_free(snd_saa7134_cards[idx]);
 	}
 
+	dmasound_init = NULL;
+	dmasound_exit = NULL;
 	printk(KERN_INFO "saa7134 ALSA driver for DMA sound unloaded\n");
 
 	return;

index 513a699..0061acf 100644
@@ -959,8 +959,17 @@ static int saa7134_oss_init(void)
 	struct saa7134_dev *dev = NULL;
 	struct list_head *list;
 
+	if (!dmasound_init && !dmasound_exit) {
+		dmasound_init = oss_device_init;
+		dmasound_exit = oss_device_exit;
+	} else {
+		printk(KERN_WARNING "saa7134 OSS: can't load, DMA sound handler already assigned (probably to ALSA)\n");
+		return -EBUSY;
+	}
+
 	printk(KERN_INFO "saa7134 OSS driver for DMA sound loaded\n");
 
+
 	list_for_each(list,&saa7134_devlist) {
 		dev = list_entry(list, struct saa7134_dev, devlist);
 		if (dev->dmasound.priv_data == NULL) {

@@ -974,9 +983,6 @@ static int saa7134_oss_init(void)
 	if (dev == NULL)
 		printk(KERN_INFO "saa7134 OSS: no saa7134 cards found\n");
 
-	dmasound_init = oss_device_init;
-	dmasound_exit = oss_device_exit;
-
 	return 0;
 
 }

@@ -997,6 +1003,9 @@ static void saa7134_oss_exit(void)
 
 	}
 
+	dmasound_init = NULL;
+	dmasound_exit = NULL;
+
 	printk(KERN_INFO "saa7134 OSS driver for DMA sound unloaded\n");
 
 	return;

It works and looks good.

Can we get this patch into 2.6.15?

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 SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click

It works and looks good.

Can we get this patch into 2.6.15?

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

Em Qui, 2005-12-22 às 01:59 +0100, Adrian Bunk escreveu:

I've sent today to Linus for him to pull for 2.6.15.

Cheers,
Mauro.

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click

Em Qui, 2005-12-22 às 01:59 +0100, Adrian Bunk escreveu:

I've sent today to Linus for him to pull for 2.6.15.

Cheers,
Mauro.

The following bugs in the kernel Bugzilla [1] contain regressions in 2.6.15-rc compared to 2.6.14 with patches:
- #5632 forcedeth driver occasionally hangs
- #5758 x86_64: PANIC: early exception

The following bug in the kernel Bugzilla contains a regressions in 2.6.15-rc without a patch:
- #5760 No sound with snd_intel8x0 & ALi M5455 chipset (kobject_register failed)

If we want people to test -rc kernels, we should also try hard to fix the regressions they report (even more if there are already patches for them)...

I've Cc'ed all people who might be able comment on one or more of these issues.

cu
Adrian

[1] http://bugzilla.kernel.org/

       "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

We put code in the kobjet to report when callers fail, due to problems in them, and the kobject code is blamed...

Looks like a sound driver issue, nothing has changed in the kobject code.

thanks,

greg k-h

At Wed, 21 Dec 2005 23:15:57 -0800,

But there is no relevant change in sound stuff between 2.6.15-rc4 and rc6 (except for minor fix of OSS drivers). If it really worked with 2.6.15-rc4, something else got broken.

Takashi

I don't know whether this is related to the problem, but the code giving the "AC'97 1 does not respond - RESET" warning that is present in both the working and the non-working cases for the submitter looks a bit fragile.

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 SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

I don't know whether this is related to the problem, but the code giving the "AC'97 1 does not respond - RESET" warning that is present in both the working and the non-working cases for the submitter looks a bit fragile.

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

Two more post 2.6.14 ALSA regressions that IMHO need to be fixed for 2.6.15:

https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1585
http://music.columbia.edu/pipermail/linux-audio-dev/2005-December/014269.html

Lee

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Two more post 2.6.14 ALSA regressions that IMHO need to be fixed for 2.6.15:

https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1585
http://music.columbia.edu/pipermail/linux-audio-dev/2005-December/014269.html

Lee

Thanks for tracking this. Although I fear it won't come to much.

non-bugzilla post-2.6.14 bugs which I've squirelled away include:

From: Brice Goglin <[email protected]>
Subject: Linux 2.6.14: Badness in as-iosched

From: Charles-Edouard Ruault <[email protected]>
Subject: [BUG] kernel 2.6.14.2 breaks IPSEC

From: Michael Madore <[email protected]>
Subject: USB handoff, irq 193: nobody cared!

From: Wu Fengguang <[email protected]>
Subject: BUG: spinlock recursion on 2.6.14-mm2 when oprofiling

From: Miles Lane <[email protected]>
Subject: 2.6.15-rc2-git6 + ipw2200 1.0.8 -- Slab corruption

From: "Gottfried Haider" <[email protected]>
Subject: [2.6.15-rc2] 8139too probe fails (pci related?)

From: Steve Work <[email protected]>
Subject: Multi-thread corefiles broken since April

From: Diego Calleja <[email protected]>
Subject: Oops with w9968cf

From: John Reiser <[email protected]>
Subject: control placement of vDSO page

From: "P. Christeas" <[email protected]>
Subject: No sound from CX23880 tuner w. 2.6.15-rc5

Subject: x86_64 timekeeping buglets
From: Jim Houston <[email protected]>

People had been complaining about a lack of testing prior to the final release of a kernel.

If this was meant serious, we should try hard to fix all regressions reported by people who do test -rc and -git kernels.

As the subject says, this is not a post-2.6.14 regression.

Besides this, Jens (Cc'ed) sent a patch for it:
http://lkml.org/lkml/2005/11/20/119

Was there a reason why it wasn't applied?

As the subject says, this is not a post-2.6.14 regression.

And reading the discussion on netdev, it seems this wasn't ever expected to work without additional netfilter patches.

If this is still present, David should look into it:
http://www.ussg.iu.edu/hypermail/linux/kernel/0511.1/2243.html

If this affects Linus' tree, a patch for it is in -mm.

As the subject says, this is a problem when using an external version of this driver.

According to the report perhaps not a post-2.6.14 regression.

But anyways, this should be better debugged.

@Gottfried:
Does it work with kernel 2.6.14.4?
Does it work with kernel 2.6.15-rc6?
If it stil fails, can you send a complete dmesg for 2.6.15-rc6?

As the subject says, this is not a post-2.6.14 regression.

@Luca, Greg:
http://lkml.org/lkml/2005/12/12/91

This is not a post-2.6.14 regression.

No answer by the submitter when being asked for more information.

Reported against 2.6.13, therefore not a post-2.6.14 regression.

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

Well yeah. But that doesn't mean thse things have lower priority that post-2.6.14 regressions.

I understand what you're doing here, but we should in general concentrate upon the most severe bugs rather than upon the most recent..

Regressions are worse than other bugs since they break working setups after a kernel upgrade, and should therefore be fixed before 2.6.15 gets released.

This should in no way imply that other severe bugs shouldn't be fixed.

One thing why I'm currently pointing to such regressions is that I can't stand people whining noone would test -rc kernels while we aren't even able to handle all the regressions reported by people who actually do test our -rc kernels.

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

Hypocratic oath: "First, do no harm."

If a new kernel version can't make things *better*, at least it shouldn't make them *worse*. New features are good, performance improvements are good, breaking working systems with an update is not good.

I'm with Adrian on this, if you want people to test and report with -rc kernels, then there should be some urgency to addressing the reported problems.

   -bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
 last possible moment - but no longer"  -me

I agree. Quite frankly, I am extremely surprised that this matter is even up for discussion. Is it really so important to release 2.6.15 before the end of 2005 that we dont even have the time to fix regressions that have already been reported in older kernels? ESPECIALLY given that patches are said to be available?

IMHO, I agree that new regressions are most important to fix, but I feel that old regressions are extremely important to fix as well. If we know of more regressions that CAN be fixed before a kernel release, why not do it?

Why should there be any rush to release the next mainline version? To make it in time for Christmas? A better Christmas gift to the world would be a new release without regressions, be it a month late, who cares? (I know -- not likely, but at least we should try)

...and that's my opinion.

-Michael Krufky

No, the release dates aren't critical at all.

The problem is that if we allow the release to be stalled by bugs it allows one sluggish maintainer to block the entire kernel. At some point in time we do need to just give up and hope that the bug will get fixed in 2.6.x.y or that it'll just magically fix itself later on (this happens, for various reasons).

We get in the situation where lots of people are sitting there with arms folded, complaining about lack of a new kernel release while nobody is actually working on the bugs. Nobody knows why this happens.

Things get lost. If there's a patch which needs applying and we've missed it, please please please rediff it, add your Signed-off-by and loudly mail the thing out daily.

Fixing many of these things is not trivial, as I'm sure you know from personal experience. The great majority are in drivers and, almost axiomatically, the guy who added the regression cannot reproduce it on his hardware (otherwise he wouldn't have shipped the diff). So the debugging process involves drawn out to-and-fro with the reporter. And it requires quite a bit of work by and help from the original reporter. Depressingly, developers often just don't bother entering into this process in the first place and we shed another batch of mainline testers/users.

We'll regularly hold up a release due to an identified set of bugs. But if we do this we need to be very clear on what those bugs are and we need to be assured that there's a developer actively working on each bug and that the reporter is responding. Without all of that in place, the whole release process would get stalled for arbitrary amounts of time.

We need someone who does nothing but track and report upon bugs. It would be a full-time job. We don't have asuch a person. We hope that individual maintainers and subsystem maintainers will track the bugs in their area of responsibility so that such a person is not necessary. But the maintainers don't do this. You see the result.

Or after some period of time the code causing the regression gets rolled back and the patch gets delayed until the regression is fixed or at least understood. Other than a fix for an exploitable security issue there are few things added in any mailline release which couldn't wail until the next mainline or -stable comes out.

Historically patches have been rejected because they were "not the right way to fix the problem," even though they did work (some of mine during early SMP days, for example). I would hope that introducing a regression also qualifies as "not the right way to fix the problem," and particularly not the right way to introduce some new feature or performance enhancement.

I suspect that the developer of a patch would be more likely to work on the regression if it were preventing the fix from going in.

Good luck. Someone qualified to do that job would also be qualified to do more interesting things...

bill davidsen <[email protected]>
 CTO TMR Associates, Inc
 Doing interesting things with small computers since 1979

Fair enough... (not much else I can say to that -- you're right)

... btw, I tested -rc7 and it's smooth as butter...

-MiKE

I can't believe that of all the vendors and distributors with Linux-centric business models and multimillion dollar investments in Linux that someone didn't hire someone to do this years ago. Are they all hoping that some "weekend hacker" will come along and do it all for free?

Lee

Jens also posted a different patch on
http://lkml.org/lkml/2005/11/21/111 addressing my issue. It was supposed to go in -stable. But, from I see in changelogs, nothing went into -stable while something similar has been merged into rc3:
http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;h=43fa2049568883d6b5c07cc304b77c93d3091abf;hp=fbe050124ec514431c19091d395fa9065b2398a4;hb=8ad9ebb391e4cd75837ee608b9c33fcaceda0bc2;f=block/as-iosched.c

Anyway, I did not reproduce my problem with the first patch that Jens sent (applied on top of 2.6.14). 2.6.15-rcX look fine too, but I am not sure I have stressed those kernels as much as 2.6.14.

Brice

Actually, a -git bisection test is even easier, less work involved, and will point you to the exact patch that caused the regression.

http://www.kernel.org/pub/software/scm/git/docs/howto/isolate-bugs-with-bisect.txt

Cheers,
Michael Krufky

P.S.: I apologize if any cc's got dropped.... I tried to add those that I know should be here, but the V4L mailing list hosted by RedHat adds a Reply-To: and drops all the cc's ... I've been flamed about it in the past, and I complained about it on V4L list-- Alan Cox says this was intended, and nobody agrees with me that it should be fixed. :-( (this is my last word on the issue)

No, you're incorrect. In many cases, modules from a given subsystem can break due to a change elsewhere in the kernel.

Did you drop the list cc's on purpose? (re-added)

Regards,

Mike Krufky

I recently played around with this particular system, and it turned out that moving the 8139b-card to another PCI slot fixed it. (works now in both 2.6.15-rc2 and rc6-git2) So I guess it's just a particular oddity of this system, as noone else seems to hit this?

the original lines in kern.log were
-- snip --
PCI quirk: region e400-e47f claimed by ICH4 ACPI/GPIO/TCO
PCI quirk: region ec00-ec3f claimed by ICH4 GPIO
PCI: Unable to handle 64-bit address for device 0000:01:0c.0
PCI: Transparent bridge - 0000:00:1e.0
(..)
PCI: Cannot allocate resource region 0 of device 0000:01:0c.0
PCI: Cannot allocate resource region 3 of device 0000:01:0c.0
pnp: 00:03: ioport range 0xe400-0xe47f could not be reserved
pnp: 00:03: ioport range 0xec00-0xec3f has been reserved
PCI: Ignore bogus resource 6 [0:0] of 0000:00:02.0
PCI: Error while updating region 0000:01:0c.0/3 (fa800800 != 00000810)
PCI: Error while updating region 0000:01:0c.0/0 (0000d001 != 813910fc)
PCI: Bridge: 0000:00:1e.0
(..)
8139too Fast Ethernet driver 0.9.27
PCI: Device 0000:01:0c.0 not available because of resource collisions
Trying to free nonexistent resource <0000d000-0000d003>
Trying to free nonexistent resource <fa800800-fa80080f>
8139too: probe of 0000:01:0c.0 failed with error -22
-- snip --
.. on a ASUS CUSL2 (i815E) motherboard that was, no change when using pci=routeirq or pci=noacpi.

Gottfried Haider

Greg, can you comment on this issue?

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

I have no idea, sorry. Glad it's working for you now :)

greg k-h

From: Andrew Morton <[email protected]>
Date: Thu, 22 Dec 2005 00:52:09 -0800

Herbert's reply at the end of the thread explains that what the user is doing, applying SNAT to IPSEC, has undefined results currently.

Using netfilter with IPSEC is known to be broken since the beginning of our IPSEC implementation, and we plan to cure it in 2.6.16 with some excellent work done by Patrick McHardy and Herbert Xu.

So just remove that from your list please, thanks.