ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc4/2.6.17-rc4-mm3/
- A few patchsets were dropped. They will come back. People who had memory
management initialisation problems will hopefully see improvements.
- swsusp resume on RH FC5 is still broken. It appears to be a userspace
bug.
Boilerplate:
- See the `hot-fixes' directory for any important updates to this patchset.
- To fetch an -mm tree using git, use (for example)
git fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git v2.6.16-rc2-mm1
- -mm kernel commit activity can be reviewed by subscribing to the
mm-commits mailing list.
echo "subscribe mm-commits" | mail [email protected]
- If you hit a bug in -mm and it is not obvious which patch caused it, it is
most valuable if you can perform a bisection search to identify which patch
introduced the bug. Instructions for this process are at
http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt
But beware that this process takes some time (around ten rebuilds and
reboots), so consider reporting the bug first and if we cannot immediately
identify the faulty patch, then perform the bisection search.
- When reporting bugs, please try to Cc: the relevant maintainer and mailing
list on any email.
Changes since 2.6.17-rc4-mm2:
origin.patch
git-acpi.patch
git-agpgart.patch
git-alsa.patch
git-audit-master.patch
git-block.patch
git-cfq.patch
git-cifs.patch
git-dvb.patch
git-gfs2.patch
git-ia64.patch
git-infiniband.patch
git-intelfb.patch
git-klibc.patch
git-hdrcleanup.patch
git-hdrinstall.patch
git-libata-all.patch
git-mips.patch
git-mtd.patch
git-netdev-all.patch
git-nfs.patch
git-ocfs2.patch
git-powerpc.patch
git-rbtree.patch
git-sas.patch
git-pcmcia.patch
git-scsi-rc-fixes.patch
git-scsi-target.patch
git-supertrak.patch
git-watchdog.patch
git-cryptodev.patch
git-viro-bird-m32r.patch
git-viro-bird-m68k.patch
git-viro-bird-frv.patch
git-viro-bird-upf.patch
git-viro-bird-volatile.patch
git trees
-nfs-fix-error-handling-on-access_ok-in-compat_sys_nfsservctl.patch
-matroxfb-fix-dvi-setup-to-be-more-compatible.patch
-i386-remove-junk-from-stack-dump.patch
-powerpc-fix-ide-pmac-sysfs-entry.patch
-kdump-maintainer-info-update.patch
-nfs-server-subtree_check-returns-dubious-value.patch
-md-fix-inverted-test-for-repair-directive.patch
-nfsd-sign-conversion-obscuring-errors-in-nfsd_set_posix_acl.patch
-x86_64-dont-warn-for-overflow-in-nommu-case-when-dma_mask-is-32bit-fix.patch
-hid-read-busywait-fix.patch
-binfmt_flat-dont-check-for-emfile.patch
-selinux-endian-fix.patch
-x86_64-mm-hotadd-reserve-fix-fix-fix.patch
-sparsemem-incorrectly-calculates-section-number.patch
-fix-race-in-inotify_release.patch
-pci-correctly-allocate-return-buffers-for-osc-calls.patch
-cpuset-might-sleep-checking-zones-allowed-fix.patch
-cpuset-update-cpuset_zones_allowed-comment.patch
-cpuset-might_sleep_if-check-in-cpuset_zones_allowed.patch
-overrun-in-isdn_ttyc.patch
-clarify-maintainers-and-include-linux-security-info.patch
-update-ext2-ext3-jbd-maintainers-entries.patch
-minor-spi-doc-fix.patch
-spi-added-spi-master-driver-for.patch
-drivers-base-firmware_classc-cleanups.patch
-s3c24xx-gpio-based-spi-driver.patch
-s3c24xx-hardware-spi-driver.patch
-s3c24xx-hardware-spi-driver-tidy.patch
-pxa2xx-spi-update.patch
-i386-kdump-boot-cpu-physical-apicid-fix.patch
-kprobes-bad-manupilation-of-2-byte-opcode-on-x86_64.patch
-missing-newline-in-scsi-stc.patch
-fix-a-no_idle_hz-timer-bug.patch
-revert-forcedeth-fix-multi-irq-issues.patch
-s390-next_timer_interrupt-overflow-in-stop_hz_timer.patch
-kbuild-check-sht_rel-sections.patch
-kbuild-fix-modpost-segfault-for-64bit-mipsel-kernel.patch
-rtc-subsystem-use-enoioctlcmd-and-enotty-where-appropriate.patch
-via-rhine-revert-change-mdelay-to-msleep-and-remove-from-isr-path.patch
-fix-broken-vm86-interrupt-signal-handling.patch
-kobject-quiet-errors-in-kobject_add.patch
-align-the-node_mem_map-endpoints-to-a-max_order-boundary.patch
-pd6729-section-fix.patch
-i810-section-fix.patch
-mpu401-section-fix.patch
-es18xx-build-fix.patch
-nm256_audio-section-fix.patch
-ad1848-section-fix.patch
-gregkh-driver-platform_bus-learns-about-modalias-warning-fix.patch
-gregkh-driver-warn-when-statically-allocated-kobjects-are-used-fix.patch
-w1-warning-fix.patch
-git-mtd-symbol_get-fix.patch
-git-mtd-moddi-fix.patch
-ppa-no-highmem-pages.patch
-scsi-make-scsi_implement_eh-generic-api-for-scsi-transports.patch
-added-support-for-asix-88178-chipset-usb-gigabit-ethernet-adaptor.patch
Merged into mainline or a subsystem tree
+sys_sync_file_range-move-exported-flags-outside-kernel.patch
+knfsd-fix-two-problems-that-can-cause-rmmod-nfsd-to-die.patch
+md-fix-possible-oops-when-starting-a-raid0-array.patch
+md-make-sure-bi_max_vecs-is-set-properly-in-bio_split.patch
2.6.17 queue
+gregkh-driver-remove-duplication-from-documentation-power-devicestxt.patch
+gregkh-driver-driver-core-pm_debug-device-suspend-messages-become-informative.patch
Driver tree updates
+gregkh-i2c-w1-warning-fix.patch
i2c tree update
+input-powermac-cleanup-of-mac_hid-and-support-for-ctrlclick-and-commandclick.patch
powermac input driver cleanup and feature work
+forcedeth-suggested-cleanups.patch
+forcedeth-add-support-for-flow-control.patch
+forcedeth-add-support-for-configuration.patch
Bring back these forcedeth patches
+secmark-add-new-packet-controls-to-selinux-disable-new-controls-for-selinux-by-default.patch
Make the secmark Kconfiguration more user-friendly.
+git-nfs-fixup.patch
Fix reject in git-nfs.patch.
+git-scsi-target-warning-fix.patch
Fix wanring in git-scsi-target.patch
+gregkh-usb-usb-added-support-for-asix-88178-chipset-usb-gigabit-ethernet-adaptor.patch
+gregkh-usb-usb-correct-the-usb-info-in-documentation-power-swsusptxt.patch
+gregkh-usb-usb-remove-4088-byte-limit-on-usbfs-control-urbs.patch
+gregkh-usb-usb-allow-high-bandwidth-isochronous-packets-via-usbfs.patch
+gregkh-usb-uhci-use-integer-sized-frame-numbers.patch
+gregkh-usb-uhci-fix-race-in-iso-dequeuing.patch
+gregkh-usb-uhci-store-the-period-in-the-queue-header.patch
+gregkh-usb-uhci-remove-iso-tds-as-they-are-used.patch
+gregkh-usb-fix-a-deadlock-in-usbtest.patch
+gregkh-usb-usb_interrupt_msg.patch
USB tree updates
+revert-gregkh-usb-usb-ohci-avoids-root-hub-timer-polling.patch
Revert a USB patch which caused swsusp resume hangs
+git-supertrak-fixup.patch
Fix reject in git-supertrak.patch
+orinoco-possible-null-pointer-dereference-in-orinoco_rx_monitor.patch
wireless driver fix
+x86_64-mm-i386-numa-summit-check-fix.patch
+x86_64-dont-warn-for-overflow-in-nommu-case-when-dma_mask-is-32bit-fix.patch
x86_64 things
-introduce-mechanism-for-registering-active-regions-of-memory.patch
-have-power-use-add_active_range-and-free_area_init_nodes.patch
-have-x86-use-add_active_range-and-free_area_init_nodes.patch
-have-x86_64-use-add_active_range-and-free_area_init_nodes.patch
-have-ia64-use-add_active_range-and-free_area_init_nodes.patch
Hopefully the source of recent memory-management initialisation problems.
+fix-broken-vm86-interrupt-signal-handling.patch
x86 fix
+x86-move-vsyscall-page-out-of-fixmap-above-stack.patch
+x86-move-vsyscall-page-out-of-fixmap-above-stack-tidy.patch
Move the x86 vsyscall page elsewhere (Xen preparation)
+rewritten-backlight-infrastructure-for-portable-apple-computers-fix.patch
Fix rewritten-backlight-infrastructure-for-portable-apple-computers.patch
+pdflush-handle-resume-wakeups.patch
Fix pdflush interaction with swsusp resume
+genirq-rename-desc-handler-to-desc-chip.patch
+genirq-rename-desc-handler-to-desc-chip-power-fix.patch
+genirq-rename-desc-handler-to-desc-chip-ia64-fix.patch
Rename irq_desc.handler to irq_desc.chip (big stupid patch which is
preparation for the genirq patches, which had merge problems).
+edd-isnt-experimental-anymore.patch
EDD is ready for prime time.
+kernel-doc-drop-leading-space-in-sections.patch
+kernel-doc-script-cleanups.patch
kernel-doc work.
+schedule_on_each_cpu-reduce-kmalloc-size.patch
schedule_on_cpu() was kmallocing stupidly large amounts of memory.
-vectorize-aio_read-aio_write-methods.patch
-remove-readv-writev-methods-and-use-aio_read-aio_write.patch
-core-aio-changes-to-support-vectored-aio.patch
-core-aio-changes-to-support-vectored-aio-fix-2.patch
-streamline-generic_file_-interfaces-and-filemap.patch
-gfs2-vs-streamline-generic_file_-interfaces-and-filemap.patch
These broke autofs4
-nfs-open-code-the-nfs-direct-write-rescheduler.patch
-nfs-open-code-the-nfs-direct-write-rescheduler-printk-fix.patch
-nfs-remove-user_addr-and-user_count-from-nfs_direct_req.patch
-nfs-eliminate-nfs_get_user_pages.patch
-nfs-alloc-nfs_read-write_data-as-direct-i-o-is-scheduled.patch
-nfs-check-all-iov-segments-for-correct-memory-access-rights.patch
-nfs-support-vector-i-o-throughout-the-nfs-direct-i-o-path.patch
-ecryptfs-vs-streamline-generic_file_-interfaces-and-filemap.patch
-ecryptfs-vs-streamline-generic_file_-interfaces-and-filemap-fix.patch
These depended on the preceding patches. Temporarily dropped.
+namespaces-add-nsproxy-dont-include-compileh.patch
Fix namespaces-add-nsproxy.patch
+namespaces-utsname-implement-utsname-namespaces-dont-include-compileh.patch
Fix namespaces-utsname-implement-utsname-namespaces.patch
+intelfb-use-firmware-edid-for-mode-database-fix.patch
Fix intelfb-use-firmware-edid-for-mode-database.patch
+add-print_fatal_signals-support.patch
Add `print-fatal-signals=1' boot option - causes the kernel to emit debug
info when a task is killed in strange circumstances.
All 1085 patches:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc4/2.6.17-rc4-mm3/patch-list
On Mon, 22 May 2006 02:27:09 PDT, Andrew Morton said:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc4/2.6.17-rc4-mm3/
Mostly works, am chasing down 3 small things (all 3 were new as of -mm2 - I was
busy chasing them when -mm3 showed up).
1) Something has gone astray in the hardware RNG rework. /sbin/rngd was
quite happy dealing with the i810 RNG in my laptop under -rc4-mm1, but under
-mm2 and -mm3, I get this (from strace /bin/rngd):
open("/dev/hw_random", O_RDONLY) = 3
read(3, "q\252cg", 4) = 4
read(3, 0xbfaf56ac, 4) = -1 EAGAIN (Resource temporarily unavai lable)
It works for some number of reads, but eventually pulls an EAGAIN. When
stracing on a console that was slow-to-scroll, it did several dozen before
failing - so it's apparently a timing thing. I stuck a debugging printk
in just before the test that returns EAGAIN, and got this:
[ 68.361000] rng_read data_present=1 i=0 bytes_read=1
[ 68.361000] rng_read data_present=1 i=0 bytes_read=1
[ 68.361000] rng_read data_present=1 i=0 bytes_read=1
[ 68.361000] rng_read data_present=1 i=0 bytes_read=1
[ 68.361000] rng_read data_present=0 i=20 bytes_read=0
It looks to me line the old code stayed in a while() loop in rng_dev_read
until it had fulfilled the read request (including possibly multiple
calls to need_resched() and friends). The new code will bail on an -EAGAIN
as soon as the *first* poll fails, rather than waiting until something
is available - even if it is NOT flagged O_NONBLOCK.
2) Building modules, stage 2.
MODPOST
WARNING: drivers/acpi/processor.o - Section mismatch: reference to .init.data: from .text between 'acpi_processor_power_init' (at offset 0xf5e) and 'acpi_safe_halt'
3) Something in git-cryptodev.patch doesn't play nice with RedHat Fedora's
'modsign' patches. I'm suspecting this is the cause:
commit f1c737f209e39095016e5be3904b2ce84027890f
Author: Herbert Xu <[email protected]>
Date: Tue May 16 22:09:29 2006 +1000
[CRYPTO] all: Pass tfm instead of ctx to algorithms
I just haven't stared at it enough to make the fixes needed.
On Monday 22 May 2006 13:15, you wrote:
> On Mon, 22 May 2006 02:27:09 PDT, Andrew Morton said:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc4/2.6.17-rc4-mm3/
>
> Mostly works, am chasing down 3 small things (all 3 were new as of -mm2 - I was
> busy chasing them when -mm3 showed up).
>
> 1) Something has gone astray in the hardware RNG rework. /sbin/rngd was
> quite happy dealing with the i810 RNG in my laptop under -rc4-mm1, but under
> -mm2 and -mm3, I get this (from strace /bin/rngd):
>
> open("/dev/hw_random", O_RDONLY) = 3
> read(3, "q\252cg", 4) = 4
> read(3, 0xbfaf56ac, 4) = -1 EAGAIN (Resource temporarily unavai lable)
>
> It works for some number of reads, but eventually pulls an EAGAIN. When
> stracing on a console that was slow-to-scroll, it did several dozen before
> failing - so it's apparently a timing thing. I stuck a debugging printk
> in just before the test that returns EAGAIN, and got this:
>
> [ 68.361000] rng_read data_present=1 i=0 bytes_read=1
> [ 68.361000] rng_read data_present=1 i=0 bytes_read=1
> [ 68.361000] rng_read data_present=1 i=0 bytes_read=1
> [ 68.361000] rng_read data_present=1 i=0 bytes_read=1
> [ 68.361000] rng_read data_present=0 i=20 bytes_read=0
>
> It looks to me line the old code stayed in a while() loop in rng_dev_read
> until it had fulfilled the read request (including possibly multiple
> calls to need_resched() and friends). The new code will bail on an -EAGAIN
> as soon as the *first* poll fails, rather than waiting until something
> is available - even if it is NOT flagged O_NONBLOCK.
Yeah. That is how it works. I am wondering why userspace doesn't
simply retry, if it receives an EAGAIN.
Should we return ERESTARTSYS or something like that instead?
Michael Buesch <[email protected]> wrote:
>
> On Monday 22 May 2006 13:15, you wrote:
> > On Mon, 22 May 2006 02:27:09 PDT, Andrew Morton said:
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc4/2.6.17-rc4-mm3/
> >
> > Mostly works, am chasing down 3 small things (all 3 were new as of -mm2 - I was
> > busy chasing them when -mm3 showed up).
> >
> > 1) Something has gone astray in the hardware RNG rework. /sbin/rngd was
> > quite happy dealing with the i810 RNG in my laptop under -rc4-mm1, but under
> > -mm2 and -mm3, I get this (from strace /bin/rngd):
> >
> > open("/dev/hw_random", O_RDONLY) = 3
> > read(3, "q\252cg", 4) = 4
> > read(3, 0xbfaf56ac, 4) = -1 EAGAIN (Resource temporarily unavai lable)
> >
> > It works for some number of reads, but eventually pulls an EAGAIN. When
> > stracing on a console that was slow-to-scroll, it did several dozen before
> > failing - so it's apparently a timing thing. I stuck a debugging printk
> > in just before the test that returns EAGAIN, and got this:
> >
> > [ 68.361000] rng_read data_present=1 i=0 bytes_read=1
> > [ 68.361000] rng_read data_present=1 i=0 bytes_read=1
> > [ 68.361000] rng_read data_present=1 i=0 bytes_read=1
> > [ 68.361000] rng_read data_present=1 i=0 bytes_read=1
> > [ 68.361000] rng_read data_present=0 i=20 bytes_read=0
> >
> > It looks to me line the old code stayed in a while() loop in rng_dev_read
> > until it had fulfilled the read request (including possibly multiple
> > calls to need_resched() and friends). The new code will bail on an -EAGAIN
> > as soon as the *first* poll fails, rather than waiting until something
> > is available - even if it is NOT flagged O_NONBLOCK.
>
> Yeah. That is how it works. I am wondering why userspace doesn't
> simply retry, if it receives an EAGAIN.
> Should we return ERESTARTSYS or something like that instead?
Heaven alone knows what that would do.
Let's just retain the present behaviour, please. Don't break stuff. Or,
if we really do need to break stuff, we do it with lengthy lead times and
with elaborate process (such as, for example, creating /dev/hw_random-2 and
waiting for userspace to migrate to that, then deprecating /dev/hw_random).
On Mon, 22 May 2006 13:25:10 +0200, Michael Buesch said:
> On Monday 22 May 2006 13:15, you wrote:
> > It looks to me line the old code stayed in a while() loop in rng_dev_read
> > until it had fulfilled the read request (including possibly multiple
> > calls to need_resched() and friends). The new code will bail on an -EAGAIN
> > as soon as the *first* poll fails, rather than waiting until something
> > is available - even if it is NOT flagged O_NONBLOCK.
>
> Yeah. That is how it works. I am wondering why userspace doesn't
> simply retry, if it receives an EAGAIN.
> Should we return ERESTARTSYS or something like that instead?
That's not the way it worked in previous kernels, and it's not the way that
the current rng-utils RPM in Fedora expects it to work.
Here's a patch that makes it work the way it used to. Adding the test
for O_NONBLOCK is the biggie - the old code did a resched test at that
point in the loop, so I added it here too.
--- linux-2.6.17-rc4-mm3/drivers/char/hw_random/core.c.rnd_fix 2006-05-22 07:23:34.000000000 -0400
+++ linux-2.6.17-rc4-mm3/drivers/char/hw_random/core.c 2006-05-22 07:22:29.000000000 -0400
@@ -125,7 +125,7 @@ static ssize_t rng_dev_read(struct file
mutex_unlock(&rng_mutex);
err = -EAGAIN;
- if (!bytes_read)
+ if (filp->f_flags & O_NONBLOCK && !bytes_read)
goto out;
err = -EFAULT;
@@ -138,6 +138,9 @@ static ssize_t rng_dev_read(struct file
data >>= 8;
}
+ if (need_resched())
+ schedule_timeout_interruptible(1);
+
if (signal_pending(current))
goto out;
}
On Monday 22 May 2006 13:38, you wrote:
> On Mon, 22 May 2006 13:25:10 +0200, Michael Buesch said:
> > On Monday 22 May 2006 13:15, you wrote:
>
> > > It looks to me line the old code stayed in a while() loop in rng_dev_read
> > > until it had fulfilled the read request (including possibly multiple
> > > calls to need_resched() and friends). The new code will bail on an -EAGAIN
> > > as soon as the *first* poll fails, rather than waiting until something
> > > is available - even if it is NOT flagged O_NONBLOCK.
> >
> > Yeah. That is how it works. I am wondering why userspace doesn't
> > simply retry, if it receives an EAGAIN.
> > Should we return ERESTARTSYS or something like that instead?
>
> That's not the way it worked in previous kernels, and it's not the way that
> the current rng-utils RPM in Fedora expects it to work.
>
> Here's a patch that makes it work the way it used to. Adding the test
> for O_NONBLOCK is the biggie - the old code did a resched test at that
> point in the loop, so I added it here too.
>
> --- linux-2.6.17-rc4-mm3/drivers/char/hw_random/core.c.rnd_fix 2006-05-22 07:23:34.000000000 -0400
> +++ linux-2.6.17-rc4-mm3/drivers/char/hw_random/core.c 2006-05-22 07:22:29.000000000 -0400
> @@ -125,7 +125,7 @@ static ssize_t rng_dev_read(struct file
> mutex_unlock(&rng_mutex);
>
> err = -EAGAIN;
> - if (!bytes_read)
> + if (filp->f_flags & O_NONBLOCK && !bytes_read)
> goto out;
>
> err = -EFAULT;
> @@ -138,6 +138,9 @@ static ssize_t rng_dev_read(struct file
> data >>= 8;
> }
>
> + if (need_resched())
> + schedule_timeout_interruptible(1);
> +
Andrew's comment on this:
What's going on with the need_resched() tricks in there? (Unobvious, needs
a comment). From my reading, it'll cause a caller to this function to hang
for arbitrary periods of time if something if causing heavy scheduling
pressure.
So I decided to remove it and return -EAGAIN, so userspace can retry.
But seems like it it does not. I thought glibc would handle that.
On Mon, 22 May 2006 13:49:28 +0200, Michael Buesch said:
> Andrew's comment on this:
>
> What's going on with the need_resched() tricks in there? (Unobvious, needs
> a comment). From my reading, it'll cause a caller to this function to hang
> for arbitrary periods of time if something if causing heavy scheduling
> pressure.
>
> So I decided to remove it and return -EAGAIN, so userspace can retry.
> But seems like it it does not. I thought glibc would handle that.
On the other hand, the *old* code did the same 'need_resched()' test - although
it was slightly different:
if(need_resched())
schedule_timeout_interruptible(1);
else
udelay(200); /* FIXME: We could poll for 250uS ?? */
I tossed the else because we have the poll loop elsewhere (the only delay in
the old code was that udelay).
And it's probably no *great* sin if it blocks for a long time - remember that
we're waiting for more entropy to show up. And if we don't resched, we basically
end up spinning until we get all the entropy we want.
Note that the current userspace will go and snarf up 2500 (yes, 2500) bytes
of data, and then spend the next half hour or so feeding it into /dev/random
in small chunks once a minute. At least on my laptop, strace reports the
read as taking 0.46 seconds. I'm pretty sure we want to resched once in
a while, rather than lock up a CPU for half a second. :)
On Mon, 22 May 2006 02:27:09 -0700
Andrew Morton <[email protected]> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc4/2.6.17-rc4-mm3/
>
> - A few patchsets were dropped. They will come back. People who had memory
> management initialisation problems will hopefully see improvements.
>
> - swsusp resume on RH FC5 is still broken. It appears to be a userspace
> bug.
>
compile error found.
==
CC arch/ia64/kernel/machine_kexec.o
arch/ia64/kernel/machine_kexec.c: In function `machine_shutdown':
arch/ia64/kernel/machine_kexec.c:74: error: structure has no member named `handler'
arch/ia64/kernel/machine_kexec.c:75: error: structure has no member named `handler'
make[1]: *** [arch/ia64/kernel/machine_kexec.o] Error 1
==
maybe kexec need to catch the changes in IRQ. .config is attached.
-Kame
Hi,
On 22/05/06, Andrew Morton <[email protected]> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc4/2.6.17-rc4-mm3/
>
[snip]
> git-alsa.patch
I have noticed small problem with ALSA.
When I boot 2.6.17-rc4-mm3 everything is ok, then I switch to
2.6.17-rc4-git11 - everything is ok. But when I switch back to
2.6.17-rc4-mm3 PCM is mute (off), Spread Front to Surround and
Center/LFE is off, Channel Mode is set to 2ch (should be 6ch).
/sbin/alsactl -v
alsactl version 1.0.11rc2
This is an user space tools bug?
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
On Tue, 2006-05-23 at 23:07 +0200, Michal Piotrowski wrote:
> Hi,
>
> On 22/05/06, Andrew Morton <[email protected]> wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc4/2.6.17-rc4-mm3/
> >
> [snip]
> > git-alsa.patch
>
> I have noticed small problem with ALSA.
> When I boot 2.6.17-rc4-mm3 everything is ok, then I switch to
> 2.6.17-rc4-git11 - everything is ok. But when I switch back to
> 2.6.17-rc4-mm3 PCM is mute (off), Spread Front to Surround and
> Center/LFE is off, Channel Mode is set to 2ch (should be 6ch).
>
> /sbin/alsactl -v
> alsactl version 1.0.11rc2
>
> This is an user space tools bug?
If the mixer controls changed between those versions, then alsactl will
be unable to completely restore the mixer state.
Otherwise the problem is with your userspace tools. I think KDE likes
to save/restore mixer settings on its own and its ALSA support is
horribly buggy.
It would help if you determine what app is saving/restoring the mixer
settings.
Lee
Hi Lee,
On 23/05/06, Lee Revell <[email protected]> wrote:
> On Tue, 2006-05-23 at 23:07 +0200, Michal Piotrowski wrote:
> > Hi,
> >
> > On 22/05/06, Andrew Morton <[email protected]> wrote:
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.17-rc4/2.6.17-rc4-mm3/
> > >
> > [snip]
> > > git-alsa.patch
> >
> > I have noticed small problem with ALSA.
> > When I boot 2.6.17-rc4-mm3 everything is ok, then I switch to
> > 2.6.17-rc4-git11 - everything is ok. But when I switch back to
> > 2.6.17-rc4-mm3 PCM is mute (off), Spread Front to Surround and
> > Center/LFE is off, Channel Mode is set to 2ch (should be 6ch).
> >
> > /sbin/alsactl -v
> > alsactl version 1.0.11rc2
> >
> > This is an user space tools bug?
>
> If the mixer controls changed between those versions, then alsactl will
> be unable to completely restore the mixer state.
>
> Otherwise the problem is with your userspace tools. I think KDE likes
> to save/restore mixer settings on its own and its ALSA support is
> horribly buggy.
>
> It would help if you determine what app is saving/restoring the mixer
> settings.
This is from my /etc/init.d/halt (FC5)
if [ $? = 0 -a -x /usr/sbin/alsactl ]; then
runcmd $"Saving mixer settings" alsactl store
fi
but this is KDE problem :).
> Lee
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)