Linux 2.6.15-rc6

Linux 2.6.15-rc6

[Linus Torvalds]

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

hawkes@sgi.com:
      [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

Re: Linux 2.6.15-rc6

[Diego Calleja]

El Sun, 18 Dec 2005 16:47:33 -0800 (PST),
Linus Torvalds <torvalds@osdl.org> escribió:

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


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...

--- a/include/linux/cn_proc.h
+++ b/include/linux/cn_proc.h
@@ -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)

Re: Linux 2.6.15-rc6

[Willy Tarreau]

On Mon, Dec 19, 2005 at 02:30:58AM +0100, Diego Calleja wrote:
> El Sun, 18 Dec 2005 16:47:33 -0800 (PST),
> Linus Torvalds <torvalds@osdl.org> escribió:
> 
> > Matt Helsley:
> >       Add getnstimestamp function
> >       Add timestamp field to process events
> 
> 
> 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...
> 
> --- a/include/linux/cn_proc.h
> +++ b/include/linux/cn_proc.h
> @@ -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: boot failure in saa7134-alsa.c

[Adrian Bunk]

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

Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 1392 bytes --]

On Tue, Dec 20, 2005 at 02:18:10PM +0100, Adrian Bunk wrote:
> 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...).

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.

> 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.

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

[Linus Torvalds]

On Tue, 20 Dec 2005, Sergey Vlasov wrote:
> 
> saa7134-alsa is trying to initialize before the ALSA core has initialized.
> Probably no one has tested CONFIG_VIDEO_SAA7134=y.

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

Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

[Linus Torvalds]

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

On Tue, 20 Dec 2005, Sergey Vlasov wrote:

> On Tue, Dec 20, 2005 at 10:24:55AM -0800, Linus Torvalds wrote:
> > 
> > 
> > On Tue, 20 Dec 2005, Sergey Vlasov wrote:
> > > 
> > > saa7134-alsa is trying to initialize before the ALSA core has initialized.
> > > Probably no one has tested CONFIG_VIDEO_SAA7134=y.
> > 
> > Adrian, does it work if you change the "module_init()" in 
> > sound/sound_core.c into a "fs_initcall()"?
> 
> And in sound/core/sound.c (ALSA causes the problem here, not OSS).
> 
> > That should make sure that the sound core gets to initialize before normal 
> > drivers do.
> 

Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

[Adrian Bunk]

On Tue, Dec 20, 2005 at 10:24:55AM -0800, Linus Torvalds wrote:
> 
> 
> On Tue, 20 Dec 2005, Sergey Vlasov wrote:
> > 
> > saa7134-alsa is trying to initialize before the ALSA core has initialized.
> > Probably no one has tested CONFIG_VIDEO_SAA7134=y.
> 
> Adrian, does it work if you change the "module_init()" in 
> sound/sound_core.c into a "fs_initcall()"?

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

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

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

[Mauro Carvalho Chehab]

Em Ter, 2005-12-20 às 20:14 +0100, Adrian Bunk escreveu:
> On Tue, Dec 20, 2005 at 10:24:55AM -0800, Linus Torvalds wrote:
> > 

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

> > That should make sure that the sound core gets to initialize before normal 
> > drivers do.
> > 
> > 		Linus
> 
> cu
> Adrian
> 
Cheers, 
Mauro.

Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

[Linus Torvalds]

On Tue, 20 Dec 2005, Adrian Bunk wrote:
>
> > Adrian, does it work if you change the "module_init()" in 
> > sound/sound_core.c into a "fs_initcall()"?
> 
> No, this didn't work.
> 
> What did work was to leave sound/sound_core.c alone

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

Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

[Adrian Bunk]

On Tue, Dec 20, 2005 at 11:59:20AM -0800, Linus Torvalds wrote:
> 
> 
> On Tue, 20 Dec 2005, Adrian Bunk wrote:
> >
> > > Adrian, does it work if you change the "module_init()" in 
> > > sound/sound_core.c into a "fs_initcall()"?
> > 
> > No, this didn't work.
> > 
> > What did work was to leave sound/sound_core.c alone
> 
> Can you do try the other way again, with sound/core/sound.c fixed too?
>...

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.

> 	Thanks,
> 
> 		Linus

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

[Mauro Carvalho Chehab]

[-- Attachment #1: Type: text/plain, Size: 439 bytes --]

Em Ter, 2005-12-20 às 20:14 +0100, Adrian Bunk escreveu:
> (plus disabling building of saa7134-oss.o because
> otherwise saa7134-alsa.o wouldn't do anything). 

	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.

[-- Attachment #2: v4l_dvb_3200_fix_saa7134_alsa_oss_collisions.patch --]
[-- Type: text/x-patch, Size: 5500 bytes --]

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

From: Ricardo Cerqueira <v4l@cerqueira.org>

- 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

Signed-off-by: Ricardo Cerqueira <v4l@cerqueira.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@brturbo.com.br>
---

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

diff --git a/drivers/media/video/saa7134/Kconfig b/drivers/media/video/saa7134/Kconfig
index c512c44..c0f604a 100644
--- a/drivers/media/video/saa7134/Kconfig
+++ b/drivers/media/video/saa7134/Kconfig
@@ -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
diff --git a/drivers/media/video/saa7134/Makefile b/drivers/media/video/saa7134/Makefile
index 134f83a..1ba9984 100644
--- a/drivers/media/video/saa7134/Makefile
+++ b/drivers/media/video/saa7134/Makefile
@@ -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)/..
diff --git a/drivers/media/video/saa7134/saa7134-alsa.c b/drivers/media/video/saa7134/saa7134-alsa.c
index 953d5fe..ac608b1 100644
--- a/drivers/media/video/saa7134/saa7134-alsa.c
+++ b/drivers/media/video/saa7134/saa7134-alsa.c
@@ -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;
diff --git a/drivers/media/video/saa7134/saa7134-oss.c b/drivers/media/video/saa7134/saa7134-oss.c
index 513a699..0061acf 100644
--- a/drivers/media/video/saa7134/saa7134-oss.c
+++ b/drivers/media/video/saa7134/saa7134-oss.c
@@ -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;

Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

[James Courtier-Dutton]

Linus Torvalds wrote:
> 
> On Tue, 20 Dec 2005, Adrian Bunk wrote:
> 
>>>Adrian, does it work if you change the "module_init()" in 
>>>sound/sound_core.c into a "fs_initcall()"?
>>
>>No, this didn't work.
>>
>>What did work was to leave sound/sound_core.c alone
> 
> 
> 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 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

Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

[Linus Torvalds]

On Tue, 20 Dec 2005, Adrian Bunk wrote:
> 
> But the non-saa7134 access to my soundcard (e.g. rexima or xmms) is no 
> longer working.

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

Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

[James Courtier-Dutton]

Linus Torvalds wrote:
> 
> On Tue, 20 Dec 2005, Adrian Bunk wrote:
> 
>>But the non-saa7134 access to my soundcard (e.g. rexima or xmms) is no 
>>longer working.
> 
> 
> 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
> 

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

Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

[Linus Torvalds]

On Tue, 20 Dec 2005, James Courtier-Dutton wrote:
>
> 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.

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

> 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.

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.

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

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

Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

[Linus Torvalds]

On Tue, 20 Dec 2005, James Courtier-Dutton wrote:

> Linus Torvalds wrote:
> > 
> > On Tue, 20 Dec 2005, Adrian Bunk wrote:
> > 
> > > But the non-saa7134 access to my soundcard (e.g. rexima or xmms) is no
> > > longer working.
> > 
> > 
> > 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.
> 
> 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

[RFC: 2.6 patch] Makefile: sound/ must come before drivers/

[Adrian Bunk]

On Tue, Dec 20, 2005 at 08:47:09PM +0000, James Courtier-Dutton wrote:
> Linus Torvalds wrote:
> >
> >On Tue, 20 Dec 2005, Adrian Bunk wrote:
> >
> >>But the non-saa7134 access to my soundcard (e.g. rexima or xmms) is no 
> >>longer working.
> >
> >
> >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
> >
> 
> But that's not really a useable fix. The problem is with almost all ALSA 
> sound cards.

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.


Signed-off-by: Adrian Bunk <bunk@stusta.de>

--- linux-2.6.15-rc6/Makefile.old	2005-12-20 21:53:26.000000000 +0100
+++ linux-2.6.15-rc6/Makefile	2005-12-20 21:53:42.000000000 +0100
@@ -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/

Re: [Alsa-devel] [RFC: 2.6 patch] Makefile: sound/ must come before drivers/

[Jaroslav Kysela]

On Tue, 20 Dec 2005, Adrian Bunk wrote:

> On Tue, Dec 20, 2005 at 08:47:09PM +0000, James Courtier-Dutton wrote:
> > Linus Torvalds wrote:
> > >
> > >On Tue, 20 Dec 2005, Adrian Bunk wrote:
> > >
> > >>But the non-saa7134 access to my soundcard (e.g. rexima or xmms) is no 
> > >>longer working.
> > >
> > >
> > >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
> > >
> > 
> > But that's not really a useable fix. The problem is with almost all ALSA 
> > sound cards.
> 
> No, inside sound/ it's working due to the link order.
> 
> Thinking about this, what about the patch below?
>
> -drivers-y	:= drivers/ sound/
> +drivers-y	:= sound/ drivers/

It might break the "video" subsystem, because we have a lowlevel code 
for radio tuners in our code.

Basically, everything from /sound/core tree should be initialized at first 
before any lowlevel driver is loaded, except /sound/core/oss and
/sound/core/seq/oss subtrees.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs

Re: [RFC: 2.6 patch] Makefile: sound/ must come before drivers/

[Linus Torvalds]

On Tue, 20 Dec 2005, Adrian Bunk wrote:
> 
> Thinking about this, what about the patch below?
> 
> I don't know whether this might break anything else, but it fixes my 
> problem.

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

Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

[Lee Revell]

On Tue, 2005-12-20 at 13:03 -0800, Linus Torvalds wrote:
> 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. 

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

Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

[Linus Torvalds]

On Tue, 20 Dec 2005, Lee Revell wrote:
> 
> With modules it's possible to test a new ALSA version without
> recompiling the kernel or even rebooting

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

Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

[Stephen Clark]

Lee Revell wrote:

>On Tue, 2005-12-20 at 13:03 -0800, Linus Torvalds wrote:
>  
>
>>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. 
>>    
>>
>
>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
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>  
>
Users don't want to be testers when they report problems and no on 
responds to the problem
report!

My $.02
Steve

Re: [RFC: 2.6 patch] Makefile: sound/ must come before drivers/

[Takashi Iwai]

At Tue, 20 Dec 2005 14:09:03 -0800 (PST),
Linus Torvalds wrote:
> 
> 
> 
> On Tue, 20 Dec 2005, Adrian Bunk wrote:
> > 
> > Thinking about this, what about the patch below?
> > 
> > I don't know whether this might break anything else, but it fixes my 
> > problem.
> 
> 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.

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

Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

[Takashi Iwai]

At Tue, 20 Dec 2005 21:23:25 +0100,
Adrian Bunk wrote:
> 
> On Tue, Dec 20, 2005 at 11:59:20AM -0800, Linus Torvalds wrote:
> > 
> > 
> > On Tue, 20 Dec 2005, Adrian Bunk wrote:
> > >
> > > > Adrian, does it work if you change the "module_init()" in 
> > > > sound/sound_core.c into a "fs_initcall()"?
> > > 
> > > No, this didn't work.
> > > 
> > > What did work was to leave sound/sound_core.c alone
> > 
> > Can you do try the other way again, with sound/core/sound.c fixed too?
> >...
> 
> 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.

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

Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

[Takashi Iwai]

At Tue, 20 Dec 2005 13:03:10 -0800 (PST),
Linus Torvalds wrote:
> 
> 
> 
> On Tue, 20 Dec 2005, James Courtier-Dutton wrote:
> >
> > 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.
> 
> Which, as a recommendation, is pure and utter crap.
> 
> > 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.
> 
> 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.

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.


> > I have no idea how to get the kernel to do this though. Any pointers?
> 
> 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.

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

Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

[Steve deRosier]

Linus Torvalds wrote:
> 
> 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,

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

Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

[Adrian Bunk]

On Wed, Dec 21, 2005 at 03:23:09PM +0100, Takashi Iwai wrote:
> At Tue, 20 Dec 2005 21:23:25 +0100,
> Adrian Bunk wrote:
> > 
> > On Tue, Dec 20, 2005 at 11:59:20AM -0800, Linus Torvalds wrote:
> > > 
> > > 
> > > On Tue, 20 Dec 2005, Adrian Bunk wrote:
> > > >
> > > > > Adrian, does it work if you change the "module_init()" in 
> > > > > sound/sound_core.c into a "fs_initcall()"?
> > > > 
> > > > No, this didn't work.
> > > > 
> > > > What did work was to leave sound/sound_core.c alone
> > > 
> > > Can you do try the other way again, with sound/core/sound.c fixed too?
> > >...
> > 
> > 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.
> 
> What is missing there?  No sound card entry in /proc/asound/cards?
>...

<--  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.

> Takashi

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

Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

[Linus Torvalds]

On Wed, 21 Dec 2005, Steve deRosier wrote:
> 
> Thankfully, we've never had to deal with this sort of failure; all of our Alsa
> drivers and services have been well behaved (mostly).

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

Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

[Linus Torvalds]

On Wed, 21 Dec 2005, Takashi Iwai wrote:
>
> (And, interestingly, fs_initcall() is rarely used in the whole fs/
>  codes!  "grep -r fs_initcall linux/fs" hits only one file.)

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

> 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.

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

Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

[Takashi Iwai]

At Wed, 21 Dec 2005 19:22:14 +0100,
Adrian Bunk wrote:
> 
> On Wed, Dec 21, 2005 at 03:23:09PM +0100, Takashi Iwai wrote:
> > At Tue, 20 Dec 2005 21:23:25 +0100,
> > Adrian Bunk wrote:
> > > 
> > > On Tue, Dec 20, 2005 at 11:59:20AM -0800, Linus Torvalds wrote:
> > > > 
> > > > 
> > > > On Tue, 20 Dec 2005, Adrian Bunk wrote:
> > > > >
> > > > > > Adrian, does it work if you change the "module_init()" in 
> > > > > > sound/sound_core.c into a "fs_initcall()"?
> > > > > 
> > > > > No, this didn't work.
> > > > > 
> > > > > What did work was to leave sound/sound_core.c alone
> > > > 
> > > > Can you do try the other way again, with sound/core/sound.c fixed too?
> > > >...
> > > 
> > > 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.
> > 
> > What is missing there?  No sound card entry in /proc/asound/cards?
> >...
> 
> <--  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.

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

Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

[Takashi Iwai]

At Wed, 21 Dec 2005 10:32:05 -0800 (PST),
Linus Torvalds wrote:
> 
> On Wed, 21 Dec 2005, Steve deRosier wrote:
> > 
> > Thankfully, we've never had to deal with this sort of failure; all of our Alsa
> > drivers and services have been well behaved (mostly).
> 
> 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. 

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

Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

[Takashi Iwai]

At Wed, 21 Dec 2005 10:32:41 -0800 (PST),
Linus Torvalds wrote:
> 
> On Wed, 21 Dec 2005, Takashi Iwai wrote:
> >
> > (And, interestingly, fs_initcall() is rarely used in the whole fs/
> >  codes!  "grep -r fs_initcall linux/fs" hits only one file.)
> 
> 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).

I see.  Thanks for clarification.

> > 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.
> 
> 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.

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

Re: [RFC: 2.6 patch] Makefile: sound/ must come before drivers/

[Mauro Carvalho Chehab]

Em Qua, 2005-12-21 às 15:21 +0100, Takashi Iwai escreveu:
> > 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.
> 
> Agreed, it looks too radical at this stage
Agreed.
> 
> 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. 
hmmm... this may break saa7134 code, since alsa stuff is dependent of
saa7134.ko.

Cheers, 
Mauro.

Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

[Adrian Bunk]

On Wed, Dec 21, 2005 at 07:38:39PM +0100, Takashi Iwai wrote:
> At Wed, 21 Dec 2005 19:22:14 +0100,
> Adrian Bunk wrote:
> > 
> > On Wed, Dec 21, 2005 at 03:23:09PM +0100, Takashi Iwai wrote:
> > > At Tue, 20 Dec 2005 21:23:25 +0100,
> > > Adrian Bunk wrote:
> > > > 
> > > > On Tue, Dec 20, 2005 at 11:59:20AM -0800, Linus Torvalds wrote:
> > > > > 
> > > > > 
> > > > > On Tue, 20 Dec 2005, Adrian Bunk wrote:
> > > > > >
> > > > > > > Adrian, does it work if you change the "module_init()" in 
> > > > > > > sound/sound_core.c into a "fs_initcall()"?
> > > > > > 
> > > > > > No, this didn't work.
> > > > > > 
> > > > > > What did work was to leave sound/sound_core.c alone
> > > > > 
> > > > > Can you do try the other way again, with sound/core/sound.c fixed too?
> > > > >...
> > > > 
> > > > 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.
> > > 
> > > What is missing there?  No sound card entry in /proc/asound/cards?
> > >...
> > 
> > <--  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.
> 
> Well, that's not anyway guaranteed unless you pass the proper index
> options.

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?

> In the case above, snd_via82xx.index=0 saa7134.index=1 should work.

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.

> Or you may tune with udev, too.

-ENOUDEV

> Takashi

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

Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

[Adrian Bunk]

On Wed, Dec 21, 2005 at 07:52:02PM +0100, Takashi Iwai wrote:
> At Wed, 21 Dec 2005 10:32:41 -0800 (PST),
> Linus Torvalds wrote:
>...
> > > 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.
> > 
> > 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.
> 
> 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.

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

> Takashi

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

Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

[R C]

Hi all;

On Wed, 2005-12-21 at 19:52 +0100, Takashi Iwai wrote:
> > 
> > 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.
> 
> 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.
> 

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

Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

[Adrian Bunk]

On Tue, Dec 20, 2005 at 06:35:30PM -0200, Mauro Carvalho Chehab wrote:
> Em Ter, 2005-12-20 às 20:14 +0100, Adrian Bunk escreveu:
> > (plus disabling building of saa7134-oss.o because
> > otherwise saa7134-alsa.o wouldn't do anything). 
> 
> 	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.

It works and looks good.

Can we get this patch into 2.6.15?

> Cheers, 
> Mauro.

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

2.6.15-rc6: known regressions in the kernel Bugzilla

[Adrian Bunk]

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

Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

[Greg KH]

On Thu, Dec 22, 2005 at 02:13:20AM +0100, Adrian Bunk wrote:
> 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)

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

Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

[Andrew Morton]

Adrian Bunk <bunk@stusta.de> wrote:
>
> The following bugs in the kernel Bugzilla [1] contain regressions in 
> 2.6.15-rc compared to 2.6.14 with patches:

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 <Brice.Goglin@ens-lyon.org>
Subject: Linux 2.6.14: Badness in as-iosched

From: Charles-Edouard Ruault <ce@ruault.com>
Subject: [BUG] kernel 2.6.14.2 breaks IPSEC

From: Michael Madore <michael.madore@gmail.com>
Subject: USB handoff, irq 193: nobody cared!

From: Wu Fengguang <wfg@mail.ustc.edu.cn>
Subject: BUG: spinlock recursion on 2.6.14-mm2 when oprofiling

From: Miles Lane <miles.lane@gmail.com>
Subject: 2.6.15-rc2-git6 + ipw2200 1.0.8 -- Slab corruption

From: "Gottfried Haider" <gohai@gmx.net>
Subject: [2.6.15-rc2] 8139too probe fails (pci related?)

From: Steve Work <swork@aventail.com>
Subject: Multi-thread corefiles broken since April

From: Diego Calleja <diegocg@gmail.com>
Subject: Oops with w9968cf

From: John Reiser <jreiser@BitWagon.com>
Subject: control placement of vDSO page

From: "P. Christeas" <p_christ@hol.gr>
Subject: No sound from CX23880 tuner w. 2.6.15-rc5

Subject: x86_64 timekeeping buglets
From: Jim Houston <jim.houston@comcast.net>

Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

[Mauro Carvalho Chehab]

Em Qui, 2005-12-22 às 01:59 +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.
> 
> It works and looks good.
> 
> Can we get this patch into 2.6.15?
	I've sent today to Linus for him to pull for 2.6.15.

Cheers, 
Mauro.

Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c

[Takashi Iwai]

At Wed, 21 Dec 2005 23:40:25 +0100,
Adrian Bunk wrote:
> 
> On Wed, Dec 21, 2005 at 07:38:39PM +0100, Takashi Iwai wrote:
> > At Wed, 21 Dec 2005 19:22:14 +0100,
> > Adrian Bunk wrote:
> > > 
> > > On Wed, Dec 21, 2005 at 03:23:09PM +0100, Takashi Iwai wrote:
> > > > At Tue, 20 Dec 2005 21:23:25 +0100,
> > > > Adrian Bunk wrote:
> > > > > 
> > > > > On Tue, Dec 20, 2005 at 11:59:20AM -0800, Linus Torvalds wrote:
> > > > > > 
> > > > > > 
> > > > > > On Tue, 20 Dec 2005, Adrian Bunk wrote:
> > > > > > >
> > > > > > > > Adrian, does it work if you change the "module_init()" in 
> > > > > > > > sound/sound_core.c into a "fs_initcall()"?
> > > > > > > 
> > > > > > > No, this didn't work.
> > > > > > > 
> > > > > > > What did work was to leave sound/sound_core.c alone
> > > > > > 
> > > > > > Can you do try the other way again, with sound/core/sound.c fixed too?
> > > > > >...
> > > > > 
> > > > > 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.
> > > > 
> > > > What is missing there?  No sound card entry in /proc/asound/cards?
> > > >...
> > > 
> > > <--  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.
> > 
> > Well, that's not anyway guaranteed unless you pass the proper index
> > options.
> 
> 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?

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.

> > In the case above, snd_via82xx.index=0 saa7134.index=1 should work.
> 
> This results in my soundcard being no longer available:
> 
> <--  snip  -->
> 
> ...
> Unknown boot option `saa7134.index=1': ignoring

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

> ...
> 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.

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

> > Or you may tune with udev, too.
> 
> -ENOUDEV

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


Takashi

Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

[Takashi Iwai]

At Wed, 21 Dec 2005 23:15:57 -0800,
Greg KH wrote:
> 
> On Thu, Dec 22, 2005 at 02:13:20AM +0100, Adrian Bunk wrote:
> > 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)
> 
> 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.

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

Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

[Adrian Bunk]

On Thu, Dec 22, 2005 at 12:52:09AM -0800, Andrew Morton wrote:
> Adrian Bunk <bunk@stusta.de> wrote:
> >
> > The following bugs in the kernel Bugzilla [1] contain regressions in 
> > 2.6.15-rc compared to 2.6.14 with patches:
> 
> Thanks for tracking this.  Although I fear it won't come to much.

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.

> non-bugzilla post-2.6.14 bugs which I've squirelled away include:
> 
> 
> From: Brice Goglin <Brice.Goglin@ens-lyon.org>
> Subject: Linux 2.6.14: Badness in as-iosched

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?

> From: Charles-Edouard Ruault <ce@ruault.com>
> Subject: [BUG] kernel 2.6.14.2 breaks IPSEC

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.

> From: Michael Madore <michael.madore@gmail.com>
> Subject: USB handoff, irq 193: nobody cared!

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

> From: Wu Fengguang <wfg@mail.ustc.edu.cn>
> Subject: BUG: spinlock recursion on 2.6.14-mm2 when oprofiling

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

> From: Miles Lane <miles.lane@gmail.com>
> Subject: 2.6.15-rc2-git6 + ipw2200 1.0.8 -- Slab corruption

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

> From: "Gottfried Haider" <gohai@gmx.net>
> Subject: [2.6.15-rc2] 8139too probe fails (pci related?)

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?

> From: Steve Work <swork@aventail.com>
> Subject: Multi-thread corefiles broken since April

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

> From: Diego Calleja <diegocg@gmail.com>
> Subject: Oops with w9968cf

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

> From: John Reiser <jreiser@BitWagon.com>
> Subject: control placement of vDSO page

This is not a post-2.6.14 regression.

> From: "P. Christeas" <p_christ@hol.gr>
> Subject: No sound from CX23880 tuner w. 2.6.15-rc5

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

> Subject: x86_64 timekeeping buglets
> From: Jim Houston <jim.houston@comcast.net>

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

Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

[Andrew Morton]

Adrian Bunk <bunk@stusta.de> wrote:
>
> not a post-2.6.14 regression
>

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..

Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

[David S. Miller]

From: Andrew Morton <akpm@osdl.org>
Date: Thu, 22 Dec 2005 00:52:09 -0800

> From: Charles-Edouard Ruault <ce@ruault.com>
> Subject: [BUG] kernel 2.6.14.2 breaks IPSEC

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.

Re: [RFC: 2.6 patch] Makefile: sound/ must come before drivers/

[Takashi Iwai]

At Wed, 21 Dec 2005 18:49:00 -0200,
Mauro Carvalho Chehab wrote:
> 
> > 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. 
> hmmm... this may break saa7134 code, since alsa stuff is dependent of
> saa7134.ko.

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

Re: [RFC: 2.6 patch] Makefile: sound/ must come before drivers/

[Mauro Carvalho Chehab]

Em Qui, 2005-12-22 às 16:32 +0100, Takashi Iwai escreveu:
> At Wed, 21 Dec 2005 18:49:00 -0200,
> Mauro Carvalho Chehab wrote:
> > 
> > > 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. 
> > hmmm... this may break saa7134 code, since alsa stuff is dependent of
> > saa7134.ko.
> 
> 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?
	saa7134-oss.
> 
> 
> Takashi
> 
Cheers, 
Mauro.

Re: [RFC: 2.6 patch] Makefile: sound/ must come before drivers/

[Takashi Iwai]

At Thu, 22 Dec 2005 14:06:57 -0200,
Mauro Carvalho Chehab wrote:
> 
> Em Qui, 2005-12-22 às 16:32 +0100, Takashi Iwai escreveu:
> > At Wed, 21 Dec 2005 18:49:00 -0200,
> > Mauro Carvalho Chehab wrote:
> > > 
> > > > 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. 
> > > hmmm... this may break saa7134 code, since alsa stuff is dependent of
> > > saa7134.ko.
> > 
> > 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?
> 	saa7134-oss.

It's obsolete to me ;)


Takashi

Re: [RFC: 2.6 patch] Makefile: sound/ must come before drivers/

[Mauro Carvalho Chehab]

Em Qui, 2005-12-22 às 17:17 +0100, Takashi Iwai escreveu:
> > > 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?
> >       saa7134-oss.
> 
> It's obsolete to me ;)
	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.

Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

[Brice Goglin]

Adrian Bunk wrote:

>>non-bugzilla post-2.6.14 bugs which I've squirelled away include:
>>
>>
>>From: Brice Goglin <Brice.Goglin@ens-lyon.org>
>>Subject: Linux 2.6.14: Badness in as-iosched
>>    
>>
>
>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?
>  
>
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

Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

[Mike Krufky]

Mauro Carvalho Chehab wrote:

>Em Qui, 2005-12-22 às 21:52 +0200, P. Christeas escreveu:
>  
>
>>On Thursday 22 December 2005 3:57 pm, you wrote:
>>    
>>
>>The two important tags are:
>>v2.6.13 0da688d20078783b23f99b232b272b027d6c3f59
>>v2.6.14-rc1 1f9d1e3248d4eb96b229eecf0e5d9445d3529e85
>>    
>>
>Christeas,
>
>	Between 2,6,13 and 2.6.14-rc1 we had about 220 v4l patches. It would
>help more if you get v4l CVS tree and try to identify the broken patch.
>there weren't so many patches for cx2388x. I suspect it might be some
>changes at tda9887, cx88-cards or cx88-tvaudio (the latest is the more
>likely).
>  
>
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)

Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

[Adrian Bunk]

On Thu, Dec 22, 2005 at 06:08:27AM -0800, Andrew Morton wrote:
> Adrian Bunk <bunk@stusta.de> wrote:
> >
> > not a post-2.6.14 regression
> >
> 
> 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

Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

[Michael Krufky]

P. Christeas wrote:

>On Friday 23 December 2005 12:55 am, you wrote:
>  
>
>>>Christeas,
>>>
>>>	Between 2,6,13 and 2.6.14-rc1 we had about 220 v4l patches. It would
>>>help more if you get v4l CVS tree and try to identify the broken patch.
>>>there weren't so many patches for cx2388x. I suspect it might be some
>>>changes at tda9887, cx88-cards or cx88-tvaudio (the latest is the more
>>>likely).
>>>      
>>>
>>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-bis
>>ect.txt
>>
>>Cheers,
>>Michael Krufky
>>
>>    
>>
>I just discovered 'bisect', too, and are using it.
>
>Andrew, it would be nice to have a 'limited' bisect when whe know which 
>subsystem we are narrowing to:
>git bisect start drivers/media/video/cx88/
>Theoretically speaking, I shouldn't even rebuild but the module alone..
>  
>
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

Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

[Gottfried Haider]

>> From: "Gottfried Haider" <gohai@gmx.net>
>> Subject: [2.6.15-rc2] 8139too probe fails (pci related?)
> 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?
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 

Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

[Bill Davidsen]

Andrew Morton wrote:
> Adrian Bunk <bunk@stusta.de> wrote:
> 
>>not a post-2.6.14 regression
>>
> 
> 
> 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..

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 (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

[Michael Krufky]

On 12/23/05, Bill Davidsen <davidsen@tmr.com> wrote:
> Andrew Morton wrote:
> > Adrian Bunk <bunk@stusta.de> wrote:
> >
> >>not a post-2.6.14 regression
> >>
> >
> >
> > 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..
>
> 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.

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

Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

[Andrew Morton]

Michael Krufky <mkrufky@gmail.com> wrote:
>
> On 12/23/05, Bill Davidsen <davidsen@tmr.com> wrote:
> > Andrew Morton wrote:
> > > Adrian Bunk <bunk@stusta.de> wrote:
> > >
> > >>not a post-2.6.14 regression
> > >>
> > >
> > >
> > > 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..
> >
> > 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.
> 
> 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? 

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.

> ESPECIALLY given that patches are said to be available?

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.

> 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?

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.

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

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.

Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

[Bill Davidsen]

Andrew Morton wrote:

>Michael Krufky <mkrufky@gmail.com> wrote:
>  
>
>>On 12/23/05, Bill Davidsen <davidsen@tmr.com> wrote:
>>    
>>
>>>Andrew Morton wrote:
>>>      
>>>
>>>>Adrian Bunk <bunk@stusta.de> wrote:
>>>>
>>>>        
>>>>
>>>>>not a post-2.6.14 regression
>>>>>
>>>>>          
>>>>>
>>>>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..
>>>>        
>>>>
>>>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.
>>>      
>>>
>>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? 
>>    
>>
>
>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.
>
>  
>
>>ESPECIALLY given that patches are said to be available?
>>    
>>
>
>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.
>
>  
>
>>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?
>>    
>>
>
>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.
>
>  
>
>>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)
>>    
>>
>
>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.
>  
>
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.

>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.
>
>  
>
Good luck. Someone qualified to do that job would also be qualified to 
do more interesting things...

-- 
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

[Michael Krufky]

On 12/23/05, Andrew Morton <akpm@osdl.org> wrote:
> Michael Krufky <mkrufky@gmail.com> wrote:
> >
> > On 12/23/05, Bill Davidsen <davidsen@tmr.com> wrote:
> > > Andrew Morton wrote:
> > > > Adrian Bunk <bunk@stusta.de> wrote:
> > > >
> > > >>not a post-2.6.14 regression
> > > >>
> > > >
> > > >
> > > > 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..
> > >
> > > 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.
> >
> > 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?
>
> 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.
>
> > ESPECIALLY given that patches are said to be available?
>
> 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.
>
> > 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?
>
> 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.
>
> > 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)
>
> 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.

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

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

-MiKE

Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

[Lee Revell]

On Fri, 2005-12-23 at 19:54 -0800, Andrew Morton wrote:
> 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. 

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

Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

[Adrian Bunk]

On Thu, Dec 22, 2005 at 01:04:23PM +0100, Takashi Iwai wrote:
> At Wed, 21 Dec 2005 23:15:57 -0800,
> Greg KH wrote:
> > 
> > On Thu, Dec 22, 2005 at 02:13:20AM +0100, Adrian Bunk wrote:
> > > 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)
> > 
> > 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.
> 
> 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.

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.

> Takashi

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

Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

[Lee Revell]

On Thu, 2005-12-29 at 14:23 +0100, Adrian Bunk wrote:
> On Thu, Dec 22, 2005 at 01:04:23PM +0100, Takashi Iwai wrote:
> > At Wed, 21 Dec 2005 23:15:57 -0800,
> > Greg KH wrote:
> > > 
> > > On Thu, Dec 22, 2005 at 02:13:20AM +0100, Adrian Bunk wrote:
> > > > 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)
> > > 
> > > 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.
> > 
> > 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.
> 
> 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.
> 
> > Takashi

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

Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

[Adrian Bunk]

On Fri, Dec 23, 2005 at 12:50:22PM +0100, Gottfried Haider wrote:
> >>From: "Gottfried Haider" <gohai@gmx.net>
> >>Subject: [2.6.15-rc2] 8139too probe fails (pci related?)
> >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?
> 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.

Greg, can you comment on this issue?

> Gottfried Haider 

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

Re: 2.6.15-rc6: known regressions in the kernel Bugzilla

[Greg KH]

On Mon, Jan 02, 2006 at 05:00:31PM +0100, Adrian Bunk wrote:
> On Fri, Dec 23, 2005 at 12:50:22PM +0100, Gottfried Haider wrote:
> > >>From: "Gottfried Haider" <gohai@gmx.net>
> > >>Subject: [2.6.15-rc2] 8139too probe fails (pci related?)
> > >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?
> > 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.
> 
> Greg, can you comment on this issue?

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

greg k-h

Re: Linux 2.6.15-rc6

[Voluspa]

On Tue, 20 Dec 2005 21:33:28 -0800 (PST) Linus Torvalds wrote:
[...]
> But it might make sense to open a bugzilla entry so that it doesn't get 
> lost.

http://bugzilla.kernel.org/show_bug.cgi?id=5767

For anyone stumbling into this problem, lacking git experience, here's
a 1/10-revert patch that gives me back the former functionality. It
behaves exactly as in 2.6.14 with regards to C1 usage and thermal_zone
temperatures etc.

diff -Nur linux-2.6.15-rc6-clean/drivers/acpi/processor_idle.c linux-2.6.15-rc6-c1fix/drivers/acpi/processor_idle.c
--- linux-2.6.15-rc6-clean/drivers/acpi/processor_idle.c	2005-12-21 13:29:12.000000000 +0100
+++ linux-2.6.15-rc6-c1fix/drivers/acpi/processor_idle.c	2005-12-21 13:39:04.000000000 +0100
@@ -893,7 +893,7 @@
 	for (i = 1; i < ACPI_PROCESSOR_MAX_POWER; i++) {
 		if (pr->power.states[i].valid) {
 			pr->power.count = i;
-			if (pr->power.states[i].type >= ACPI_STATE_C2)
+			if (pr->power.states[i].type >= ACPI_STATE_C1)
 				pr->flags.power = 1;
 		}
 	}

Mvh
Mats Johannesson
--

Re: Linux 2.6.15-rc6

[Voluspa]

On Tue, 20 Dec 2005 21:33:28 -0800 (PST) Linus Torvalds wrote:
[...]
> > 2203d6ed448ff3b777ee6bb614a53e686b483e5b:
> >
> >     Fix ACPI processor power block initialization
> 
> I'd love to have it fixed, but quite frankly, if the choice is between a 
> boot-time lockup and not using ACPI C1 sleep states, I'll take the 
> non-working sleep states.
> 
> The code in question had comments that didn't match what it was doing, and 
> apparently the ACPI guys couldn't say what was wrong..
> 
> But it might make sense to open a bugzilla entry so that it doesn't get 
> lost.

No sweat, it's easy to revert locally. I'll open a report once I've registered
at the bugzilla.

God Jul (och se upp med revbenen!)
Mats Johannesson
--

Re: Linux 2.6.15-rc6

[Linus Torvalds]

On Wed, 21 Dec 2005, Voluspa wrote:
> 
> Not so in 2.6.15-rc2 to -rc6 (report http://marc.theaimsgroup.com/?l=linux-kernel&m=113498252000221&w=2 )
> Culprit is the following commit that I humbly ask to be removed/rewritten:
> 
> 2203d6ed448ff3b777ee6bb614a53e686b483e5b:
>
>     Fix ACPI processor power block initialization

I'd love to have it fixed, but quite frankly, if the choice is between a 
boot-time lockup and not using ACPI C1 sleep states, I'll take the 
non-working sleep states.

The code in question had comments that didn't match what it was doing, and 
apparently the ACPI guys couldn't say what was wrong..

But it might make sense to open a bugzilla entry so that it doesn't get 
lost.

		Linus

Re: Linux 2.6.15-rc6

[Voluspa]

I know that C1 isn't much of a power save, but that's what my amd64
notebook provides, and it get used in 2.6.14:

loke@sleipner:~$ cat /proc/acpi/processor/CPU0/power
active state:            C1
max_cstate:              C8
bus master activity:     00000000
states:
   *C1:                  type[C1] promotion[--] demotion[--] latency[000] usage[01399981]

Not so in 2.6.15-rc2 to -rc6 (report http://marc.theaimsgroup.com/?l=linux-kernel&m=113498252000221&w=2 )
Culprit is the following commit that I humbly ask to be removed/rewritten:

root@sleipner:/home/git/linux-2.6# git bisect bad
2203d6ed448ff3b777ee6bb614a53e686b483e5b is first bad commit
diff-tree 2203d6ed448ff3b777ee6bb614a53e686b483e5b (from 2656c076e31a3ce3ab2a987a578e7122dc2af51d)
Author: Linus Torvalds <torvalds@g5.osdl.org>
Date:   Fri Nov 18 07:29:51 2005 -0800

    Fix ACPI processor power block initialization

    Properly clear the memory, and set "pr->flags.power" only if a C2 or
    deeper state is valid (to make the code match both the comment and
    previous behaviour).

    This fixes a boot-time lockup reported by Maneesh Soni when using
    "maxcpus=1".

    Acked-by: Maneesh Soni <maneesh@in.ibm.com>
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>

:040000 040000 52be621b960ae192b36acf778c966d78ff5edbe2 04c183ce141dab8cdff049c1dae379104b637ed4 M      drivers

Mvh
Mats Johannesson
--

Re: Linux 2.6.15-rc6

[Voluspa]

Total loss of ACPI C-states (even C1 is unused) has survived from -rc5
to -rc6. See short thread:

[ACPI] Fw: Re: 2.6.15-rc5-mm1
http://marc.theaimsgroup.com/?t=113383872000001&r=1&w=2

The issue seems to be fixed in 2.6.15-rc5-mm3, but no public figure has
explained how or sent any specific patch for it:

[ACPI] Re: 2.6.15-rc5-mm3
http://marc.theaimsgroup.com/?l=acpi4linux&m=113464591421744&w=2

Mvh
Mats Johannesson
--