From: Bauke Jan Douma <[email protected]>
On ASUS A8V and A8V Deluxe boards, the onboard AC97 audio controller
and MC97 modem controller are deactivated when a second PCI soundcard
is present. This patch enables them.
Signed-off-by: Bauke Jan Douma <[email protected]>
---
When a PCI soundcard is present in an Asus A8V or A8V Deluxe system, the
BIOS will disable the onboard AC97 and MC97 devices. This patch enables
them. The soundcard now works on my A8V Deluxe, shows up in lspci output,
in /proc/asound/cards, has mixer controls, plays audio, on both 32 bits
and 64 bits systems.
Patch is against 2.6.16-rc3.
--- ./linux-2.6.16-rc3/drivers/pci/quirks.c.orig 2006-02-28 00:54:47.000000000
+0100
+++ ./linux-2.6.16-rc3/drivers/pci/quirks.c 2006-02-28 21:34:46.000000000 +0100
@@ -1074,6 +1074,37 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_S
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_963,
quirk_sis_96x_smbus );
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_LPC,
quirk_sis_96x_smbus );
+/*
+ * On ASUS A8V and A8V Deluxe boards, the onboard AC97 audio controller
+ * and MC97 modem controller are disabled when a second PCI soundcard is
+ * present. This patch, tweaking the VT8237 ISA bridge, enables them.
+ * -- bjd
+ */
+static void __init asus_hides_ac97_lpc(struct pci_dev *dev)
+{
+ u8 val;
+ int asus_hides_ac97 = 0;
+
+ if (likely(dev->subsystem_vendor == PCI_VENDOR_ID_ASUSTEK)) {
+ if (dev->device == PCI_DEVICE_ID_VIA_8237)
+ asus_hides_ac97 = 1;
+ }
+
+ if (!asus_hides_ac97)
+ return;
+
+ pci_read_config_byte(dev, 0x50, &val);
+ if (val & 0xc0) {
+ pci_write_config_byte(dev, 0x50, val & (~0xc0));
+ pci_read_config_byte(dev, 0x50, &val);
+ if (val & 0xc0)
+ printk(KERN_INFO "PCI: onboard AC97/MC97 devices continue to
play 'hide and seek'! 0x%x\n", val);
+ else
+ printk(KERN_INFO "PCI: enabled onboard AC97/MC97 devices\n");
+ }
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8237,
asus_hides_ac97_lpc );
+
#ifdef CONFIG_X86_IO_APIC
static void __init quirk_alder_ioapic(struct pci_dev *pdev)
{
On Sun, Mar 05, 2006 at 08:27:09PM +0100, bjd wrote:
> +static void __init asus_hides_ac97_lpc(struct pci_dev *dev)
> +{
> + u8 val;
> + int asus_hides_ac97 = 0;
> +
> + if (likely(dev->subsystem_vendor == PCI_VENDOR_ID_ASUSTEK)) {
> + if (dev->device == PCI_DEVICE_ID_VIA_8237)
> + asus_hides_ac97 = 1;
> + }
> +
> + if (!asus_hides_ac97)
> + return;
Why likely ? It's just as unlikely to be an ASUS.
Also, why not just ..
if (dev->subsystem_vendor != PCI_VENDOR_ID_ASUSTEK)
return;
if (dev->device != PCI_DEVICE_ID_VIA_8237)
return;
and lose the asus_hides_ac97 var completely?
Is this true of every ASUS board that has an 8237 ?
Does it actually remove the enable/disable ac97 feature from the BIOS,
or just reset it to disabled ?
> + pci_read_config_byte(dev, 0x50, &val);
> + if (val & 0xc0) {
> + pci_write_config_byte(dev, 0x50, val & (~0xc0));
> + pci_read_config_byte(dev, 0x50, &val);
> + if (val & 0xc0)
> + printk(KERN_INFO "PCI: onboard AC97/MC97 devices continue to
> play 'hide and seek'! 0x%x\n", val);
How often does this trigger ?
The message could be a little more end-user friendly too
"Failed to enable onboard AC97/MC97 devices"
Dave
--
http://www.codemonkey.org.uk
On Sun, 2006-03-05 at 20:27 +0100, bjd wrote:
> From: Bauke Jan Douma <[email protected]>
>
> On ASUS A8V and A8V Deluxe boards, the onboard AC97 audio controller
> and MC97 modem controller are deactivated when a second PCI soundcard
> is present. This patch enables them.
Thanks for fixing this! We get a ton of complaints about this "feature"
on the ALSA lists.
Do we have any idea why ASUS would have done such a thing? Users hate
it. Are they working around a hardware or Windows bug?
Lee
bjd <[email protected]> writes:
> From: Bauke Jan Douma <[email protected]>
>
> On ASUS A8V and A8V Deluxe boards, the onboard AC97 audio controller
> and MC97 modem controller are deactivated when a second PCI soundcard
> is present. This patch enables them.
Will this work with P4V8X boards too? I've been quite annoyed by this
silly "feature".
--
M?ns Rullg?rd
[email protected]
On Sun, 2006-03-05 15:32:22 -0500, Lee Revell <[email protected]> wrote:
> On Sun, 2006-03-05 at 20:27 +0100, bjd wrote:
> > From: Bauke Jan Douma <[email protected]>
> > On ASUS A8V and A8V Deluxe boards, the onboard AC97 audio controller
> > and MC97 modem controller are deactivated when a second PCI soundcard
> > is present. This patch enables them.
>
> Thanks for fixing this! We get a ton of complaints about this "feature"
> on the ALSA lists.
On our LUG list ([email protected]) we had such a case as well, about a
year ago.
> Do we have any idea why ASUS would have done such a thing? Users hate
> it. Are they working around a hardware or Windows bug?
The point is that most people either use the on-board stuff, _or_ they
buy a soundcard to use that one. Vendors seem to think they shouldn't
confuse users with always letting them choose between _two_ sound
cards.
There are two trick you can play. Either disable the card in the PCI
config space, or (in older mainboards of i486 class with ISA) they
used custom ASICs in between that were activated by some magic
sequence written to some magic ISA I/O ports.
In the first case, it's quite simple to figure out how to re-enable
the card. If this is an issue somewhere, please feel free to ask for
help. Maybe even a little helper program could be written to aid in
finding the appropriate bits.
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
M?ns Rullg?rd <[email protected]> writes:
> bjd <[email protected]> writes:
>
>> From: Bauke Jan Douma <[email protected]>
>>
>> On ASUS A8V and A8V Deluxe boards, the onboard AC97 audio controller
>> and MC97 modem controller are deactivated when a second PCI soundcard
>> is present. This patch enables them.
>
> Will this work with P4V8X boards too? I've been quite annoyed by this
> silly "feature".
It does the trick for my P4V8X-X board.
--
M?ns Rullg?rd
[email protected]
bjd wrote:
> From: Bauke Jan Douma <[email protected]>
>
> On ASUS A8V and A8V Deluxe boards, the onboard AC97 audio controller
> and MC97 modem controller are deactivated when a second PCI soundcard
> is present. This patch enables them.
Thanks for the patch! I can't wait to go home and try it. AFAIK it affects
other boards aside of the ASUS A8V using the same chipset. Once I contacted
the ASUS support and they told me due to the chipset's design it is not
possible to enable the onboard sound when a PCI card is installed. It is
amazing that you could do it. :-)
Andras
On Fri, 2006-03-17 12:38:33 +0200, Andras Mantia <[email protected]> wrote:
> bjd wrote:
> > From: Bauke Jan Douma <[email protected]>
> > On ASUS A8V and A8V Deluxe boards, the onboard AC97 audio controller
> > and MC97 modem controller are deactivated when a second PCI soundcard
> > is present. This patch enables them.
>
> Thanks for the patch! I can't wait to go home and try it. AFAIK it affects
> other boards aside of the ASUS A8V using the same chipset. Once I contacted
> the ASUS support and they told me due to the chipset's design it is not
> possible to enable the onboard sound when a PCI card is installed. It is
> amazing that you could do it. :-)
Nonsense :-) These days, it's merely only a bit in PCI config space
that needs a flip. Since vendors seem more and more to `care' about
their customers to only use one (that is, the newly bought additional
sound card, or even other equipment) I even thought about writing a
little helper program to help finding the correct bit.
Just for the records, it happens actually quite often that some little
features / improvements of a chipset have bugs; from time to time,
you'll see a BIOS update that doesn't really do more than switching
off that feature. I guess that quite some of our quirks originate from
looking at what a newer BIOS configures differently compared to an
older version. Some instability can be fixed that way (though it's
better to have a fix for such a bug inside the BIOS: this way, the fix
is in place at the time the Linux kernel is loaded, so there's no way
for it to eg. cause memory corruption between loading the kernel and
issueing the quirks.)
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Jan-Benedict Glaw wrote:
> Just for the records, it happens actually quite often that some little
> features / improvements of a chipset have bugs; from time to time,
> you'll see a BIOS update that doesn't really do more than switching
> off that feature. I guess that quite some of our quirks originate from
> looking at what a newer BIOS configures differently compared to an
> older version. Some instability can be fixed that way (though it's
> better to have a fix for such a bug inside the BIOS: this way, the fix
> is in place at the time the Linux kernel is loaded, so there's no way
> for it to eg. cause memory corruption between loading the kernel and
> issueing the quirks.)
I know, but in this case I got this answer:
" Dear Friend :
Thank you for contacting ASUS Customer Service.
My name is ZYC, and I would be assisting you today.
sorry ,due to chipset limitation ,
when you add a PCI AUDIO card to a board which use VIA VT8237 southbridge
controller ,
the built in AC97 audio will be disabled automaticly .
it is a chip limitation without way to fix ."
Meantime I tried the patch against the 2.6.13-15 kernel shipped with SuSE 10
(applied without errors), and altough I see
PCI: enabled onboard AC97/MC97 devices
in the logs, the onboard card doesn't appear in lspci.
I'm downloading the 2.6.16-rc6 kernel to try with that one. Mine is an
A8V-Deluxe, so I don't know why it didn't work. :-( I have the latest Asus
bios and verified that it is enabled in the BIOS (I know, it doesn't really
matter, but I mention here).
Andras
--
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
On Fri, 2006-03-17 16:43:55 +0200, Andras Mantia <[email protected]> wrote:
> Jan-Benedict Glaw wrote:
> I know, but in this case I got this answer:
> " Dear Friend :
Huh?
> Thank you for contacting ASUS Customer Service.
> My name is ZYC, and I would be assisting you today.
Interesting name...
> sorry ,due to chipset limitation ,
> when you add a PCI AUDIO card to a board which use VIA VT8237 southbridge
> controller ,
> the built in AC97 audio will be disabled automaticly .
> it is a chip limitation without way to fix ."
>
> Meantime I tried the patch against the 2.6.13-15 kernel shipped with SuSE 10
> (applied without errors), and altough I see
> PCI: enabled onboard AC97/MC97 devices
>
> in the logs, the onboard card doesn't appear in lspci.
Maybe the fix was running too late? There needs to be a PCI bus scan
afterwards... Test with a newer kernel version, hopefully not patched
to death...
MfG, JBG
--
Jan-Benedict Glaw [email protected] . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Jan-Benedict Glaw wrote:
>> Thank you for contacting ASUS Customer Service.
>> My name is ZYC, and I would be assisting you today.
>
> Interesting name...
Yeah, I have a link to the asus page where my case is handled, if you
want. ;-)
> Maybe the fix was running too late? There needs to be a PCI bus scan
> afterwards... Test with a newer kernel version, hopefully not patched
> to death...
I tested with 2.6.16-rc6. The only patch (aside of this one) I applied was
the libata patch as I need support for the PATA port on a Promise
controller.
It doesn't work and nothing appears in the log (not even the text that it is
still "hiding"). I'm starting to think that I missed some step. Is there
something else needed aside of applying the patch as it is, recompile the
kernel and install it?
I touch the kernel code only seldom, usually I port a patch from one version
to another, like the promise PATA patch to the SuSE kernel, but I don't
really know the kernel internals.
Andras
--
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
Andras Mantia <[email protected]> writes:
> Jan-Benedict Glaw wrote:
>
>> Just for the records, it happens actually quite often that some little
>> features / improvements of a chipset have bugs; from time to time,
>> you'll see a BIOS update that doesn't really do more than switching
>> off that feature. I guess that quite some of our quirks originate from
>> looking at what a newer BIOS configures differently compared to an
>> older version. ?Some instability can be fixed that way (though it's
>> better to have a fix for such a bug inside the BIOS: this way, the fix
>> is in place at the time the Linux kernel is loaded, so there's no way
>> for it to eg. cause memory corruption between loading the kernel and
>> issueing the quirks.)
> I know, but in this case I got this answer:
> " Dear Friend :
> Thank you for contacting ASUS Customer Service.
> My name is ZYC, and I would be assisting you today.
> sorry ,due to chipset limitation ,
> when you add a PCI AUDIO card to a board which use VIA VT8237 southbridge
> controller ,
> the built in AC97 audio will be disabled automaticly .
> it is a chip limitation without way to fix ."
What a liar.
> Meantime I tried the patch against the 2.6.13-15 kernel shipped with SuSE 10
> (applied without errors), and altough I see
> PCI: enabled onboard AC97/MC97 devices
>
> in the logs, the onboard card doesn't appear in lspci.
>
> I'm downloading the 2.6.16-rc6 kernel to try with that one. Mine is an
> A8V-Deluxe, so I don't know why it didn't work. :-( I have the latest Asus
> bios and verified that it is enabled in the BIOS (I know, it doesn't really
> matter, but I mention here).
The patch works on my Asus P4V8X-X board. There is one problem
though. With a CMI8738 based PCI sound card in PCI slot 3 the machine
locks up solid when I try to use it. No problems at all with the card
in slot 2.
--
M?ns Rullg?rd
[email protected]
Andras Mantia <[email protected]> writes:
> Jan-Benedict Glaw wrote:
>
>>> Thank you for contacting ASUS Customer Service.
>>> My name is ZYC, and I would be assisting you today.
>>
>> Interesting name...
>
> Yeah, I have a link to the asus page where my case is handled, if you
> want. ;-)
>
>> Maybe the fix was running too late? There needs to be a PCI bus scan
>> afterwards... Test with a newer kernel version, hopefully not patched
>> to death...
>
> I tested with 2.6.16-rc6. The only patch (aside of this one) I applied was
> the libata patch as I need support for the PATA port on a Promise
> controller.
> It doesn't work and nothing appears in the log (not even the text that it is
> still "hiding"). I'm starting to think that I missed some step. Is there
> something else needed aside of applying the patch as it is, recompile the
> kernel and install it?
I didn't do anything else. Check that your chipset has the same PCI
ID that the patch is for.
--
M?ns Rullg?rd
[email protected]
Måns Rullgård wrote:
> I didn't do anything else. Check that your chipset has the same PCI
> ID that the patch is for.
>
Indeed, the problem is here. If I use
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA, PCI_ANY_ID,
asus_hides_ac97_lpc );
(see the PCI_ANY_ID) instead of
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8237,
asus_hides_ac97_lpc );
(and remove the check "if (likely(!asus_hides_ac97)) return;")
it works. I cannot see the output about enabling the device in "dmesg | grep
PCI", but lspci shows the audio and modem device.
And it works both with the 2.6.13 suse and 2.6.15 vanilla kernel.
I managed to hang the machine completely with skype, altough before that a
quick test showed that the device works, as I could hear the music. Maybe
it's the same problem you've experienced.
Can you tell me how can I find the real device ID for my chipset? It
*should* be the same one as the original writer of the patch wrote (he also
had an ASUS A8V Deluxe as I understood), but the experience tells it is
not.
My lspci output is:
00:00.0 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
00:00.1 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
00:00.2 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
00:00.3 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
00:00.4 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
00:00.7 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890
South]
00:07.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host
Controller (rev 80)
00:08.0 RAID bus controller: Promise Technology, Inc. PDC20378 (FastTrak
378/SATA 378) (rev 02)
00:0a.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit
Ethernet Controller (rev 13)
00:0c.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07)
00:0c.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev
07)
00:0e.0 Multimedia video controller: Brooktree Corporation Bt848 Video
Capture (rev 12)
00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID
Controller (rev 80)
00:0f.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 81)
00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 81)
00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge
[KT600/K8T800/K8T890 South]
00:11.5 Multimedia audio controller: VIA Technologies, Inc.
VT8233/A/8235/8237 AC97 Audio Controller (rev 60)
00:11.6 Communication controller: VIA Technologies, Inc. AC'97 Modem
Controller (rev 80)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM
Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Miscellaneous Control
01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5500]
(rev a1)
Thanks,
Andras
--
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
Andras Mantia <[email protected]> writes:
> M?ns Rullg?rd wrote:
>
>> I didn't do anything else. ?Check that your chipset has the same PCI
>> ID that the patch is for.
>>
>
> Indeed, the problem is here. If I use
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA, PCI_ANY_ID,
> asus_hides_ac97_lpc );
>
> (see the PCI_ANY_ID) instead of
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8237,
> asus_hides_ac97_lpc );
>
> (and remove the check "if (likely(!asus_hides_ac97)) return;")
> it works. I cannot see the output about enabling the device in "dmesg | grep
> PCI", but lspci shows the audio and modem device.
> And it works both with the 2.6.13 suse and 2.6.15 vanilla kernel.
That certainly suggests that your chipset has a different PCI ID.
> I managed to hang the machine completely with skype, altough before that a
> quick test showed that the device works, as I could hear the music. Maybe
> it's the same problem you've experienced.
With the card in the bad slot I only got a few seconds of sound before
the machine locked up. Since you have a different board, it could of
course still be a similar problem, just less likely to happen.
Which sound card were you using when your machine hung?
> Can you tell me how can I find the real device ID for my chipset? It
> *should* be the same one as the original writer of the patch wrote (he also
> had an ASUS A8V Deluxe as I understood), but the experience tells it is
> not.
lspci -n will list the PCI IDs in hex.
--
M?ns Rullg?rd
[email protected]
Måns Rullgård wrote:
> With the card in the bad slot I only got a few seconds of sound before
> the machine locked up. Since you have a different board, it could of
> course still be a similar problem, just less likely to happen.
>
> Which sound card were you using when your machine hung?
I tried to use the onboard sound card at that time.
>> Can you tell me how can I find the real device ID for my chipset? It
>> *should* be the same one as the original writer of the patch wrote (he
>> also had an ASUS A8V Deluxe as I understood), but the experience tells it
>> is not.
>
> lspci -n will list the PCI IDs in hex.
Thanks.
Andras
--
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
Andras Mantia <[email protected]> writes:
> M?ns Rullg?rd wrote:
>> With the card in the bad slot I only got a few seconds of sound before
>> the machine locked up. Since you have a different board, it could of
>> course still be a similar problem, just less likely to happen.
>>
>> Which sound card were you using when your machine hung?
>
> I tried to use the onboard sound card at that time.
Hmm, mine crashed when I used the PCI card. Using the onboard sound
was fine.
>>> Can you tell me how can I find the real device ID for my chipset? It
>>> *should* be the same one as the original writer of the patch wrote (he
>>> also had an ASUS A8V Deluxe as I understood), but the experience tells it
>>> is not.
>>
>> lspci -n will list the PCI IDs in hex.
>
> Thanks.
Care to post the output?
--
M?ns Rullg?rd
[email protected]
Måns Rullgård wrote:
> Hmm, mine crashed when I used the PCI card. Using the onboard sound
> was fine.
Now it doesn't crash. :-0 That hang was with kernel 2.6.15, but I switeched
back to 2.6.13 as that is what suse provides and I played some music on
both cards and tried Skype on the onboard card (there was the hang) and it
was OK.
>>>> Can you tell me how can I find the real device ID for my chipset? It
>>>> *should* be the same one as the original writer of the patch wrote (he
>>>> also had an ASUS A8V Deluxe as I understood), but the experience tells
>>>> it is not.
>>>
>>> lspci -n will list the PCI IDs in hex.
>>
>> Thanks.
>
> Care to post the output?
Sure. I still don't know how to use those numbers in the quircks.c (do I
need to create something like #define PCI_DEVICE_WHATEVER pciIDNumber ?).
# lspci -n
00:00.0 Class 0600: 1106:0282
00:00.1 Class 0600: 1106:1282
00:00.2 Class 0600: 1106:2282
00:00.3 Class 0600: 1106:3282
00:00.4 Class 0600: 1106:4282
00:00.7 Class 0600: 1106:7282
00:01.0 Class 0604: 1106:b188
00:07.0 Class 0c00: 1106:3044 (rev 80)
00:08.0 Class 0104: 105a:3373 (rev 02)
00:0a.0 Class 0200: 11ab:4320 (rev 13)
00:0c.0 Class 0401: 1102:0002 (rev 07)
00:0c.1 Class 0980: 1102:7002 (rev 07)
00:0e.0 Class 0400: 109e:0350 (rev 12)
00:0f.0 Class 0104: 1106:3149 (rev 80)
00:0f.1 Class 0101: 1106:0571 (rev 06)
00:10.0 Class 0c03: 1106:3038 (rev 81)
00:10.1 Class 0c03: 1106:3038 (rev 81)
00:10.4 Class 0c03: 1106:3104 (rev 86)
00:11.0 Class 0601: 1106:3227
00:11.5 Class 0401: 1106:3059 (rev 60)
00:11.6 Class 0780: 1106:3068 (rev 80)
00:18.0 Class 0600: 1022:1100
00:18.1 Class 0600: 1022:1101
00:18.2 Class 0600: 1022:1102
00:18.3 Class 0600: 1022:1103
01:00.0 Class 0300: 10de:0326 (rev a1)
The result of lspci -vvvn is attached.
Andras
--
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
Andras Mantia <[email protected]> writes:
> M?ns Rullg?rd wrote:
>> Hmm, mine crashed when I used the PCI card. Using the onboard sound
>> was fine.
>
> Now it doesn't crash. :-0 That hang was with kernel 2.6.15, but I switeched
> back to 2.6.13 as that is what suse provides and I played some music on
> both cards and tried Skype on the onboard card (there was the hang) and it
> was OK.
Just write it off to cosmic rays if it doesn't happen again.
>>>>> Can you tell me how can I find the real device ID for my chipset? It
>>>>> *should* be the same one as the original writer of the patch wrote (he
>>>>> also had an ASUS A8V Deluxe as I understood), but the experience tells
>>>>> it is not.
>>>>
>>>> lspci -n will list the PCI IDs in hex.
>>>
>>> Thanks.
>>
>> Care to post the output?
>
> Sure. I still don't know how to use those numbers in the quircks.c (do I
> need to create something like #define PCI_DEVICE_WHATEVER pciIDNumber ?).
The device IDs are already #defined in <linux/pci_ids.h>.
> The result of lspci -vvvn is attached.
> 00:11.0 Class 0601: 1106:3227
> Subsystem: 1043:80ed
This is the interesting bit. Curiously enough, it is exactly the same
as mine. I can't see any reason why it shouldn't match on your board.
Try sticking some printk()s in there and find out what values are
actually seen.
--
M?ns Rullg?rd
[email protected]
Måns Rullgård wrote:
> This is the interesting bit. Curiously enough, it is exactly the same
> as mine. I can't see any reason why it shouldn't match on your board.
>
> Try sticking some printk()s in there and find out what values are
> actually seen.
I found why it didn't work on my PC before. I wrote that I not only enabled
for every PCI id, but removed the following check:
if (likely(!asus_hides_ac97))
return;
This was the bit which made it work. After putting some debugging
information it turned out that asus_hides_ac97_lpc was called *before*
asus_hides_ac97_device, so the asus_hides_ac97 remained 0 in that check.
As far as I know this problem appears on all VT8237 boards (I found in
several forums), I suggest to completely drop the asus_hides_ac97_device
function and the above if clause.
See the debug outputs:
Inside asus_hides_ac97_lpc
asus_hides_ac97=0
device: 0x3227
PCI: enabled onboard AC97/MC97 devices
Inside asus_hides_ac97_device
vendor 0x1043
device 0x3227
Andras
--
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
Andras Mantia <[email protected]> writes:
> M?ns Rullg?rd wrote:
>
>> This is the interesting bit. Curiously enough, it is exactly the same
>> as mine. I can't see any reason why it shouldn't match on your board.
>>
>> Try sticking some printk()s in there and find out what values are
>> actually seen.
>
> I found why it didn't work on my PC before. I wrote that I not only enabled
> for every PCI id, but removed the following check:
>
> if (likely(!asus_hides_ac97))
> return;
>
> This was the bit which made it work. After putting some debugging
> information it turned out that asus_hides_ac97_lpc was called *before*
> asus_hides_ac97_device, so the asus_hides_ac97 remained 0 in that check.
>
> As far as I know this problem appears on all VT8237 boards (I found in
> several forums), I suggest to completely drop the asus_hides_ac97_device
> function and the above if clause.
Hmm, we seem to be using different patches. Here's what I'm using:
--- drivers/pci/quirks.c.orig 2006-01-03 03:21:10.000000000 +0000
+++ drivers/pci/quirks.c 2006-03-19 16:34:02.021338158 +0000
@@ -1074,6 +1074,33 @@
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_963, quirk_sis_96x_smbus );
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_LPC, quirk_sis_96x_smbus );
+/*
+ * On ASUS A8V and A8V Deluxe boards, the onboard AC97 audio controller
+ * and MC97 modem controller are disabled when a second PCI soundcard is
+ * present. This patch, tweaking the VT8237 ISA bridge, enables them.
+ * -- bjd
+ */
+static void __init asus_hides_ac97_lpc(struct pci_dev *dev)
+{
+ u8 val;
+
+ if (dev->subsystem_vendor != PCI_VENDOR_ID_ASUSTEK)
+ return;
+ if (dev->device != PCI_DEVICE_ID_VIA_8237)
+ return;
+
+ pci_read_config_byte(dev, 0x50, &val);
+ if (val & 0xc0) {
+ pci_write_config_byte(dev, 0x50, val & (~0xc0));
+ pci_read_config_byte(dev, 0x50, &val);
+ if (val & 0xc0)
+ printk(KERN_INFO "PCI: Failed to enable onboard AC97/MC97 devices: 0x%x\n", val);
+ else
+ printk(KERN_INFO "PCI: enabled onboard AC97/MC97 devices\n");
+ }
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8237, asus_hides_ac97_lpc );
+
#ifdef CONFIG_X86_IO_APIC
static void __init quirk_alder_ioapic(struct pci_dev *pdev)
{
--
M?ns Rullg?rd
[email protected]
Måns Rullgård wrote:
> Hmm, we seem to be using different patches. Here's what I'm using:
>
Oh, yeah. I used the original one posted here (actually I get from some -mm
patch collection IIRC, I don't remember from which one).
Anyway, my suggestion remains, that the
+ if (dev->subsystem_vendor != PCI_VENDOR_ID_ASUSTEK)
+ return;
+ if (dev->device != PCI_DEVICE_ID_VIA_8237)
+ return;
might be not needed at all as it is not ASUS specific. I don't understand
the second if, as (from my limited knowledge) it seems that
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8237,
asus_hides_ac97_lpc );
already means the function will be called only for devices with PCI id
PCI_DEVICE_ID_VIA_8237 .
Andras
--
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
Andras Mantia <[email protected]> writes:
> M?ns Rullg?rd wrote:
>
>> Hmm, we seem to be using different patches. ?Here's what I'm using:
>>
> Oh, yeah. I used the original one posted here (actually I get from
> some -mm patch collection IIRC, I don't remember from which one).
OK, I just used the simpler (and newer) of the two versions that were
posted, and modified as suggested by someone. Does my version work on
your machine?
> Anyway, my suggestion remains, that the
> + if (dev->subsystem_vendor != PCI_VENDOR_ID_ASUSTEK)
> + return;
> + if (dev->device != PCI_DEVICE_ID_VIA_8237)
> + return;
>
> might be not needed at all as it is not ASUS specific.
Doesn't it depend on the BIOS? My BIOS lets me choose between
"automatic" and "disabled" for the onboard sound.
> I don't understand the second if, as (from my limited knowledge) it
> seems that
>
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8237,
> asus_hides_ac97_lpc );
>
> already means the function will be called only for devices with PCI id
> PCI_DEVICE_ID_VIA_8237 .
That struck me too.
--
M?ns Rullg?rd
[email protected]
Måns Rullgård wrote:
> OK, I just used the simpler (and newer) of the two versions that were
> posted, and modified as suggested by someone. Does my version work on
> your machine?
I did not try it, but because of the code and the outputs I got when I tried
to find the problem I'm sure it would work.
>> Anyway, my suggestion remains, that the
>> + if (dev->subsystem_vendor != PCI_VENDOR_ID_ASUSTEK)
>> + return;
>> + if (dev->device != PCI_DEVICE_ID_VIA_8237)
>> + return;
>>
>> might be not needed at all as it is not ASUS specific.
>
> Doesn't it depend on the BIOS? My BIOS lets me choose between
> "automatic" and "disabled" for the onboard sound.
I don't see how that setting could change the device ID or the vendor ID. As
I understood the above code will simply not try to enable the sound device
if:
a) the vendor is not ASUSTEK
b) the device is not ID is not PCI_DEVICE_ID_VIA_8237
For a) it means that an MSI/Epox/whatever board with the same VIA chipset
and the same problem will not be handled. For b) see my previous comment
(and your concerns).
Well, it would be nice if a kernel developer could comment on it, or simply
include the right version in some upcoming release. ;-)
Andras
--
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
Andras Mantia <[email protected]> writes:
>>> Anyway, my suggestion remains, that the
>>> + if (dev->subsystem_vendor != PCI_VENDOR_ID_ASUSTEK)
>>> + return;
>>> + if (dev->device != PCI_DEVICE_ID_VIA_8237)
>>> + return;
>>>
>>> might be not needed at all as it is not ASUS specific.
>>
>> Doesn't it depend on the BIOS? My BIOS lets me choose between
>> "automatic" and "disabled" for the onboard sound.
>
> I don't see how that setting could change the device ID or the vendor ID. As
> I understood the above code will simply not try to enable the sound device
> if:
> a) the vendor is not ASUSTEK
> b) the device is not ID is not PCI_DEVICE_ID_VIA_8237
>
> For a) it means that an MSI/Epox/whatever board with the same VIA chipset
> and the same problem will not be handled. For b) see my previous comment
It is the BIOS that disables the onboard sound if it detects a PCI
sound card. Chances are other vendors use different BIOS
configurations that do not automatically disable things. I don't know
if messing with those bits might do something bad on another board.
--
M?ns Rullg?rd
[email protected]
Måns Rullgård wrote:
> It is the BIOS that disables the onboard sound if it detects a PCI
> sound card. Chances are other vendors use different BIOS
> configurations that do not automatically disable things. I don't know
> if messing with those bits might do something bad on another board.
>
Yes, this might be a case, but you never know if ASUS engineers realize that
they can enable the board even if there is a PCI card and will include in
the next bios (as I wrote, they say it is impossible, but you never know).
So checking for ASUS will be wrong starting from that BIOS version.
When I first saw this bug on my system I searched a lot to see if I made a
wrong decision by buying ASUS and not another brand and everywhere on the
forums the same issue was described for other brands as well.
>From the code I would say that
pci_read_config_byte(dev, 0x50, &val);
if (val & 0xc0) {
is the test if it's enabled by the bios or not, as after trying to enable
with
pci_write_config_byte(dev, 0x50, val & (~0xc0));
it reads again the same byte and checks if the correct bits are enabled.
I see no harm here, but as I said I am not a hardware guy, just a desktop
programmer. ;-)
Andras
--
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org