* Linux 2.6.15-rc6 @ 2005-12-19 0:47 Linus Torvalds 2005-12-19 1:30 ` Diego Calleja ` (2 more replies) 0 siblings, 3 replies; 66+ messages in thread From: Linus Torvalds @ 2005-12-19 0:47 UTC (permalink / raw) To: Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Linux 2.6.15-rc6 2005-12-19 0:47 Linux 2.6.15-rc6 Linus Torvalds @ 2005-12-19 1:30 ` Diego Calleja 2005-12-19 5:41 ` Willy Tarreau 2005-12-20 13:18 ` 2.6.15-rc6: boot failure in saa7134-alsa.c Adrian Bunk 2005-12-22 1:13 ` 2.6.15-rc6: known regressions in the kernel Bugzilla Adrian Bunk 2 siblings, 1 reply; 66+ messages in thread From: Diego Calleja @ 2005-12-19 1:30 UTC (permalink / raw) To: Linus Torvalds; +Cc: linux-kernel, matthltc 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) ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: Linux 2.6.15-rc6 2005-12-19 1:30 ` Diego Calleja @ 2005-12-19 5:41 ` Willy Tarreau 0 siblings, 0 replies; 66+ messages in thread From: Willy Tarreau @ 2005-12-19 5:41 UTC (permalink / raw) To: Diego Calleja; +Cc: Linus Torvalds, linux-kernel, matthltc 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* 2.6.15-rc6: boot failure in saa7134-alsa.c 2005-12-19 0:47 Linux 2.6.15-rc6 Linus Torvalds 2005-12-19 1:30 ` Diego Calleja @ 2005-12-20 13:18 ` Adrian Bunk 2005-12-20 15:52 ` [Alsa-devel] " Sergey Vlasov 2005-12-22 1:13 ` 2.6.15-rc6: known regressions in the kernel Bugzilla Adrian Bunk 2 siblings, 1 reply; 66+ messages in thread From: Adrian Bunk @ 2005-12-20 13:18 UTC (permalink / raw) To: Linus Torvalds, Ricardo Cerqueira, mchehab Cc: Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c 2005-12-20 13:18 ` 2.6.15-rc6: boot failure in saa7134-alsa.c Adrian Bunk @ 2005-12-20 15:52 ` Sergey Vlasov 2005-12-20 18:24 ` Linus Torvalds 0 siblings, 1 reply; 66+ messages in thread From: Sergey Vlasov @ 2005-12-20 15:52 UTC (permalink / raw) To: Adrian Bunk Cc: Linus Torvalds, Ricardo Cerqueira, mchehab, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel [-- 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 --] ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c 2005-12-20 15:52 ` [Alsa-devel] " Sergey Vlasov @ 2005-12-20 18:24 ` Linus Torvalds [not found] ` <20051220183455.GC19797@master.mivlgu.local> 2005-12-20 19:14 ` Adrian Bunk 0 siblings, 2 replies; 66+ messages in thread From: Linus Torvalds @ 2005-12-20 18:24 UTC (permalink / raw) To: Sergey Vlasov Cc: Adrian Bunk, Ricardo Cerqueira, mchehab, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
[parent not found: <20051220183455.GC19797@master.mivlgu.local>]
* Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c [not found] ` <20051220183455.GC19797@master.mivlgu.local> @ 2005-12-20 18:57 ` Linus Torvalds 0 siblings, 0 replies; 66+ messages in thread From: Linus Torvalds @ 2005-12-20 18:57 UTC (permalink / raw) To: Adrian Bunk, Ricardo Cerqueira, mchehab, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel, Sergey Vlasov 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. > ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c 2005-12-20 18:24 ` Linus Torvalds [not found] ` <20051220183455.GC19797@master.mivlgu.local> @ 2005-12-20 19:14 ` Adrian Bunk 2005-12-20 19:23 ` Mauro Carvalho Chehab ` (2 more replies) 1 sibling, 3 replies; 66+ messages in thread From: Adrian Bunk @ 2005-12-20 19:14 UTC (permalink / raw) To: Linus Torvalds Cc: Sergey Vlasov, Ricardo Cerqueira, mchehab, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c 2005-12-20 19:14 ` Adrian Bunk @ 2005-12-20 19:23 ` Mauro Carvalho Chehab 2005-12-20 19:59 ` Linus Torvalds 2005-12-20 20:35 ` Mauro Carvalho Chehab 2 siblings, 0 replies; 66+ messages in thread From: Mauro Carvalho Chehab @ 2005-12-20 19:23 UTC (permalink / raw) To: Adrian Bunk Cc: Linus Torvalds, Sergey Vlasov, Ricardo Cerqueira, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c 2005-12-20 19:14 ` Adrian Bunk 2005-12-20 19:23 ` Mauro Carvalho Chehab @ 2005-12-20 19:59 ` Linus Torvalds 2005-12-20 20:23 ` Adrian Bunk 2005-12-20 20:35 ` James Courtier-Dutton 2005-12-20 20:35 ` Mauro Carvalho Chehab 2 siblings, 2 replies; 66+ messages in thread From: Linus Torvalds @ 2005-12-20 19:59 UTC (permalink / raw) To: Adrian Bunk Cc: Sergey Vlasov, Ricardo Cerqueira, mchehab, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c 2005-12-20 19:59 ` Linus Torvalds @ 2005-12-20 20:23 ` Adrian Bunk 2005-12-20 20:41 ` Linus Torvalds 2005-12-21 14:23 ` [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c Takashi Iwai 2005-12-20 20:35 ` James Courtier-Dutton 1 sibling, 2 replies; 66+ messages in thread From: Adrian Bunk @ 2005-12-20 20:23 UTC (permalink / raw) To: Linus Torvalds Cc: Sergey Vlasov, Ricardo Cerqueira, mchehab, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c 2005-12-20 20:23 ` Adrian Bunk @ 2005-12-20 20:41 ` Linus Torvalds 2005-12-20 20:47 ` James Courtier-Dutton 2005-12-21 14:23 ` [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c Takashi Iwai 1 sibling, 1 reply; 66+ messages in thread From: Linus Torvalds @ 2005-12-20 20:41 UTC (permalink / raw) To: Adrian Bunk Cc: Sergey Vlasov, Ricardo Cerqueira, mchehab, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c 2005-12-20 20:41 ` Linus Torvalds @ 2005-12-20 20:47 ` James Courtier-Dutton 2005-12-20 21:06 ` Linus Torvalds 2005-12-20 21:13 ` [RFC: 2.6 patch] Makefile: sound/ must come before drivers/ Adrian Bunk 0 siblings, 2 replies; 66+ messages in thread From: James Courtier-Dutton @ 2005-12-20 20:47 UTC (permalink / raw) To: Linus Torvalds Cc: Adrian Bunk, Sergey Vlasov, Ricardo Cerqueira, mchehab, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c 2005-12-20 20:47 ` James Courtier-Dutton @ 2005-12-20 21:06 ` Linus Torvalds 2005-12-20 21:13 ` [RFC: 2.6 patch] Makefile: sound/ must come before drivers/ Adrian Bunk 1 sibling, 0 replies; 66+ messages in thread From: Linus Torvalds @ 2005-12-20 21:06 UTC (permalink / raw) To: James Courtier-Dutton Cc: Adrian Bunk, Sergey Vlasov, Ricardo Cerqueira, mchehab, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* [RFC: 2.6 patch] Makefile: sound/ must come before drivers/ 2005-12-20 20:47 ` James Courtier-Dutton 2005-12-20 21:06 ` Linus Torvalds @ 2005-12-20 21:13 ` Adrian Bunk 2005-12-20 21:24 ` [Alsa-devel] " Jaroslav Kysela 2005-12-20 22:09 ` Linus Torvalds 1 sibling, 2 replies; 66+ messages in thread From: Adrian Bunk @ 2005-12-20 21:13 UTC (permalink / raw) To: James Courtier-Dutton Cc: Linus Torvalds, Sergey Vlasov, Ricardo Cerqueira, mchehab, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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/ ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [Alsa-devel] [RFC: 2.6 patch] Makefile: sound/ must come before drivers/ 2005-12-20 21:13 ` [RFC: 2.6 patch] Makefile: sound/ must come before drivers/ Adrian Bunk @ 2005-12-20 21:24 ` Jaroslav Kysela 2005-12-20 22:09 ` Linus Torvalds 1 sibling, 0 replies; 66+ messages in thread From: Jaroslav Kysela @ 2005-12-20 21:24 UTC (permalink / raw) To: Adrian Bunk Cc: James Courtier-Dutton, Linus Torvalds, Sergey Vlasov, Ricardo Cerqueira, mchehab, Linux Kernel Mailing List, video4linux-list, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [RFC: 2.6 patch] Makefile: sound/ must come before drivers/ 2005-12-20 21:13 ` [RFC: 2.6 patch] Makefile: sound/ must come before drivers/ Adrian Bunk 2005-12-20 21:24 ` [Alsa-devel] " Jaroslav Kysela @ 2005-12-20 22:09 ` Linus Torvalds 2005-12-21 14:21 ` Takashi Iwai 1 sibling, 1 reply; 66+ messages in thread From: Linus Torvalds @ 2005-12-20 22:09 UTC (permalink / raw) To: Adrian Bunk Cc: James Courtier-Dutton, Sergey Vlasov, Ricardo Cerqueira, mchehab, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [RFC: 2.6 patch] Makefile: sound/ must come before drivers/ 2005-12-20 22:09 ` Linus Torvalds @ 2005-12-21 14:21 ` Takashi Iwai 2005-12-21 20:49 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 66+ messages in thread From: Takashi Iwai @ 2005-12-21 14:21 UTC (permalink / raw) To: Linus Torvalds Cc: Adrian Bunk, James Courtier-Dutton, Sergey Vlasov, Ricardo Cerqueira, mchehab, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [RFC: 2.6 patch] Makefile: sound/ must come before drivers/ 2005-12-21 14:21 ` Takashi Iwai @ 2005-12-21 20:49 ` Mauro Carvalho Chehab 2005-12-22 15:32 ` Takashi Iwai 0 siblings, 1 reply; 66+ messages in thread From: Mauro Carvalho Chehab @ 2005-12-21 20:49 UTC (permalink / raw) To: Takashi Iwai Cc: Linus Torvalds, Adrian Bunk, James Courtier-Dutton, Sergey Vlasov, Ricardo Cerqueira, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [RFC: 2.6 patch] Makefile: sound/ must come before drivers/ 2005-12-21 20:49 ` Mauro Carvalho Chehab @ 2005-12-22 15:32 ` Takashi Iwai 2005-12-22 16:06 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 66+ messages in thread From: Takashi Iwai @ 2005-12-22 15:32 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Linus Torvalds, Adrian Bunk, James Courtier-Dutton, Sergey Vlasov, Ricardo Cerqueira, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [RFC: 2.6 patch] Makefile: sound/ must come before drivers/ 2005-12-22 15:32 ` Takashi Iwai @ 2005-12-22 16:06 ` Mauro Carvalho Chehab 2005-12-22 16:17 ` Takashi Iwai 0 siblings, 1 reply; 66+ messages in thread From: Mauro Carvalho Chehab @ 2005-12-22 16:06 UTC (permalink / raw) To: Takashi Iwai Cc: Linus Torvalds, Adrian Bunk, James Courtier-Dutton, Sergey Vlasov, Ricardo Cerqueira, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [RFC: 2.6 patch] Makefile: sound/ must come before drivers/ 2005-12-22 16:06 ` Mauro Carvalho Chehab @ 2005-12-22 16:17 ` Takashi Iwai 2005-12-22 16:38 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 66+ messages in thread From: Takashi Iwai @ 2005-12-22 16:17 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Linus Torvalds, Adrian Bunk, James Courtier-Dutton, Sergey Vlasov, Ricardo Cerqueira, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [RFC: 2.6 patch] Makefile: sound/ must come before drivers/ 2005-12-22 16:17 ` Takashi Iwai @ 2005-12-22 16:38 ` Mauro Carvalho Chehab 0 siblings, 0 replies; 66+ messages in thread From: Mauro Carvalho Chehab @ 2005-12-22 16:38 UTC (permalink / raw) To: Takashi Iwai Cc: Linus Torvalds, Adrian Bunk, James Courtier-Dutton, Sergey Vlasov, Ricardo Cerqueira, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c 2005-12-20 20:23 ` Adrian Bunk 2005-12-20 20:41 ` Linus Torvalds @ 2005-12-21 14:23 ` Takashi Iwai 2005-12-21 18:22 ` Adrian Bunk 1 sibling, 1 reply; 66+ messages in thread From: Takashi Iwai @ 2005-12-21 14:23 UTC (permalink / raw) To: Adrian Bunk Cc: Linus Torvalds, Sergey Vlasov, Ricardo Cerqueira, mchehab, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c 2005-12-21 14:23 ` [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c Takashi Iwai @ 2005-12-21 18:22 ` Adrian Bunk 2005-12-21 18:38 ` Takashi Iwai 0 siblings, 1 reply; 66+ messages in thread From: Adrian Bunk @ 2005-12-21 18:22 UTC (permalink / raw) To: Takashi Iwai Cc: Linus Torvalds, Sergey Vlasov, Ricardo Cerqueira, mchehab, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c 2005-12-21 18:22 ` Adrian Bunk @ 2005-12-21 18:38 ` Takashi Iwai 2005-12-21 22:40 ` Adrian Bunk 0 siblings, 1 reply; 66+ messages in thread From: Takashi Iwai @ 2005-12-21 18:38 UTC (permalink / raw) To: Adrian Bunk Cc: Linus Torvalds, Sergey Vlasov, Ricardo Cerqueira, mchehab, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c 2005-12-21 18:38 ` Takashi Iwai @ 2005-12-21 22:40 ` Adrian Bunk 2005-12-22 11:39 ` Takashi Iwai 0 siblings, 1 reply; 66+ messages in thread From: Adrian Bunk @ 2005-12-21 22:40 UTC (permalink / raw) To: Takashi Iwai Cc: Linus Torvalds, Sergey Vlasov, Ricardo Cerqueira, mchehab, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c 2005-12-21 22:40 ` Adrian Bunk @ 2005-12-22 11:39 ` Takashi Iwai 0 siblings, 0 replies; 66+ messages in thread From: Takashi Iwai @ 2005-12-22 11:39 UTC (permalink / raw) To: Adrian Bunk Cc: Linus Torvalds, Sergey Vlasov, Ricardo Cerqueira, mchehab, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c 2005-12-20 19:59 ` Linus Torvalds 2005-12-20 20:23 ` Adrian Bunk @ 2005-12-20 20:35 ` James Courtier-Dutton 2005-12-20 21:03 ` Linus Torvalds 1 sibling, 1 reply; 66+ messages in thread From: James Courtier-Dutton @ 2005-12-20 20:35 UTC (permalink / raw) To: Linus Torvalds Cc: Adrian Bunk, Sergey Vlasov, Ricardo Cerqueira, mchehab, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c 2005-12-20 20:35 ` James Courtier-Dutton @ 2005-12-20 21:03 ` Linus Torvalds 2005-12-20 22:17 ` Lee Revell ` (2 more replies) 0 siblings, 3 replies; 66+ messages in thread From: Linus Torvalds @ 2005-12-20 21:03 UTC (permalink / raw) To: James Courtier-Dutton Cc: Adrian Bunk, Sergey Vlasov, Ricardo Cerqueira, mchehab, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c 2005-12-20 21:03 ` Linus Torvalds @ 2005-12-20 22:17 ` Lee Revell 2005-12-21 1:29 ` Linus Torvalds 2005-12-21 13:29 ` Stephen Clark 2005-12-21 14:39 ` Takashi Iwai 2005-12-21 16:58 ` Steve deRosier 2 siblings, 2 replies; 66+ messages in thread From: Lee Revell @ 2005-12-20 22:17 UTC (permalink / raw) To: Linus Torvalds Cc: James Courtier-Dutton, Adrian Bunk, Sergey Vlasov, Ricardo Cerqueira, mchehab, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c 2005-12-20 22:17 ` Lee Revell @ 2005-12-21 1:29 ` Linus Torvalds 2005-12-21 13:29 ` Stephen Clark 1 sibling, 0 replies; 66+ messages in thread From: Linus Torvalds @ 2005-12-21 1:29 UTC (permalink / raw) To: Lee Revell Cc: James Courtier-Dutton, Adrian Bunk, Sergey Vlasov, Ricardo Cerqueira, mchehab, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c 2005-12-20 22:17 ` Lee Revell 2005-12-21 1:29 ` Linus Torvalds @ 2005-12-21 13:29 ` Stephen Clark 1 sibling, 0 replies; 66+ messages in thread From: Stephen Clark @ 2005-12-21 13:29 UTC (permalink / raw) To: Lee Revell Cc: Linus Torvalds, James Courtier-Dutton, Adrian Bunk, Sergey Vlasov, Ricardo Cerqueira, mchehab, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c 2005-12-20 21:03 ` Linus Torvalds 2005-12-20 22:17 ` Lee Revell @ 2005-12-21 14:39 ` Takashi Iwai 2005-12-21 18:32 ` Linus Torvalds 2005-12-21 16:58 ` Steve deRosier 2 siblings, 1 reply; 66+ messages in thread From: Takashi Iwai @ 2005-12-21 14:39 UTC (permalink / raw) To: Linus Torvalds Cc: James Courtier-Dutton, Adrian Bunk, Sergey Vlasov, Ricardo Cerqueira, mchehab, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c 2005-12-21 14:39 ` Takashi Iwai @ 2005-12-21 18:32 ` Linus Torvalds 2005-12-21 18:52 ` Takashi Iwai 0 siblings, 1 reply; 66+ messages in thread From: Linus Torvalds @ 2005-12-21 18:32 UTC (permalink / raw) To: Takashi Iwai Cc: James Courtier-Dutton, Adrian Bunk, Sergey Vlasov, Ricardo Cerqueira, mchehab, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c 2005-12-21 18:32 ` Linus Torvalds @ 2005-12-21 18:52 ` Takashi Iwai 2005-12-21 22:42 ` Adrian Bunk 2005-12-21 22:50 ` R C 0 siblings, 2 replies; 66+ messages in thread From: Takashi Iwai @ 2005-12-21 18:52 UTC (permalink / raw) To: Linus Torvalds Cc: James Courtier-Dutton, Adrian Bunk, Sergey Vlasov, Ricardo Cerqueira, mchehab, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c 2005-12-21 18:52 ` Takashi Iwai @ 2005-12-21 22:42 ` Adrian Bunk 2005-12-21 22:50 ` R C 1 sibling, 0 replies; 66+ messages in thread From: Adrian Bunk @ 2005-12-21 22:42 UTC (permalink / raw) To: Takashi Iwai Cc: Linus Torvalds, James Courtier-Dutton, Sergey Vlasov, Ricardo Cerqueira, mchehab, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c 2005-12-21 18:52 ` Takashi Iwai 2005-12-21 22:42 ` Adrian Bunk @ 2005-12-21 22:50 ` R C 1 sibling, 0 replies; 66+ messages in thread From: R C @ 2005-12-21 22:50 UTC (permalink / raw) To: Takashi Iwai Cc: Linus Torvalds, James Courtier-Dutton, Adrian Bunk, Sergey Vlasov, mchehab, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c 2005-12-20 21:03 ` Linus Torvalds 2005-12-20 22:17 ` Lee Revell 2005-12-21 14:39 ` Takashi Iwai @ 2005-12-21 16:58 ` Steve deRosier 2005-12-21 18:32 ` Linus Torvalds 2 siblings, 1 reply; 66+ messages in thread From: Steve deRosier @ 2005-12-21 16:58 UTC (permalink / raw) To: Linus Torvalds Cc: James Courtier-Dutton, Adrian Bunk, Sergey Vlasov, Ricardo Cerqueira, mchehab, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c 2005-12-21 16:58 ` Steve deRosier @ 2005-12-21 18:32 ` Linus Torvalds 2005-12-21 18:41 ` Takashi Iwai 0 siblings, 1 reply; 66+ messages in thread From: Linus Torvalds @ 2005-12-21 18:32 UTC (permalink / raw) To: Steve deRosier Cc: James Courtier-Dutton, Adrian Bunk, Sergey Vlasov, Ricardo Cerqueira, mchehab, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c 2005-12-21 18:32 ` Linus Torvalds @ 2005-12-21 18:41 ` Takashi Iwai 0 siblings, 0 replies; 66+ messages in thread From: Takashi Iwai @ 2005-12-21 18:41 UTC (permalink / raw) To: Linus Torvalds Cc: Steve deRosier, James Courtier-Dutton, Adrian Bunk, Sergey Vlasov, Ricardo Cerqueira, mchehab, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c 2005-12-20 19:14 ` Adrian Bunk 2005-12-20 19:23 ` Mauro Carvalho Chehab 2005-12-20 19:59 ` Linus Torvalds @ 2005-12-20 20:35 ` Mauro Carvalho Chehab 2005-12-22 0:59 ` Adrian Bunk 2 siblings, 1 reply; 66+ messages in thread From: Mauro Carvalho Chehab @ 2005-12-20 20:35 UTC (permalink / raw) To: Adrian Bunk Cc: Linus Torvalds, Sergey Vlasov, Ricardo Cerqueira, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel [-- 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; ^ permalink raw reply related [flat|nested] 66+ messages in thread
* Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c 2005-12-20 20:35 ` Mauro Carvalho Chehab @ 2005-12-22 0:59 ` Adrian Bunk 2005-12-22 11:15 ` Mauro Carvalho Chehab 0 siblings, 1 reply; 66+ messages in thread From: Adrian Bunk @ 2005-12-22 0:59 UTC (permalink / raw) To: Mauro Carvalho Chehab Cc: Linus Torvalds, Sergey Vlasov, Ricardo Cerqueira, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c 2005-12-22 0:59 ` Adrian Bunk @ 2005-12-22 11:15 ` Mauro Carvalho Chehab 0 siblings, 0 replies; 66+ messages in thread From: Mauro Carvalho Chehab @ 2005-12-22 11:15 UTC (permalink / raw) To: Adrian Bunk Cc: Linus Torvalds, Sergey Vlasov, Ricardo Cerqueira, Linux Kernel Mailing List, video4linux-list, perex, alsa-devel 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* 2.6.15-rc6: known regressions in the kernel Bugzilla 2005-12-19 0:47 Linux 2.6.15-rc6 Linus Torvalds 2005-12-19 1:30 ` Diego Calleja 2005-12-20 13:18 ` 2.6.15-rc6: boot failure in saa7134-alsa.c Adrian Bunk @ 2005-12-22 1:13 ` Adrian Bunk 2005-12-22 7:15 ` Greg KH 2005-12-22 8:52 ` Andrew Morton 2 siblings, 2 replies; 66+ messages in thread From: Adrian Bunk @ 2005-12-22 1:13 UTC (permalink / raw) To: Linus Torvalds, Andrew Morton Cc: Linux Kernel Mailing List, aabdulla, jgarzik, netdev, ak, discuss, perex, alsa-devel, gregkh 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: 2.6.15-rc6: known regressions in the kernel Bugzilla 2005-12-22 1:13 ` 2.6.15-rc6: known regressions in the kernel Bugzilla Adrian Bunk @ 2005-12-22 7:15 ` Greg KH 2005-12-22 12:04 ` Takashi Iwai 2005-12-22 8:52 ` Andrew Morton 1 sibling, 1 reply; 66+ messages in thread From: Greg KH @ 2005-12-22 7:15 UTC (permalink / raw) To: Adrian Bunk Cc: Linus Torvalds, Andrew Morton, Linux Kernel Mailing List, aabdulla, jgarzik, netdev, ak, discuss, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: 2.6.15-rc6: known regressions in the kernel Bugzilla 2005-12-22 7:15 ` Greg KH @ 2005-12-22 12:04 ` Takashi Iwai 2005-12-29 13:23 ` Adrian Bunk 0 siblings, 1 reply; 66+ messages in thread From: Takashi Iwai @ 2005-12-22 12:04 UTC (permalink / raw) To: Greg KH Cc: Adrian Bunk, Linus Torvalds, Andrew Morton, Linux Kernel Mailing List, aabdulla, jgarzik, netdev, ak, discuss, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: 2.6.15-rc6: known regressions in the kernel Bugzilla 2005-12-22 12:04 ` Takashi Iwai @ 2005-12-29 13:23 ` Adrian Bunk 2005-12-30 19:31 ` Lee Revell 0 siblings, 1 reply; 66+ messages in thread From: Adrian Bunk @ 2005-12-29 13:23 UTC (permalink / raw) To: Takashi Iwai Cc: Greg KH, Linus Torvalds, Andrew Morton, Linux Kernel Mailing List, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: 2.6.15-rc6: known regressions in the kernel Bugzilla 2005-12-29 13:23 ` Adrian Bunk @ 2005-12-30 19:31 ` Lee Revell 0 siblings, 0 replies; 66+ messages in thread From: Lee Revell @ 2005-12-30 19:31 UTC (permalink / raw) To: Adrian Bunk Cc: Takashi Iwai, Greg KH, Linus Torvalds, Andrew Morton, Linux Kernel Mailing List, perex, alsa-devel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: 2.6.15-rc6: known regressions in the kernel Bugzilla 2005-12-22 1:13 ` 2.6.15-rc6: known regressions in the kernel Bugzilla Adrian Bunk 2005-12-22 7:15 ` Greg KH @ 2005-12-22 8:52 ` Andrew Morton 2005-12-22 13:57 ` Adrian Bunk 2005-12-22 15:16 ` David S. Miller 1 sibling, 2 replies; 66+ messages in thread From: Andrew Morton @ 2005-12-22 8:52 UTC (permalink / raw) To: Adrian Bunk Cc: torvalds, linux-kernel, aabdulla, jgarzik, netdev, ak, discuss, perex, alsa-devel, gregkh 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> ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: 2.6.15-rc6: known regressions in the kernel Bugzilla 2005-12-22 8:52 ` Andrew Morton @ 2005-12-22 13:57 ` Adrian Bunk 2005-12-22 14:08 ` Andrew Morton ` (3 more replies) 2005-12-22 15:16 ` David S. Miller 1 sibling, 4 replies; 66+ messages in thread From: Adrian Bunk @ 2005-12-22 13:57 UTC (permalink / raw) To: Andrew Morton Cc: torvalds, linux-kernel, Jens Axboe, Herbert Xu, Michael Madore, David Brownell, Greg KH, paulmck, Gottfried Haider, luca.risolia, P. Christeas 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: 2.6.15-rc6: known regressions in the kernel Bugzilla 2005-12-22 13:57 ` Adrian Bunk @ 2005-12-22 14:08 ` Andrew Morton 2005-12-22 23:12 ` Adrian Bunk 2005-12-23 15:28 ` Bill Davidsen 2005-12-22 17:11 ` Brice Goglin ` (2 subsequent siblings) 3 siblings, 2 replies; 66+ messages in thread From: Andrew Morton @ 2005-12-22 14:08 UTC (permalink / raw) To: Adrian Bunk Cc: torvalds, linux-kernel, axboe, herbert, michael.madore, david-b, gregkh, paulmck, gohai, luca.risolia, p_christ 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.. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: 2.6.15-rc6: known regressions in the kernel Bugzilla 2005-12-22 14:08 ` Andrew Morton @ 2005-12-22 23:12 ` Adrian Bunk 2005-12-23 15:28 ` Bill Davidsen 1 sibling, 0 replies; 66+ messages in thread From: Adrian Bunk @ 2005-12-22 23:12 UTC (permalink / raw) To: Andrew Morton Cc: torvalds, linux-kernel, axboe, herbert, michael.madore, david-b, gregkh, paulmck, gohai, luca.risolia, p_christ 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: 2.6.15-rc6: known regressions in the kernel Bugzilla 2005-12-22 14:08 ` Andrew Morton 2005-12-22 23:12 ` Adrian Bunk @ 2005-12-23 15:28 ` Bill Davidsen 2005-12-23 17:32 ` Michael Krufky 1 sibling, 1 reply; 66+ messages in thread From: Bill Davidsen @ 2005-12-23 15:28 UTC (permalink / raw) To: Andrew Morton Cc: torvalds, linux-kernel, axboe, herbert, michael.madore, david-b, gregkh, paulmck, gohai, luca.risolia, p_christ 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: 2.6.15-rc6: known regressions in the kernel Bugzilla 2005-12-23 15:28 ` Bill Davidsen @ 2005-12-23 17:32 ` Michael Krufky 2005-12-24 3:54 ` Andrew Morton 0 siblings, 1 reply; 66+ messages in thread From: Michael Krufky @ 2005-12-23 17:32 UTC (permalink / raw) To: Bill Davidsen Cc: Andrew Morton, torvalds, linux-kernel, axboe, herbert, michael.madore, david-b, gregkh, paulmck, gohai, luca.risolia, p_christ 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: 2.6.15-rc6: known regressions in the kernel Bugzilla 2005-12-23 17:32 ` Michael Krufky @ 2005-12-24 3:54 ` Andrew Morton 2005-12-25 20:25 ` Bill Davidsen ` (2 more replies) 0 siblings, 3 replies; 66+ messages in thread From: Andrew Morton @ 2005-12-24 3:54 UTC (permalink / raw) To: Michael Krufky Cc: davidsen, torvalds, linux-kernel, axboe, herbert, michael.madore, david-b, gregkh, paulmck, gohai, luca.risolia, p_christ 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: 2.6.15-rc6: known regressions in the kernel Bugzilla 2005-12-24 3:54 ` Andrew Morton @ 2005-12-25 20:25 ` Bill Davidsen 2005-12-26 1:59 ` Michael Krufky 2005-12-26 2:21 ` Lee Revell 2 siblings, 0 replies; 66+ messages in thread From: Bill Davidsen @ 2005-12-25 20:25 UTC (permalink / raw) To: Andrew Morton Cc: Michael Krufky, torvalds, linux-kernel, axboe, herbert, michael.madore, david-b, gregkh, paulmck, gohai, luca.risolia, p_christ 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: 2.6.15-rc6: known regressions in the kernel Bugzilla 2005-12-24 3:54 ` Andrew Morton 2005-12-25 20:25 ` Bill Davidsen @ 2005-12-26 1:59 ` Michael Krufky 2005-12-26 2:21 ` Lee Revell 2 siblings, 0 replies; 66+ messages in thread From: Michael Krufky @ 2005-12-26 1:59 UTC (permalink / raw) To: Andrew Morton Cc: davidsen, torvalds, linux-kernel, axboe, herbert, michael.madore, david-b, gregkh, paulmck, gohai, luca.risolia, p_christ 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: 2.6.15-rc6: known regressions in the kernel Bugzilla 2005-12-24 3:54 ` Andrew Morton 2005-12-25 20:25 ` Bill Davidsen 2005-12-26 1:59 ` Michael Krufky @ 2005-12-26 2:21 ` Lee Revell 2 siblings, 0 replies; 66+ messages in thread From: Lee Revell @ 2005-12-26 2:21 UTC (permalink / raw) To: Andrew Morton Cc: Michael Krufky, davidsen, torvalds, linux-kernel, axboe, herbert, michael.madore, david-b, gregkh, paulmck, gohai, luca.risolia, p_christ 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: 2.6.15-rc6: known regressions in the kernel Bugzilla 2005-12-22 13:57 ` Adrian Bunk 2005-12-22 14:08 ` Andrew Morton @ 2005-12-22 17:11 ` Brice Goglin [not found] ` <200512222152.05427.p_christ@hol.gr> 2005-12-23 11:50 ` Gottfried Haider 3 siblings, 0 replies; 66+ messages in thread From: Brice Goglin @ 2005-12-22 17:11 UTC (permalink / raw) To: Adrian Bunk Cc: Andrew Morton, torvalds, linux-kernel, Jens Axboe, Herbert Xu, Michael Madore, David Brownell, Greg KH, paulmck, Gottfried Haider, luca.risolia, P. Christeas 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
[parent not found: <200512222152.05427.p_christ@hol.gr>]
[parent not found: <1135291436.14685.7.camel@localhost>]
* Re: 2.6.15-rc6: known regressions in the kernel Bugzilla [not found] ` <1135291436.14685.7.camel@localhost> @ 2005-12-22 22:55 ` Mike Krufky [not found] ` <200512230121.48882.p_christ@hol.gr> 0 siblings, 1 reply; 66+ messages in thread From: Mike Krufky @ 2005-12-22 22:55 UTC (permalink / raw) To: Linux and Kernel Video Cc: P. Christeas, Adrian Bunk, Mauro Carvalho Chehab, linux-kernel 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) ^ permalink raw reply [flat|nested] 66+ messages in thread
[parent not found: <200512230121.48882.p_christ@hol.gr>]
* Re: 2.6.15-rc6: known regressions in the kernel Bugzilla [not found] ` <200512230121.48882.p_christ@hol.gr> @ 2005-12-23 1:07 ` Michael Krufky 0 siblings, 0 replies; 66+ messages in thread From: Michael Krufky @ 2005-12-23 1:07 UTC (permalink / raw) To: P. Christeas; +Cc: Mauro Chehab, Andrew Morton, Linux and Kernel Video, lkml 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: 2.6.15-rc6: known regressions in the kernel Bugzilla 2005-12-22 13:57 ` Adrian Bunk ` (2 preceding siblings ...) [not found] ` <200512222152.05427.p_christ@hol.gr> @ 2005-12-23 11:50 ` Gottfried Haider 2006-01-02 16:00 ` Adrian Bunk 3 siblings, 1 reply; 66+ messages in thread From: Gottfried Haider @ 2005-12-23 11:50 UTC (permalink / raw) To: Adrian Bunk, Andrew Morton Cc: torvalds, linux-kernel, Jens Axboe, Herbert Xu, Michael Madore, David Brownell, Greg KH, paulmck, luca.risolia, P. Christeas >> 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: 2.6.15-rc6: known regressions in the kernel Bugzilla 2005-12-23 11:50 ` Gottfried Haider @ 2006-01-02 16:00 ` Adrian Bunk 2006-01-04 16:38 ` Greg KH 0 siblings, 1 reply; 66+ messages in thread From: Adrian Bunk @ 2006-01-02 16:00 UTC (permalink / raw) To: Gottfried Haider; +Cc: linux-kernel, Greg KH 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: 2.6.15-rc6: known regressions in the kernel Bugzilla 2006-01-02 16:00 ` Adrian Bunk @ 2006-01-04 16:38 ` Greg KH 0 siblings, 0 replies; 66+ messages in thread From: Greg KH @ 2006-01-04 16:38 UTC (permalink / raw) To: Adrian Bunk; +Cc: Gottfried Haider, linux-kernel 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 ^ permalink raw reply [flat|nested] 66+ messages in thread
* Re: 2.6.15-rc6: known regressions in the kernel Bugzilla 2005-12-22 8:52 ` Andrew Morton 2005-12-22 13:57 ` Adrian Bunk @ 2005-12-22 15:16 ` David S. Miller 1 sibling, 0 replies; 66+ messages in thread From: David S. Miller @ 2005-12-22 15:16 UTC (permalink / raw) To: akpm Cc: bunk, torvalds, linux-kernel, aabdulla, jgarzik, netdev, ak, discuss, perex, alsa-devel, gregkh 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. ^ permalink raw reply [flat|nested] 66+ messages in thread
end of thread, other threads:[~2006-01-04 16:38 UTC | newest] Thread overview: 66+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-12-19 0:47 Linux 2.6.15-rc6 Linus Torvalds 2005-12-19 1:30 ` Diego Calleja 2005-12-19 5:41 ` Willy Tarreau 2005-12-20 13:18 ` 2.6.15-rc6: boot failure in saa7134-alsa.c Adrian Bunk 2005-12-20 15:52 ` [Alsa-devel] " Sergey Vlasov 2005-12-20 18:24 ` Linus Torvalds [not found] ` <20051220183455.GC19797@master.mivlgu.local> 2005-12-20 18:57 ` Linus Torvalds 2005-12-20 19:14 ` Adrian Bunk 2005-12-20 19:23 ` Mauro Carvalho Chehab 2005-12-20 19:59 ` Linus Torvalds 2005-12-20 20:23 ` Adrian Bunk 2005-12-20 20:41 ` Linus Torvalds 2005-12-20 20:47 ` James Courtier-Dutton 2005-12-20 21:06 ` Linus Torvalds 2005-12-20 21:13 ` [RFC: 2.6 patch] Makefile: sound/ must come before drivers/ Adrian Bunk 2005-12-20 21:24 ` [Alsa-devel] " Jaroslav Kysela 2005-12-20 22:09 ` Linus Torvalds 2005-12-21 14:21 ` Takashi Iwai 2005-12-21 20:49 ` Mauro Carvalho Chehab 2005-12-22 15:32 ` Takashi Iwai 2005-12-22 16:06 ` Mauro Carvalho Chehab 2005-12-22 16:17 ` Takashi Iwai 2005-12-22 16:38 ` Mauro Carvalho Chehab 2005-12-21 14:23 ` [Alsa-devel] 2.6.15-rc6: boot failure in saa7134-alsa.c Takashi Iwai 2005-12-21 18:22 ` Adrian Bunk 2005-12-21 18:38 ` Takashi Iwai 2005-12-21 22:40 ` Adrian Bunk 2005-12-22 11:39 ` Takashi Iwai 2005-12-20 20:35 ` James Courtier-Dutton 2005-12-20 21:03 ` Linus Torvalds 2005-12-20 22:17 ` Lee Revell 2005-12-21 1:29 ` Linus Torvalds 2005-12-21 13:29 ` Stephen Clark 2005-12-21 14:39 ` Takashi Iwai 2005-12-21 18:32 ` Linus Torvalds 2005-12-21 18:52 ` Takashi Iwai 2005-12-21 22:42 ` Adrian Bunk 2005-12-21 22:50 ` R C 2005-12-21 16:58 ` Steve deRosier 2005-12-21 18:32 ` Linus Torvalds 2005-12-21 18:41 ` Takashi Iwai 2005-12-20 20:35 ` Mauro Carvalho Chehab 2005-12-22 0:59 ` Adrian Bunk 2005-12-22 11:15 ` Mauro Carvalho Chehab 2005-12-22 1:13 ` 2.6.15-rc6: known regressions in the kernel Bugzilla Adrian Bunk 2005-12-22 7:15 ` Greg KH 2005-12-22 12:04 ` Takashi Iwai 2005-12-29 13:23 ` Adrian Bunk 2005-12-30 19:31 ` Lee Revell 2005-12-22 8:52 ` Andrew Morton 2005-12-22 13:57 ` Adrian Bunk 2005-12-22 14:08 ` Andrew Morton 2005-12-22 23:12 ` Adrian Bunk 2005-12-23 15:28 ` Bill Davidsen 2005-12-23 17:32 ` Michael Krufky 2005-12-24 3:54 ` Andrew Morton 2005-12-25 20:25 ` Bill Davidsen 2005-12-26 1:59 ` Michael Krufky 2005-12-26 2:21 ` Lee Revell 2005-12-22 17:11 ` Brice Goglin [not found] ` <200512222152.05427.p_christ@hol.gr> [not found] ` <1135291436.14685.7.camel@localhost> 2005-12-22 22:55 ` Mike Krufky [not found] ` <200512230121.48882.p_christ@hol.gr> 2005-12-23 1:07 ` Michael Krufky 2005-12-23 11:50 ` Gottfried Haider 2006-01-02 16:00 ` Adrian Bunk 2006-01-04 16:38 ` Greg KH 2005-12-22 15:16 ` David S. Miller
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).