Hi all,
On New Years eve my CPU (Athlon 1200 ams3b) died. I managed to get a
replacement off e-bay. During my diagnosis of what happened, I reset BIOS,
so obviously when I got the replacement I had to set it all up again.
Info: 2.6.15, on base Slack 10 (updated a lot from source).
PCI:
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev
22)
00:07.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT823x/A/C/VT8235 PIPC Bus Master IDE (rev 10)
00:07.2 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller]
(rev 10)
00:07.3 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller]
(rev 10)
00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev
30)
00:09.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev
78)
00:0f.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07)
00:0f.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev
07)
01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 MX 440]
(rev a3)
If I turn OFF PNP OS, when I boot, 'alsactl restore' (run from rc.local)
squinnies:
Set_Control:894 Name mismatch ... Control #47
896: Index mismatch (0/0) for Control #47
1008: Bad control.47.value
Then I messed with alsamixer/aslactl store~restore etc. and all appeared OK in
console - but sound is all messed as if no restore was done. And I get the
same error on boot again.
Turn ON PNP OS in BIOS, and all works again, alsactl restore works fine.
Now, after the issue I had with my CPU dying, I hate keep rebooting to test
this, but the tests I done appear as above.
So, is this something else? Or do I need to set PNP OS in BIOS for ALSA?
Nick
--
"Person who say it cannot be done should not interrupt person doing it."
-Chinese Proverb
Nick Warne wrote:
> 00:0f.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1
>
> If I turn OFF PNP OS, when I boot, 'alsactl restore' (run from
> rc.local) squinnies:
>
> Set_Control:894 Name mismatch ... Control #47
> 896: Index mismatch (0/0) for Control #47
> 1008: Bad control.47.value
This usually happens when you use a different driver version that has
different mixer controls so that the saved state in /etc/asound.state
doesn't match.
I don't know why the "PNP OS" setting should affect which mixer
controls are available. What are the differences in /etc/asound.state
after "alsactl store" in both cases?
Clemens
At Tue, 10 Jan 2006 10:01:33 +0100,
Clemens Ladisch wrote:
>
> Nick Warne wrote:
> > 00:0f.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1
> >
> > If I turn OFF PNP OS, when I boot, 'alsactl restore' (run from
> > rc.local) squinnies:
> >
> > Set_Control:894 Name mismatch ... Control #47
> > 896: Index mismatch (0/0) for Control #47
> > 1008: Bad control.47.value
>
> This usually happens when you use a different driver version that has
> different mixer controls so that the saved state in /etc/asound.state
> doesn't match.
Use -F option for alsactl in your init script.
Takashi
On Tuesday 10 January 2006 11:27, Takashi Iwai wrote:
> > > Set_Control:894 Name mismatch ... Control #47
> > > 896: Index mismatch (0/0) for Control #47
> > > 1008: Bad control.47.value
> >
> > This usually happens when you use a different driver version that has
> > different mixer controls so that the saved state in /etc/asound.state
> > doesn't match.
>
> Use -F option for alsactl in your init script.
I see - specify the asound.state file to use.
So bios pnp OS ON/OFF both use different alsa drivers (or parts _of_ the
driver) then - which in turn require different asound.state files?
Nick
--
"Person who say it cannot be done should not interrupt person doing it."
-Chinese Proverb
At Tue, 10 Jan 2006 17:59:20 +0000,
Nick Warne wrote:
>
> On Tuesday 10 January 2006 11:27, Takashi Iwai wrote:
>
> > > > Set_Control:894 Name mismatch ... Control #47
> > > > 896: Index mismatch (0/0) for Control #47
> > > > 1008: Bad control.47.value
> > >
> > > This usually happens when you use a different driver version that has
> > > different mixer controls so that the saved state in /etc/asound.state
> > > doesn't match.
> >
> > Use -F option for alsactl in your init script.
>
> I see - specify the asound.state file to use.
>
> So bios pnp OS ON/OFF both use different alsa drivers (or parts _of_ the
> driver) then - which in turn require different asound.state files?
No, I meant -F (a capical F), which means to force to set up the
controls even the number id mismatches. This avoid the errors like
above. (The default behavior of alsactl is a bit too strict.)
But, anyway, it's better to do the following:
- Boot with PnP ON, run "alsactl -f state-with-pnp store"
- Boot with PnP OFF, run "alsactl -f state-wo-pnp store"
then compare these two files.
Takashi
On Tuesday 10 January 2006 18:12, Takashi Iwai wrote:
> > So bios pnp OS ON/OFF both use different alsa drivers (or parts _of_ the
> > driver) then - which in turn require different asound.state files?
>
> No, I meant -F (a capical F), which means to force to set up the
> controls even the number id mismatches. This avoid the errors like
> above. (The default behavior of alsactl is a bit too strict.)
>
> But, anyway, it's better to do the following:
>
> - Boot with PnP ON, run "alsactl -f state-with-pnp store"
> - Boot with PnP OFF, run "alsactl -f state-wo-pnp store"
>
> then compare these two files.
OK, sorry for a delay in reply - I haven't rebooted since last mail.
I have something _really_ peculiar ongoing on here (ignoring PnP - this isn't
my issue now, I feel).
Info (lspci):
00:0f.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07)
00:0f.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev
07)
This morning I built and installed 2.6.15.4. On reboot, I got control errors
again ('alsactl restore' is run from rc.local):
Sorting SB Live! sound (alsactl restore)...
alsactl: set_control:894: warning: name mismatch (Sigmatel Surround Playback
Volume/Sigmatel Surround Playback Switch) for control #47
alsactl: set_control:896: warning: index mismatch (0/0) for control #47
alsactl: set_control:1008: bad control.47.value index
Ummm. At the command line, same errors also. So I deleted /etc/asound.state
and reconfigured alsamixer from scratch. Then following 'alsactl store',
'alsactl restore' completes without issue (i.e. works clean).
If I then reboot, the same damn control #47 errors happen again. It's as if
something changes my asound.state file at boot time time?
Ideas? This is driving me potty.
Nick
--
"Person who say it cannot be done should not interrupt person doing it."
-Chinese Proverb
> Ummm. At the command line, same errors also. So I deleted /etc/asound.state
> and reconfigured alsamixer from scratch. Then following 'alsactl store',
> 'alsactl restore' completes without issue (i.e. works clean).
>
> If I then reboot, the same damn control #47 errors happen again. It's as if
> something changes my asound.state file at boot time time?
>
> Ideas? This is driving me potty.
>
OK, talking to myself (testing, testing, 1-2-3) - I have resolved this
issue after spending 2 hours trying to get my Mic to work again in
Teamspeak (why is there _so_ many frigging mixers
(alsamixer/amixer/aumix/kmix/arts) that all seem to do different
things...
I updated alsa-lib and alsa-utils to1.0.11rc3/rc2 This fixed my issues.
Now the question - there have been a lot of alsa changes (since my
alsa-tools was built Slack 10) - do we need to keep the alsa tools and
stuff current too?
Nick
On Sat, 2006-02-11 at 10:54 +0000, Nick Warne wrote:
> Sorting SB Live! sound (alsactl restore)...
> alsactl: set_control:894: warning: name mismatch (Sigmatel Surround
> Playback
> Volume/Sigmatel Surround Playback Switch) for control #47
> alsactl: set_control:896: warning: index mismatch (0/0) for control
> #47
> alsactl: set_control:1008: bad control.47.value index
>
>
Harmless
> Ummm. At the command line, same errors also. So I
> deleted /etc/asound.state
> and reconfigured alsamixer from scratch. Then following 'alsactl
> store',
> 'alsactl restore' completes without issue (i.e. works clean).
>
> If I then reboot, the same damn control #47 errors happen again. It's
> as if
> something changes my asound.state file at boot time time?
>
Probably you have two different alsactl's installed, one that's
hardcoded to save the state in /etc/asound.state, and a distro version
that wants to save it in /var/lib/whatever. It sounds like one is being
run at boot and a different one at shutdown.
On Sat, 2006-02-11 at 13:56 +0000, Nick wrote:
> > Ummm. At the command line, same errors also. So I deleted /etc/asound.state
> > and reconfigured alsamixer from scratch. Then following 'alsactl store',
> > 'alsactl restore' completes without issue (i.e. works clean).
> >
> > If I then reboot, the same damn control #47 errors happen again. It's as if
> > something changes my asound.state file at boot time time?
> >
> > Ideas? This is driving me potty.
> >
>
> OK, talking to myself (testing, testing, 1-2-3) - I have resolved this
> issue after spending 2 hours trying to get my Mic to work again in
> Teamspeak (why is there _so_ many frigging mixers
> (alsamixer/amixer/aumix/kmix/arts) that all seem to do different
> things...
Because people keep writing half-assed mixers, rather than fixing the
existing ones, and distros inexplicably include 5 of them. Half the
mixers out there only speak OSS, and distros ship them anyway.
Lee
On Sat, 2006-02-11 at 13:56 +0000, Nick wrote:
> Now the question - there have been a lot of alsa changes (since my
> alsa-tools was built Slack 10) - do we need to keep the alsa tools and
> stuff current too?
Yes - kernel upgrades should depend on alsa-lib upgrades (many distros
seem to get this wrong). This should be fixed in the future, but it's
been this way for some time.
Lee
On Saturday 11 February 2006 19:44, Lee Revell wrote:
> > If I then reboot, the same damn control #47 errors happen again. It's
> > as if
> > something changes my asound.state file at boot time time?
>
> Probably you have two different alsactl's installed, one that's
> hardcoded to save the state in /etc/asound.state, and a distro version
> that wants to save it in /var/lib/whatever. It sounds like one is being
> run at boot and a different one at shutdown.
First thing I thought of - Slackware is a 'clean, straight' distro though, and
the only asound.state file I had was in /etc/ and only one alsactl in
default /usr/sbin
On Saturday 11 February 2006 22:07, Lee Revell wrote:
> > do we need to keep the alsa tools and
> > stuff current too?
>
> Yes - kernel upgrades should depend on alsa-lib upgrades (many distros
> seem to get this wrong). This should be fixed in the future, but it's
> been this way for some time.
Well, it appears to have fixed the issues I had. Several reboots since and no
problems now.
Looking back, originally I had a 2.4.x kernel - I have since upgraded to 2.6.x
series, plus built a lot of new tools and such from source - all except alsa
stuff, of course - so it does make sense and I kick myself for not thinking
about this in the beginning. One to remember.
Thanks,
Nick
--
"Person who say it cannot be done should not interrupt person doing it."
-Chinese Proverb