Some pcnet32 hardware erroneously has the Vendor ID for Trident. The
pcnet32 driver looks for the PCI ethernet class before grabbing the
hardware, but the current trident driver does not check against the
PCI audio class. This allows the trident driver to claim the pcnet32
hardware. This patch prevents that.
This patch is untested on Trident 4DWAVE_DX hardware, but has been
tested on pcnet32 hardware.
Thanks,
Jon
Signed-off-by: Jon Mason <[email protected]>
diff -r 4a7597b41d25 sound/oss/trident.c
--- a/sound/oss/trident.c Wed Jan 11 19:14:08 2006
+++ b/sound/oss/trident.c Thu Jan 12 11:32:26 2006
@@ -279,7 +279,8 @@
static struct pci_device_id trident_pci_tbl[] = {
{PCI_VENDOR_ID_TRIDENT, PCI_DEVICE_ID_TRIDENT_4DWAVE_DX,
- PCI_ANY_ID, PCI_ANY_ID, 0, 0, TRIDENT_4D_DX},
+ PCI_ANY_ID, PCI_ANY_ID, PCI_CLASS_MULTIMEDIA_AUDIO << 8, 0xffff00,
+ TRIDENT_4D_DX},
{PCI_VENDOR_ID_TRIDENT, PCI_DEVICE_ID_TRIDENT_4DWAVE_NX,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, TRIDENT_4D_NX},
{PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_7018,
Jon Mason napsal(a):
> Some pcnet32 hardware erroneously has the Vendor ID for Trident. The
> pcnet32 driver looks for the PCI ethernet class before grabbing the
> hardware, but the current trident driver does not check against the
> PCI audio class. This allows the trident driver to claim the pcnet32
> hardware. This patch prevents that.
>
> This patch is untested on Trident 4DWAVE_DX hardware, but has been
> tested on pcnet32 hardware.
>
> Thanks,
> Jon
>
> Signed-off-by: Jon Mason <[email protected]>
>
> diff -r 4a7597b41d25 sound/oss/trident.c
> --- a/sound/oss/trident.c Wed Jan 11 19:14:08 2006
> +++ b/sound/oss/trident.c Thu Jan 12 11:32:26 2006
You should change alsa driver (sound/pci/trident/trident.c), rather than this,
which will be removed soon, I guess. And, additionally, could you change that
lines to use PCI_DEVICE macro?
regards,
--
Jiri Slaby http://www.fi.muni.cz/~xslaby
~\-/~ [email protected] ~\-/~
B67499670407CE62ACC8 22A032CC55C339D47A7E
Jiri Slaby napsal(a):
> which will be removed soon, I guess. And, additionally, could you change that
> lines to use PCI_DEVICE macro?
plus in alsa driver converting to use macros from pci_ids for devices instead of
numbers.
thanks,
--
Jiri Slaby http://www.fi.muni.cz/~xslaby
~\-/~ [email protected] ~\-/~
B67499670407CE62ACC8 22A032CC55C339D47A7E
On Thu, Jan 12, 2006 at 08:28:30PM +0100, Jiri Slaby wrote:
> You should change alsa driver (sound/pci/trident/trident.c), rather than this,
> which will be removed soon, I guess. And, additionally, could you change that
> lines to use PCI_DEVICE macro?
This driver is not up for removal soon, as it supports a device that
the alsa driver apparently doesn't (the INTERG_5050). As for
PCI_DEVICE, agreed. Jon, feel like patching it up?
Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/
Jon Mason wrote:
> Some pcnet32 hardware erroneously has the Vendor ID for Trident. The
> pcnet32 driver looks for the PCI ethernet class before grabbing the
> hardware, but the current trident driver does not check against the
> PCI audio class. This allows the trident driver to claim the pcnet32
> hardware. This patch prevents that.
On the subject of pcnet32 and the invalid vendor ID, you may find this
interesting:
http://forums.gentoo.org/viewtopic-t-420013-highlight-trident.html
The user saw the correct vendor ID (AMD) in 2.4, but when upgrading to
2.6, it changed to Trident.
I guess this is still likely to be a hardware bug, but it demonstrates
that the Linux PCI layer has something to do with it (even if it is just
triggering it somehow).
Daniel
On Thu, Jan 12, 2006 at 08:49:42PM +0000, Daniel Drake wrote:
> interesting:
>
> http://forums.gentoo.org/viewtopic-t-420013-highlight-trident.html
>
> The user saw the correct vendor ID (AMD) in 2.4, but when upgrading to
> 2.6, it changed to Trident.
It looks to me like there used to be a quirk that knew about this bug
and fixed it.
The reason I say this is that the lspci -x dumps are the same -- both
featuring the wrong vendor ID. Want to dig through 2.4 and look for
this quirk?
Matthew Wilcox wrote:
> It looks to me like there used to be a quirk that knew about this bug
> and fixed it.
>
> The reason I say this is that the lspci -x dumps are the same -- both
> featuring the wrong vendor ID.
Good catch. I didn't notice this.
> Want to dig through 2.4 and look for
> this quirk?
No time for this personally.
Daniel
On Thu, Jan 12, 2006 at 08:49:42PM +0000, Daniel Drake wrote:
> On the subject of pcnet32 and the invalid vendor ID, you may find this
> interesting:
>
> http://forums.gentoo.org/viewtopic-t-420013-highlight-trident.html
>
> The user saw the correct vendor ID (AMD) in 2.4, but when upgrading to
> 2.6, it changed to Trident.
>
> I guess this is still likely to be a hardware bug, but it demonstrates
> that the Linux PCI layer has something to do with it (even if it is just
> triggering it somehow).
Perhaps there is a significant different in the pcnet32.c files between
the two versions. I also remember that there is some powerpc specific
code in there related to MAC address detection. There are certainly
differences in 2.4 and 2.6's version of the driver, maybe something is
broken in the newer one when run on powerpc. I don't run gentoo and
have no idea how to get a hold of the source of pcnet32.c from each of
those two.
It does seem odd that only the pcnet32 has the pci ID change, but at the
same time, somehow the driver is recognizing it and loading at boot
time, so the ID can't be wrong at that time. Does the ID get mangled as
part of what makes the MAC addresses read incorrectly on your 2.6.14?
The 2.4 system shows all the cards overriding the MAC based on the PROM,
which I believe is what the driver code should do on a powerpc system.
On 2.6 that appears to only happen on one of the cards. At least on
that device (pci 01:01) appears to agree what the MAC should be in both
cases.
Perhaps the lspci being wrong is just a side effect of the real problem.
Maybe the driver is broken and messing things up.
Len Sorensen
On Thu, Jan 12, 2006 at 01:57:14PM -0700, Matthew Wilcox wrote:
> On Thu, Jan 12, 2006 at 08:49:42PM +0000, Daniel Drake wrote:
> > interesting:
> >
> > http://forums.gentoo.org/viewtopic-t-420013-highlight-trident.html
> >
> > The user saw the correct vendor ID (AMD) in 2.4, but when upgrading to
> > 2.6, it changed to Trident.
>
> It looks to me like there used to be a quirk that knew about this bug
> and fixed it.
>
> The reason I say this is that the lspci -x dumps are the same -- both
> featuring the wrong vendor ID. Want to dig through 2.4 and look for
> this quirk?
Oh -- found it. It's still in 2.6:
static void
fixup_broken_pcnet32(struct pci_dev* dev)
{
if ((dev->class>>8 == PCI_CLASS_NETWORK_ETHERNET)) {
dev->vendor = PCI_VENDOR_ID_AMD;
pci_write_config_word(dev, PCI_VENDOR_ID, PCI_VENDOR_ID_AMD);
}
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_TRIDENT, PCI_ANY_ID,
fixup_broken_pcnet32);
Wonder why it isn't working now ... someone with a PPC box needs to check
(a) whether this function is being called and (b) if it is called, why
it's not doing what it's supposed to.
On Thu, 2006-01-12 at 22:07 +0200, Muli Ben-Yehuda wrote:
> On Thu, Jan 12, 2006 at 08:28:30PM +0100, Jiri Slaby wrote:
>
> > You should change alsa driver (sound/pci/trident/trident.c), rather than this,
> > which will be removed soon, I guess. And, additionally, could you change that
> > lines to use PCI_DEVICE macro?
>
> This driver is not up for removal soon, as it supports a device that
> the alsa driver apparently doesn't (the INTERG_5050).
When were you going to report this?
Lee
Matthew Wilcox ([email protected]) said:
> On Thu, Jan 12, 2006 at 01:57:14PM -0700, Matthew Wilcox wrote:
> > On Thu, Jan 12, 2006 at 08:49:42PM +0000, Daniel Drake wrote:
> > > interesting:
> > >
> > > http://forums.gentoo.org/viewtopic-t-420013-highlight-trident.html
> > >
> > > The user saw the correct vendor ID (AMD) in 2.4, but when upgrading to
> > > 2.6, it changed to Trident.
> >
> > It looks to me like there used to be a quirk that knew about this bug
> > and fixed it.
> >
> > The reason I say this is that the lspci -x dumps are the same -- both
> > featuring the wrong vendor ID. Want to dig through 2.4 and look for
> > this quirk?
>
> Oh -- found it. It's still in 2.6:
>
> static void
> fixup_broken_pcnet32(struct pci_dev* dev)
> {
> if ((dev->class>>8 == PCI_CLASS_NETWORK_ETHERNET)) {
> dev->vendor = PCI_VENDOR_ID_AMD;
> pci_write_config_word(dev, PCI_VENDOR_ID, PCI_VENDOR_ID_AMD);
> }
> }
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_TRIDENT, PCI_ANY_ID,
> fixup_broken_pcnet32);
>
> Wonder why it isn't working now ... someone with a PPC box needs to check
> (a) whether this function is being called and (b) if it is called, why
> it's not doing what it's supposed to.
I remember looking at this a while back. I think the corrected information
is only being propagated to the 'vendor' file, and the write_config_word
isn't actually updating the 'config' entry in sysfs.
If you remove the "#if 0" from lib/sysfs.c in pciutils, it should
start reporting the corrected value in base lspci, etc.
Bill
Bill Nottingham ([email protected]) said:
> I remember looking at this a while back. I think the corrected information
> is only being propagated to the 'vendor' file, and the write_config_word
> isn't actually updating the 'config' entry in sysfs.
Ah, here's an example from the box I remember working on this on
(without the libpci change):
root@pseries 0000:00:0c.0]# pwd
/sys/bus/pci/devices/0000:00:0c.0
[root@pseries 0000:00:0c.0]# lspci | grep 0c.0
00:0c.0 Ethernet controller: Trident Microsystems 4DWave DX (rev 26)
[root@pseries 0000:00:0c.0]# lspci -n | grep 0c.0
00:0c.0 Class 0200: 1023:2000 (rev 26)
[root@pseries 0000:00:0c.0]# cat vendor
0x1022
[root@pseries 0000:00:0c.0]# cat device
0x2000
[root@pseries 0000:00:0c.0]# od -x config
0000000 2310 0020 4701 8002 2600 0002 0048 0000
0000020 01f0 ff00 0070 21c3 0000 0000 0000 0000
0000040 0000 0000 0000 0000 0000 0000 0000 0000
0000060 0000 10c3 0000 0000 0000 0000 1101 06ff
0000100 0000 0000 0000 0000 0000 0000 0000 0000
*
0000400
Note that the config space is different than the vendor file. This
was with 2.6.9-ish, I don't have the box around any more to confirm
with something more recent.
Bill
On Thu, Jan 12, 2006 at 10:07:35PM +0200, Muli Ben-Yehuda wrote:
> On Thu, Jan 12, 2006 at 08:28:30PM +0100, Jiri Slaby wrote:
>
> > You should change alsa driver (sound/pci/trident/trident.c), rather than this,
> > which will be removed soon, I guess. And, additionally, could you change that
> > lines to use PCI_DEVICE macro?
>
> This driver is not up for removal soon, as it supports a device that
> the alsa driver apparently doesn't (the INTERG_5050). As for
> PCI_DEVICE, agreed. Jon, feel like patching it up?
Patches to follow.
After looking at the ALSA driver, it doesn't support PCI IDs for
ALI_5451 or CYBER5050. Someone should look into porting any necessary
code from sound/oss/trident.c to sound/pci/trident/trident.c
Thanks,
Jon
On Thu, Jan 12, 2006 at 04:15:38PM -0500, Lee Revell wrote:
> On Thu, 2006-01-12 at 22:07 +0200, Muli Ben-Yehuda wrote:
> > On Thu, Jan 12, 2006 at 08:28:30PM +0100, Jiri Slaby wrote:
> >
> > > You should change alsa driver (sound/pci/trident/trident.c), rather than this,
> > > which will be removed soon, I guess. And, additionally, could you change that
> > > lines to use PCI_DEVICE macro?
> >
> > This driver is not up for removal soon, as it supports a device that
> > the alsa driver apparently doesn't (the INTERG_5050).
>
> When were you going to report this?
I already reported this as ALSA bug #1293.
The problem is the lack of a tester, and I'm currently inclined to
schedule this driver for removal although this PCI ID is still missing -
either noone is using these settop boxes anymore or someone will
volunteer to test patches.
> Lee
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
On Thu, Jan 12, 2006 at 03:47:19PM -0600, Jon Mason wrote:
> On Thu, Jan 12, 2006 at 10:07:35PM +0200, Muli Ben-Yehuda wrote:
> > On Thu, Jan 12, 2006 at 08:28:30PM +0100, Jiri Slaby wrote:
> >
> > > You should change alsa driver (sound/pci/trident/trident.c), rather than this,
> > > which will be removed soon, I guess. And, additionally, could you change that
> > > lines to use PCI_DEVICE macro?
> >
> > This driver is not up for removal soon, as it supports a device that
> > the alsa driver apparently doesn't (the INTERG_5050). As for
> > PCI_DEVICE, agreed. Jon, feel like patching it up?
>
> Patches to follow.
>
> After looking at the ALSA driver, it doesn't support PCI IDs for
> ALI_5451 or CYBER5050. Someone should look into porting any necessary
> code from sound/oss/trident.c to sound/pci/trident/trident.c
CYBER5050 is discussed in ALSA bug #1293 (tester wanted).
ALI_5451 is supported by the snd-ali5451 driver.
> Thanks,
> Jon
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
On Thu, 2006-01-12 at 22:58 +0100, Adrian Bunk wrote:
> On Thu, Jan 12, 2006 at 04:15:38PM -0500, Lee Revell wrote:
> > On Thu, 2006-01-12 at 22:07 +0200, Muli Ben-Yehuda wrote:
> > > On Thu, Jan 12, 2006 at 08:28:30PM +0100, Jiri Slaby wrote:
> > >
> > > > You should change alsa driver (sound/pci/trident/trident.c), rather than this,
> > > > which will be removed soon, I guess. And, additionally, could you change that
> > > > lines to use PCI_DEVICE macro?
> > >
> > > This driver is not up for removal soon, as it supports a device that
> > > the alsa driver apparently doesn't (the INTERG_5050).
> >
> > When were you going to report this?
>
> I already reported this as ALSA bug #1293.
>
> The problem is the lack of a tester, and I'm currently inclined to
> schedule this driver for removal although this PCI ID is still missing -
> either noone is using these settop boxes anymore or someone will
> volunteer to test patches.
Hmm, yeah, if the hardware was only used in set top boxes there's not a
lot that can be done, unless someone wants to donate one to the ALSA
project.
It might be as simple as adding the PCI IDs to the driver.
Lee
This revised version of the OSS Trident patch includes PCI_DEVICE Macro
usage.
Thanks,
Jon
Signed-off-by: Jon Mason <[email protected]>
diff -r 4a7597b41d25 sound/oss/trident.c
--- a/sound/oss/trident.c Wed Jan 11 19:14:08 2006
+++ b/sound/oss/trident.c Thu Jan 12 15:33:02 2006
@@ -278,16 +278,14 @@
};
static struct pci_device_id trident_pci_tbl[] = {
- {PCI_VENDOR_ID_TRIDENT, PCI_DEVICE_ID_TRIDENT_4DWAVE_DX,
- PCI_ANY_ID, PCI_ANY_ID, 0, 0, TRIDENT_4D_DX},
- {PCI_VENDOR_ID_TRIDENT, PCI_DEVICE_ID_TRIDENT_4DWAVE_NX,
- PCI_ANY_ID, PCI_ANY_ID, 0, 0, TRIDENT_4D_NX},
- {PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_7018,
- PCI_ANY_ID, PCI_ANY_ID, 0, 0, SIS_7018},
- {PCI_VENDOR_ID_ALI, PCI_DEVICE_ID_ALI_5451,
- PCI_ANY_ID, PCI_ANY_ID, 0, 0, ALI_5451},
- {PCI_VENDOR_ID_INTERG, PCI_DEVICE_ID_INTERG_5050,
- PCI_ANY_ID, PCI_ANY_ID, 0, 0, CYBER5050},
+ {PCI_DEVICE(PCI_VENDOR_ID_TRIDENT, PCI_DEVICE_ID_TRIDENT_4DWAVE_DX),
+ PCI_CLASS_MULTIMEDIA_AUDIO << 8, 0xffff00, TRIDENT_4D_DX},
+ {PCI_DEVICE(PCI_VENDOR_ID_TRIDENT, PCI_DEVICE_ID_TRIDENT_4DWAVE_NX),
+ 0, 0, TRIDENT_4D_NX},
+ {PCI_DEVICE(PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_7018), 0, 0, SIS_7018},
+ {PCI_DEVICE(PCI_VENDOR_ID_ALI, PCI_DEVICE_ID_ALI_5451), 0, 0, ALI_5451},
+ {PCI_DEVICE(PCI_VENDOR_ID_INTERG, PCI_DEVICE_ID_INTERG_5050),
+ 0, 0, CYBER5050},
{0,}
};
>> After looking at the ALSA driver, it doesn't support PCI IDs for
>> ALI_5451 or CYBER5050. Someone should look into porting any necessary
>> code from sound/oss/trident.c to sound/pci/trident/trident.c
>
>CYBER5050 is discussed in ALSA bug #1293 (tester wanted).
>ALI_5451 is supported by the snd-ali5451 driver.
And I have a (working) ALI 5451; for whoever wants to know that.
Jan Engelhardt
--
On Thu, Jan 12, 2006 at 05:06:53PM -0500, Lee Revell wrote:
> On Thu, 2006-01-12 at 22:58 +0100, Adrian Bunk wrote:
> > On Thu, Jan 12, 2006 at 04:15:38PM -0500, Lee Revell wrote:
> > > On Thu, 2006-01-12 at 22:07 +0200, Muli Ben-Yehuda wrote:
> > > > On Thu, Jan 12, 2006 at 08:28:30PM +0100, Jiri Slaby wrote:
> > > >
> > > > > You should change alsa driver (sound/pci/trident/trident.c), rather than this,
> > > > > which will be removed soon, I guess. And, additionally, could you change that
> > > > > lines to use PCI_DEVICE macro?
> > > >
> > > > This driver is not up for removal soon, as it supports a device that
> > > > the alsa driver apparently doesn't (the INTERG_5050).
> > >
> > > When were you going to report this?
> >
> > I already reported this as ALSA bug #1293.
> >
> > The problem is the lack of a tester, and I'm currently inclined to
> > schedule this driver for removal although this PCI ID is still missing -
> > either noone is using these settop boxes anymore or someone will
> > volunteer to test patches.
>
> Hmm, yeah, if the hardware was only used in set top boxes there's not a
> lot that can be done, unless someone wants to donate one to the ALSA
> project.
>
> It might be as simple as adding the PCI IDs to the driver.
I agree, add the IDs to the ALSA driver and if someone using a
INTERG_5050 adapter has problems....instant tester.
On Thu, Jan 12, 2006 at 11:00:39PM +0100, Adrian Bunk wrote:
> On Thu, Jan 12, 2006 at 03:47:19PM -0600, Jon Mason wrote:
> > On Thu, Jan 12, 2006 at 10:07:35PM +0200, Muli Ben-Yehuda wrote:
> > > On Thu, Jan 12, 2006 at 08:28:30PM +0100, Jiri Slaby wrote:
> > >
> > > > You should change alsa driver (sound/pci/trident/trident.c), rather than this,
> > > > which will be removed soon, I guess. And, additionally, could you change that
> > > > lines to use PCI_DEVICE macro?
> > >
> > > This driver is not up for removal soon, as it supports a device that
> > > the alsa driver apparently doesn't (the INTERG_5050). As for
> > > PCI_DEVICE, agreed. Jon, feel like patching it up?
> >
> > Patches to follow.
> >
> > After looking at the ALSA driver, it doesn't support PCI IDs for
> > ALI_5451 or CYBER5050. Someone should look into porting any necessary
> > code from sound/oss/trident.c to sound/pci/trident/trident.c
>
> CYBER5050 is discussed in ALSA bug #1293 (tester wanted).
> ALI_5451 is supported by the snd-ali5451 driver.
Sorry, I grepped for PCI_DEVICE_ID_ALI_5451 not 0x5451. Sending a patch
to fix that up too.
Thanks,
Jon
There are just a few differences between the 2.4 (1.30h) version of
pcnet32.c and the 2.6 (1.30j) version, as I have tried to keep them
as similar as possible.
The driver was changed in February 2004 to recognize the incorrect
vendor ID so that the ppc workaround was no longer required, and so that
the cards would work in non ppc systems. From the driver perspective
the ppc workaround could be deleted.
On my systems lspci shows all the devices with the correct name whether
it is ppc or x86.
PPC:
donf@elm3b48:/usr/src> lspci | grep Ethernet
0000:01:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 54)
0000:21:01.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 0d)
0000:62:00.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
0000:62:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
0000:62:02.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
0000:62:03.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
0001:21:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 44)
0001:31:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
0001:41:01.0 Ethernet controller: Intel Corporation 82545EM Gigabit Ethernet Controller (Copper) (rev 01)
0001:61:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c978 [HomePNA] (rev 51)
donf@elm3b48:/usr/src>
x86:
[donf@elm3b45 linux-2.6.14-git11]$ lspci | grep Ethernet
00:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 54)
00:05.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 44)
02:05.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 16)
02:06.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 36)
05:02.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 44)
05:03.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 54)
05:04.0 Ethernet controller: Advanced Micro Devices [AMD] 79c978 [HomePNA] (rev 51)
[donf@elm3b45 linux-2.6.14-git11]$
On Thu, Jan 12, 2006 at 04:24:35PM -0500, Bill Nottingham wrote:
> Bill Nottingham ([email protected]) said:
> > I remember looking at this a while back. I think the corrected information
> > is only being propagated to the 'vendor' file, and the write_config_word
> > isn't actually updating the 'config' entry in sysfs.
>
> Ah, here's an example from the box I remember working on this on
> (without the libpci change):
>
> root@pseries 0000:00:0c.0]# pwd
> /sys/bus/pci/devices/0000:00:0c.0
> [root@pseries 0000:00:0c.0]# lspci | grep 0c.0
> 00:0c.0 Ethernet controller: Trident Microsystems 4DWave DX (rev 26)
> [root@pseries 0000:00:0c.0]# lspci -n | grep 0c.0
> 00:0c.0 Class 0200: 1023:2000 (rev 26)
> [root@pseries 0000:00:0c.0]# cat vendor
> 0x1022
> [root@pseries 0000:00:0c.0]# cat device
> 0x2000
> [root@pseries 0000:00:0c.0]# od -x config
> 0000000 2310 0020 4701 8002 2600 0002 0048 0000
> 0000020 01f0 ff00 0070 21c3 0000 0000 0000 0000
> 0000040 0000 0000 0000 0000 0000 0000 0000 0000
> 0000060 0000 10c3 0000 0000 0000 0000 1101 06ff
> 0000100 0000 0000 0000 0000 0000 0000 0000 0000
> *
> 0000400
>
> Note that the config space is different than the vendor file. This
> was with 2.6.9-ish, I don't have the box around any more to confirm
> with something more recent.
>
> Bill
--
Don Fry
[email protected]
On Thu, Jan 12, 2006 at 02:23:20PM -0800, Don Fry wrote:
> There are just a few differences between the 2.4 (1.30h) version of
> pcnet32.c and the 2.6 (1.30j) version, as I have tried to keep them
> as similar as possible.
>
> The driver was changed in February 2004 to recognize the incorrect
> vendor ID so that the ppc workaround was no longer required, and so that
> the cards would work in non ppc systems. From the driver perspective
> the ppc workaround could be deleted.
>
> On my systems lspci shows all the devices with the correct name whether
> it is ppc or x86.
Funny, I get the following on my opteron system:
# lspci | grep Ethernet
0000:03:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5703X Gigabit Ethernet (rev 02)
0000:0e:01.0 Ethernet controller: Trident Microsystems 4DWave DX (rev 26)
>
> PPC:
> donf@elm3b48:/usr/src> lspci | grep Ethernet
> 0000:01:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 54)
> 0000:21:01.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 0d)
> 0000:62:00.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
> 0000:62:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
> 0000:62:02.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
> 0000:62:03.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
> 0001:21:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 44)
> 0001:31:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
> 0001:41:01.0 Ethernet controller: Intel Corporation 82545EM Gigabit Ethernet Controller (Copper) (rev 01)
> 0001:61:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c978 [HomePNA] (rev 51)
> donf@elm3b48:/usr/src>
>
> x86:
> [donf@elm3b45 linux-2.6.14-git11]$ lspci | grep Ethernet
> 00:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 54)
> 00:05.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 44)
> 02:05.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 16)
> 02:06.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 36)
> 05:02.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 44)
> 05:03.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 54)
> 05:04.0 Ethernet controller: Advanced Micro Devices [AMD] 79c978 [HomePNA] (rev 51)
> [donf@elm3b45 linux-2.6.14-git11]$
>
> On Thu, Jan 12, 2006 at 04:24:35PM -0500, Bill Nottingham wrote:
> > Bill Nottingham ([email protected]) said:
> > > I remember looking at this a while back. I think the corrected information
> > > is only being propagated to the 'vendor' file, and the write_config_word
> > > isn't actually updating the 'config' entry in sysfs.
> >
> > Ah, here's an example from the box I remember working on this on
> > (without the libpci change):
> >
> > root@pseries 0000:00:0c.0]# pwd
> > /sys/bus/pci/devices/0000:00:0c.0
> > [root@pseries 0000:00:0c.0]# lspci | grep 0c.0
> > 00:0c.0 Ethernet controller: Trident Microsystems 4DWave DX (rev 26)
> > [root@pseries 0000:00:0c.0]# lspci -n | grep 0c.0
> > 00:0c.0 Class 0200: 1023:2000 (rev 26)
> > [root@pseries 0000:00:0c.0]# cat vendor
> > 0x1022
> > [root@pseries 0000:00:0c.0]# cat device
> > 0x2000
> > [root@pseries 0000:00:0c.0]# od -x config
> > 0000000 2310 0020 4701 8002 2600 0002 0048 0000
> > 0000020 01f0 ff00 0070 21c3 0000 0000 0000 0000
> > 0000040 0000 0000 0000 0000 0000 0000 0000 0000
> > 0000060 0000 10c3 0000 0000 0000 0000 1101 06ff
> > 0000100 0000 0000 0000 0000 0000 0000 0000 0000
> > *
> > 0000400
> >
> > Note that the config space is different than the vendor file. This
> > was with 2.6.9-ish, I don't have the box around any more to confirm
> > with something more recent.
> >
> > Bill
> --
> Don Fry
> [email protected]
>
On Thu, 2006-01-12 at 23:00 +0100, Adrian Bunk wrote:
> CYBER5050 is discussed in ALSA bug #1293 (tester wanted).
OK I set that bug to FEEDBACK, but it's open 5 months now and no testers
are forthcoming. I think if we don't find one as a result of this
thread we can assume no one cares about this hardware anymore.
I'm still not sure that just adding it to the ALSA driver and hoping it
works is the best solution. Would we rather users see right away that
their hardware isn't supported, or have the driver load and get no sound
or hang the machine?
I think the best approach might just be to drop it in lieu of a tester.
It will be trivial to add support later if someone finds one of these
boxes.
Lee
On Thu, Jan 12, 2006 at 05:06:53PM -0500, Lee Revell wrote:
> On Thu, 2006-01-12 at 22:58 +0100, Adrian Bunk wrote:
> > On Thu, Jan 12, 2006 at 04:15:38PM -0500, Lee Revell wrote:
> > > On Thu, 2006-01-12 at 22:07 +0200, Muli Ben-Yehuda wrote:
> > > > On Thu, Jan 12, 2006 at 08:28:30PM +0100, Jiri Slaby wrote:
> > > >
> > > > > You should change alsa driver (sound/pci/trident/trident.c), rather than this,
> > > > > which will be removed soon, I guess. And, additionally, could you change that
> > > > > lines to use PCI_DEVICE macro?
> > > >
> > > > This driver is not up for removal soon, as it supports a device that
> > > > the alsa driver apparently doesn't (the INTERG_5050).
> > >
> > > When were you going to report this?
> >
> > I already reported this as ALSA bug #1293.
> >
> > The problem is the lack of a tester, and I'm currently inclined to
> > schedule this driver for removal although this PCI ID is still missing -
> > either noone is using these settop boxes anymore or someone will
> > volunteer to test patches.
>
> Hmm, yeah, if the hardware was only used in set top boxes there's not a
> lot that can be done, unless someone wants to donate one to the ALSA
> project.
>
> It might be as simple as adding the PCI IDs to the driver.
To the snd-trident ALSA driver or to the snd-ali5451 ALSA driver?
Seriously, if it would be _that_ trivial, I'd have sent such a patch
instead of opening the ALSA bug.
There's a serious amount of 5050 specific code in the OSS driver, and
I'd therefore prefer "unsopported in ALSA" over "blindly adding PCI ID
and most likely non-working".
> Lee
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
On Thu, Jan 12, 2006 at 05:42:10PM -0500, Lee Revell wrote:
> On Thu, 2006-01-12 at 23:00 +0100, Adrian Bunk wrote:
> > CYBER5050 is discussed in ALSA bug #1293 (tester wanted).
>
> OK I set that bug to FEEDBACK, but it's open 5 months now and no testers
> are forthcoming. I think if we don't find one as a result of this
> thread we can assume no one cares about this hardware anymore.
The majority of Linux users doesn't read linux-kernel...
We might find users after the OSS driver is deprecated in a released
kernel, or perhaps some months after it's removed from the kernel.
This would match my current experiences regarding my suggested removal
of some OSS drivers.
> I'm still not sure that just adding it to the ALSA driver and hoping it
> works is the best solution. Would we rather users see right away that
> their hardware isn't supported, or have the driver load and get no sound
> or hang the machine?
>
> I think the best approach might just be to drop it in lieu of a tester.
> It will be trivial to add support later if someone finds one of these
> boxes.
Agreed.
> Lee
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
On Thu, 2006-01-12 at 23:52 +0100, Adrian Bunk wrote:
> > I'm still not sure that just adding it to the ALSA driver and hoping it
> > works is the best solution. Would we rather users see right away that
> > their hardware isn't supported, or have the driver load and get no sound
> > or hang the machine?
> >
> > I think the best approach might just be to drop it in lieu of a tester.
> > It will be trivial to add support later if someone finds one of these
> > boxes.
>
> Agreed.
>
OK I'm just going to close that bug, the one person who seemed to know
anything about it had this to say:
"The cyberpro 5050 is an old combined video+audio controller - and
is/was used in some settop boxes (German Siemens Activity and also
Loewe).
There will be no "desktop users" around.
And because I don't work for Loewe anymore: I don't have access to
hardware.
If you ask me: leave it out!"
Anyone who finds one of these is free to reopen it.
Lee
On Thu, 2006-01-12 at 23:52 +0100, Adrian Bunk wrote:
> On Thu, Jan 12, 2006 at 05:42:10PM -0500, Lee Revell wrote:
> > On Thu, 2006-01-12 at 23:00 +0100, Adrian Bunk wrote:
> > > CYBER5050 is discussed in ALSA bug #1293 (tester wanted).
> >
> > OK I set that bug to FEEDBACK, but it's open 5 months now and no
> testers
> > are forthcoming. I think if we don't find one as a result of this
> > thread we can assume no one cares about this hardware anymore.
>
> The majority of Linux users doesn't read linux-kernel...
>
> We might find users after the OSS driver is deprecated in a released
> kernel, or perhaps some months after it's removed from the kernel.
>
> This would match my current experiences regarding my suggested
> removal
> of some OSS drivers.
While we're on the topic, what *is* the best place to solicit hardware
donations for purposes of driver development?
I ask because the snd-nm256 driver is one that we know users have, but
the ALSA driver has never worked (sound OK but the machine frequently
locks up IIRC, see ALSA bug #305), and the device has been unavailable
for years. Basically these users are screwed if we can't get a hardware
sample, but I think that might mean someone has to give us a whole
laptop.
Lee
On 1/12/06, Lee Revell <[email protected]> wrote:
> I ask because the snd-nm256 driver is one that we know users have, but
> the ALSA driver has never worked (sound OK but the machine frequently
> locks up IIRC, see ALSA bug #305), and the device has been unavailable
> for years. Basically these users are screwed if we can't get a hardware
> sample, but I think that might mean someone has to give us a whole
> laptop.
I happen to have an old laptop with an nm256, that I would gladly part
with, but it doesn't boot because of a hardware problem: it will shut
itself off between 5 and 30 seconds of turning on. Last time I
checked it seemed to be a not-worth-fixing problem with a lot of VAIOs
of that generation. I doubt this is worth anything to anyone but if
it is, let me know.
-Bob
On Iau, 2006-01-12 at 17:55 -0500, Lee Revell wrote:
> "The cyberpro 5050 is an old combined video+audio controller - and
> is/was used in some settop boxes (German Siemens Activity and also
> Loewe).
>
> There will be no "desktop users" around.
The 5050 is used with some older geode systems. It uses the same core
(from T-squared I believe) as trident and the other vendors. Its not
very different to the 4DWAVE.
Alan
On Iau, 2006-01-12 at 17:42 -0500, Lee Revell wrote:
> OK I set that bug to FEEDBACK, but it's open 5 months now and no testers
> are forthcoming. I think if we don't find one as a result of this
> thread we can assume no one cares about this hardware anymore.
Nobody reads ALSA bugzilla. You are probably right but its not clear,
and if the audio is going the video component might as well go too.
Have you checked with the ARM people or the person who added support (
[email protected]) ?
It's also used in various appliances people "adjust" to run Linux - the
Philips AOL-TV for example. Also on the SH reference boards for the
hitachi sh series cpus (arch/sh*).
> I think the best approach might just be to drop it in lieu of a tester.
> It will be trivial to add support later if someone finds one of these
> boxes.
Think it should stay for now at least. Pointing at ALSA bugzilla as
proof of non-use is not a good test.
Alan
On Thu, Jan 12, 2006 at 05:42:10PM -0500, Lee Revell wrote:
> On Thu, 2006-01-12 at 23:00 +0100, Adrian Bunk wrote:
> > CYBER5050 is discussed in ALSA bug #1293 (tester wanted).
>
> OK I set that bug to FEEDBACK, but it's open 5 months now and no testers
> are forthcoming. I think if we don't find one as a result of this
> thread we can assume no one cares about this hardware anymore.
>
> I'm still not sure that just adding it to the ALSA driver and hoping it
> works is the best solution. Would we rather users see right away that
> their hardware isn't supported, or have the driver load and get no sound
> or hang the machine?
... or use the known working OSS driver?
> I think the best approach might just be to drop it in lieu of a tester.
> It will be trivial to add support later if someone finds one of these
> boxes.
So you advocate removing a known working driver in favor of a known
not to be working driver? nice.
Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/
On Fri, Jan 13, 2006 at 01:37:56PM +0200, Muli Ben-Yehuda wrote:
> On Thu, Jan 12, 2006 at 05:42:10PM -0500, Lee Revell wrote:
> > On Thu, 2006-01-12 at 23:00 +0100, Adrian Bunk wrote:
> > > CYBER5050 is discussed in ALSA bug #1293 (tester wanted).
> >
> > OK I set that bug to FEEDBACK, but it's open 5 months now and no testers
> > are forthcoming. I think if we don't find one as a result of this
> > thread we can assume no one cares about this hardware anymore.
> >
> > I'm still not sure that just adding it to the ALSA driver and hoping it
> > works is the best solution. Would we rather users see right away that
> > their hardware isn't supported, or have the driver load and get no sound
> > or hang the machine?
>
> ... or use the known working OSS driver?
>...
In my experience with scheduling OSS drivers for removal, users simply
use the OSS drivers unless you tell them very explicitely that the OSS
driver will go.
It shouldn't be too hard to port the support to ALSA if someone with the
hardware is willing to test patches.
The goal is to get people still using OSS drivers where ALSA drivers
support the same hardware to use the ALSA drivers - and if there were
bugs in the ALSA drivers preventing them to switch to ALSA, to report
them to the ALSA bug tracking system.
This has the following advantages:
- better ALSA drivers
- get rid of some unmaintained code in the kernel
> Cheers,
> Muli
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
On Fri, Jan 13, 2006 at 01:23:58PM +0100, Adrian Bunk wrote:
> In my experience with scheduling OSS drivers for removal, users simply
> use the OSS drivers unless you tell them very explicitely that the OSS
> driver will go.
If the OSS drivers satisfy them, what's wrong with it?
> It shouldn't be too hard to port the support to ALSA if someone with the
> hardware is willing to test patches.
Unfortunately, I have a different trident variant (the 5451).
> The goal is to get people still using OSS drivers where ALSA drivers
> support the same hardware to use the ALSA drivers - and if there were
> bugs in the ALSA drivers preventing them to switch to ALSA, to report
> them to the ALSA bug tracking system.
>
> This has the following advantages:
> - better ALSA drivers
This one is fine.
> - get rid of some unmaintained code in the kernel
This one is irrelevant for trident - I maintain it.
Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/
On Fri, Jan 13, 2006 at 02:32:15PM +0200, Muli Ben-Yehuda wrote:
> On Fri, Jan 13, 2006 at 01:23:58PM +0100, Adrian Bunk wrote:
>
> > In my experience with scheduling OSS drivers for removal, users simply
> > use the OSS drivers unless you tell them very explicitely that the OSS
> > driver will go.
>
> If the OSS drivers satisfy them, what's wrong with it?
>...
There are two drivers, each with it's own features and bugs.
Either the ALSA driver is better in any respect making the OSS driver
simply obsolete, or there are problems in the ALSA driver that should be
reported and fixed.
Removing the OSS driver forces users to report the problems with the
ALSA driver making the latter better for everyone.
> Cheers,
> Muli
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
On Fri, Jan 13, 2006 at 04:24:21PM +0100, Adrian Bunk wrote:
> Either the ALSA driver is better in any respect making the OSS driver
> simply obsolete, or there are problems in the ALSA driver that should be
> reported and fixed.
>
> Removing the OSS driver forces users to report the problems with the
> ALSA driver making the latter better for everyone.
Yeah, and rm -rf'ing ftp.kernel.org is a great way to make everyone
write a better operating system. Surely there's a less destructive way
to do things.
In any case, I think this thread has run its course and we can agree
to disagree now.
Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/
On Fri, 2006-01-13 at 10:28 +0000, Alan Cox wrote:
> Have you checked with the ARM people or the person who added support (
> [email protected]) ?
>
> It's also used in various appliances people "adjust" to run Linux - the
> Philips AOL-TV for example. Also on the SH reference boards for the
> hitachi sh series cpus (arch/sh*).
>
Yes he was the person I quoted in my previous message, who recommended
we drop it, but it looks like this device is more widely used than we
thought.
I agree that if there's any doubt then we should not remove code.
Lee