This kernel oops is totally reproducible (on every occasion) in 2.4.9,
2.4.10, and 2.4.12. I have not tried earlier kernels in the 2.4 series, but
have tried 2.2.19pre17 (will explain other SiS Chipset funny business in
another message). All kernels were compiled while the machine was running
2.2.19pre17.
The machine in question is a Clevo lp200t SiS630S "all-in-one" machine.
( http://www.clevo.com.tw/products/lp200t.asp - has some specs online ).
The SiS630S chipset contains an SiS7018, so the driver is correct. Machine
in question has a very 'sparse' BIOS, so there is little in the way I can
configure or change.
lspci shows the following:
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 630 Host (rev 31)
00:00.1 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0)
00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513
00:01.1 Ethernet controller: Silicon Integrated Systems [SiS] SiS900
10/100 Ethernet (rev 82)
00:01.2 USB Controller: Silicon Integrated Systems [SiS] 7001 (rev 07)
00:01.3 USB Controller: Silicon Integrated Systems [SiS] 7001 (rev 07)
00:01.4 Multimedia audio controller: Silicon Integrated Systems [SiS] SiS
PCI Audio Accelerator (rev 02)
00:01.6 Modem: Silicon Integrated Systems [SiS]: Unknown device 7013 (rev a0)
00:02.0 PCI bridge: Silicon Integrated Systems [SiS] 5591/5592 AGP
00:0c.0 CardBus bridge: Texas Instruments PCI1420
00:0c.1 CardBus bridge: Texas Instruments PCI1420
00:0d.0 FireWire (IEEE 1394): Texas Instruments: Unknown device 8020
01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS]
SiS630 GUI Accelerator+3D (rev 31)
Taken from /proc/pci - the two devices that share the same IRQ.
Bus 0, device 12, function 1:
CardBus bridge: Texas Instruments PCI1420 (#2) (rev 0).
IRQ 5.
Bus 0, device 1, function 4:
Multimedia audio controller: Silicon Integrated Systems [SiS] SiS PCI
Audio
Accelerator (rev 2).
IRQ 5.
Master Capable. Latency=128. Min Gnt=2.Max Lat=24.
I/O at 0x1000 [0x10ff].
Non-prefetchable 32 bit memory at 0x34003000 [0x34003fff].
The Yenta driver (afaik) is using the Cardbus, and the cardbus interface
works fine.
Loading the driver (eg: 'modprobe trident') results in the oops, and the
driver itself stuck in initializing (as reported using lsmod). Trying to
remove the driver fails, and system has to be rebooted (usually by manually
sync'ing disks, mounting R/O, and then rebooting, all using Alt-SysRq
methods, otherwise it hangs trying to bring down ethernet, which is an SiS900).
Output taken from syslog kernel debug output, contact me if you need
more/different output.
kernel: Trident 4DWave/SiS 7018/ALi 5451,Tvia CyberPro 5050 PCI Audio,
version 0.14.9c, 10:46:08 Oct 23 2001
kernel: PCI: Found IRQ 5 for device 00:01.4
kernel: PCI: Sharing IRQ 5 with 00:0c.1
kernel: trident: SiS 7018 PCI Audio found at IO 0x1000, IRQ 5
kernel: ac97_codec: AC97 codec, id: 0x0000:0x0000 (Unknown)
kernel: Unable to handle kernel NULL pointer dereference at virtual
address 00000000
kernel: printing eip:
kernel: cf828db6
kernel: *pde = 00000000
kernel: Oops: 0000
kernel: CPU: 0
kernel: EIP: 0010:[<cf828db6>] Not tainted
kernel: EFLAGS: 00010297
kernel: eax: 00000000 ebx: cef2e680 ecx: 02000040 edx: 00001044
kernel: esi: 000001f8 edi: 0000002a ebp: 00000000 esp: cdce9e6c
kernel: ds: 0018 es: 0018 ss: 0018
kernel: Process modprobe (pid: 225, stackpage=cdce9000)
kernel: Stack: cef2e680 000001f8 0000002a cf828d1c cef2e680 cf829fc0
cf829cad 00000000
kernel: 00000000 cf829faa 02000000 00000000 cef2e680 ce610000
00000000 00000000
kernel: cf830d7c cef2e680 cf832040 cefe1c00 ce610000 00000000
cef2e680 cf83120c
kernel: Call Trace: [<cf828d1c>] [<cf829fc0>] [<cf829cad>] [<cf829faa>]
[<cf830d7c>]
kernel: [<cf832040>] [<cf83120c>] [<cf83126b>] [<cf83208c>]
[<cf832220>] [pci_announce_device+54/84]
kernel: [<cf83208c>] [<cf832220>] [pci_register_driver+72/96]
[<cf832220>] [<cf83145b>] [<cf832220>]
kernel: [<cf831d60>] [sys_init_module+1285/1448] [<cf82c060>]
[system_call+51/56]
kernel:
kernel: Code: 83 38 00 74 08 53 8b 00 ff d0 83 c4 04 31 ff ba 20 a3 82 cf
AMC Enterprises P/L - Stuart Young
First Floor - Network and Systems Admin
3 Chesterville Rd - [email protected]
Cheltenham Vic 3192 - Ph: (03) 9584-2700
http://www.amc.com.au/ - Fax: (03) 9584-2755
> This kernel oops is totally reproducible (on every occasion) in 2.4.9,
> 2.4.10, and 2.4.12. I have not tried earlier kernels in the 2.4 series, but
> have tried 2.2.19pre17 (will explain other SiS Chipset funny business in
> another message). All kernels were compiled while the machine was running
> 2.2.19pre17.
Does this problem go away if you build the driver modular. Im wondering
if it matches another mysterious and similar report
At 05:19 PM 23/10/01 +0100, Alan Cox wrote:
> > This kernel oops is totally reproducible (on every occasion) in 2.4.9,
> > 2.4.10, and 2.4.12. I have not tried earlier kernels in the 2.4 series,
> > but have tried 2.2.19pre17 (will explain other SiS Chipset funny business
> > in another message). All kernels were compiled while the machine was
> > running 2.2.19pre17.
>
>Does this problem go away if you build the driver modular. Im wondering
>if it matches another mysterious and similar report
I've built the trident driver as a module, and tried the sound support as
both a module and in-line, with the same results.
Haven't tried the trident driver and sound support in-line together. I'll
give this a try and see if there is any difference, or wether my machine
just oops's at boot.
Stuart Young - [email protected]
(aka Cefiar) - [email protected]
[All opinions expressed in the above message are my]
[own and not necessarily the views of my employer..]
I have a very similar OOPS that I reported to linux-kernel just last
week: see full details at
http://uwsg.iu.edu/hypermail/linux/kernel/0110.1/1690.html
> This kernel oops is totally reproducible (on every occasion) in 2.4.9,
> 2.4.10, and 2.4.12. I have not tried earlier kernels in the 2.4
> series
I also have a totally reproduceable OOPS on 2.4.9 through 2.4.12.
Kernel 2.4.7 works just fine. If the soundcard is compiled in to the
kernel, it dies while booting. If it is compiled as a module, it dies
when attempting to load the module (typically when artsd starts).
> The machine in question is a Clevo lp200t SiS630S "all-in-one"
> machine.
My machine is an ECS K7AMA: ALi 1645 northbridge, ALi Magic 1535D+
southbridge. Sound is onboard the southbridge. I ran ksymoops on my
OOPS report, so you can see the trace at the message archive.
Mike Robbins
[email protected]
(Please also cc your reply to me.)
At 09:07 PM 24/10/01 -0400, Michael F. Robbins wrote:
>I also have a totally reproduceable OOPS on 2.4.9 through 2.4.12.
>Kernel 2.4.7 works just fine. If the soundcard is compiled in to the
>kernel, it dies while booting. If it is compiled as a module, it dies
>when attempting to load the module (typically when artsd starts).
I just tried 2.4.7, and while the module loads, the ac97_codec gives an
"unknown id" response, and I get no sound out of the device whatsoever. Any
writes to /dev/dsp just hang (not the kernel) and I get nothing out of the
device.
I might try compiling the 2.4.7 trident module without symbol versions, and
a 2.4.9 kernel the same, and try forcibly inmod'ing the 2.4.7 trident
module on 2.4.9 and see what happens.
AMC Enterprises P/L - Stuart Young
First Floor - Network and Systems Admin
3 Chesterville Rd - [email protected]
Cheltenham Vic 3192 - Ph: (03) 9584-2700
http://www.amc.com.au/ - Fax: (03) 9584-2755
More on this kernel oops with the SiS/Trident 4DWave driver.
Went and compiled 2.4.9 and 2.4.7 without module symbol versions, and tried
the trident module from 2.4.7 in 2.4.9. Exactly the same oops that happened
with the 2.4.9 module, so it may not explicitly be the driver, but
something it relies on, like the ac97_codec.
When I used insmod, it only complained about the kernel revisions, and
nothing about symbols, so I'm guessing the interface didn't change much, if
at all, so I used the -f option to force a load, producing an oops.
Interestingly enough, with 2.4.9. and 2.4.9 loading the 2.4.7 trident
module, lsmod reports that while the trident driver is using ac97_codec,
ac97_codec has 0 modules using it.
eg: (hand typed, but accurate)
trident 24448 1 (initializing)
soundcore 3812 1 [trident]
ac97_codec 8864 0 [trident]
Hope this helps.
AMC Enterprises P/L - Stuart Young
First Floor - Network and Systems Admin
3 Chesterville Rd - [email protected]
Cheltenham Vic 3192 - Ph: (03) 9584-2700
http://www.amc.com.au/ - Fax: (03) 9584-2755
I just grabbed 2.4.12-ac6 and the OOPS continues. This is with
soundcore, ac97_codec, and trident all built as modules.
Again, like my previous report (which was on Linus' 2.4.12), I can
'modprobe soundcore' and 'modprobe ac97_codec' with no problems. Once I
do the 'modprobe trident', I get the oops. After the oops, the system
is still responsive, and just like Stuart Young reported, the trident
module is stuck in "initalizing".
See below for the details including the oops report itself.
Mike Robbins
[email protected]
(Please also cc your reply to me.)
`cat /proc/modules` after the oops:
-----------
trident 26800 (initializing)
ac97_codec 9120 0 [trident]
soundcore 3568 2 [trident]
NVdriver 713104 17
8139too 12896 1 (autoclean)
-----------
Relevant part of /proc/pci:
----------
Bus 0, device 3, function 0:
Multimedia audio controller: PCI device 10b9:5451 (Acer Laboratories
Inc. [ALi]) (rev 2).
IRQ 10.
Master Capable. Latency=64. Min Gnt=2.Max Lat=24.
I/O at 0xc400 [0xc4ff].
Non-prefetchable 32 bit memory at 0xdfffe000 [0xdfffefff].
----------
Part of /proc/iomem:
dfffe000-dfffefff : PCI device 10b9:5451 (Acer Laboratories Inc. [ALi])
Part of /proc/ioports:
c400-c4ff : PCI device 10b9:5451 (Acer Laboratories Inc. [ALi])
SYSLOG LEADING UP TO OOPS:
(`modprobe trident` executed here, and this is the result:)
----------
Oct 25 08:35:55 tbird kernel: Trident 4DWave/SiS 7018/ALi 5451,Tvia
CyberPro 5050 PCI Audio, version 0.14.9d, 08:28:09 Oct 25 2001
Oct 25 08:35:55 tbird kernel: PCI: Assigned IRQ 10 for device 00:03.0
Oct 25 08:35:55 tbird kernel: trident: ALi Audio Accelerator found at IO
0xc400, IRQ 10
Oct 25 08:35:55 tbird kernel: ac97_codec: AC97 Audio codec, id:
0x414c:0x4326 (Unknown)
Oct 25 08:35:55 tbird kernel: ali: AC97 CODEC read timed out.
Oct 25 08:35:55 tbird kernel: ali: AC97 CODEC write timed out.
Oct 25 08:35:55 tbird kernel: ali: AC97 CODEC read timed out.
Oct 25 08:35:55 tbird last message repeated 2 times
Oct 25 08:35:55 tbird kernel: ac97_codec: AC97 codec, id: 0x0000:0x0000
(Unknown)
Oct 25 08:35:55 tbird kernel: ali: AC97 CODEC read timed out.
Oct 25 08:35:55 tbird kernel: ali: AC97 CODEC write timed out.
Oct 25 08:35:55 tbird kernel: ali: AC97 CODEC read timed out.
Oct 25 08:35:55 tbird kernel: Unable to handle kernel NULL pointer
dereference at virtual address 00000000
---------- (the rest of the oops follows this)
KSYMOOPS REPORT:
-----------
Unable to handle kernel NULL pointer dereference at virtual address
00000000
e5991d7e
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<e5991d7e>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010206
eax: 00000000 ebx: dc4c7cc0 ecx: df408000 edx: 00000006
esi: 00000000 edi: dc4c7d70 ebp: 00000001 esp: dcd01e98
ds: 0018 es: 0018 ss: 0018
Process modprobe (pid: 885, stackpage=dcd01000)
Stack: dc4c7cc0 02000000 dc4c7d70 00000001 e5999fcb dc4c7cc0 00000024
00000003
dee5c000 dfff5000 e599b120 dfff6400 e599a410 dee5c000 ffffffed
0000c400
02000000 e599b068 e599b1e0 dfff6400 00000000 c01b22a4 dfff6400
e599b068
Call Trace: [<e5999fcb>] [<e599b120>] [<e599a410>] [<e599b068>]
[<e599b1e0>]
[<c01b22a4>] [<e599b068>] [<e599b1e0>] [<c01b2302>] [<e599b1e0>]
[<e599a634>]
[<e599b1e0>] [<e599aee0>] [sys_init_module+1317/1504] [<e599b860>]
[<e5995060>] [system_call+51/56]
[<e599b1e0>] [<e599aee0>] [<c01142c5>] [<e599b860>] [<e5995060>]
[<c0106ecb>]
Code: 8b 00 85 c0 74 04 53 ff d0 5a 31 ed 83 3d e0 31 99 e5 ff ba
>>EIP; e5991d7e <[ac97_codec]ac97_init_mixer+7e/e0> <=====
Trace; e5999fcb <[trident]trident_ac97_init+22b/2f0>
Trace; e599b120 <[trident]trident_audio_fops+0/60>
Trace; e599a410 <[trident]trident_probe+380/4a0>
Trace; e599b068 <[trident]trident_pci_tbl+54/a8>
Trace; e599b1e0 <[trident]trident_pci_driver+0/3f>
Trace; c01b22a4 <pci_announce_device+34/50>
Trace; e599b068 <[trident]trident_pci_tbl+54/a8>
Trace; e599b1e0 <[trident]trident_pci_driver+0/3f>
Trace; c01b2302 <pci_register_driver+42/60>
Trace; e599b1e0 <[trident]trident_pci_driver+0/3f>
Trace; e599a634 <[trident]trident_init_module+24/50>
Trace; e599b1e0 <[trident]trident_pci_driver+0/3f>
Trace; e599aee0 <[trident]__module_pci_device_size+614/693>
Trace; e599b1e0 <[trident]trident_pci_driver+0/3f>
Trace; e599aee0 <[trident]__module_pci_device_size+614/693>
Trace; c01142c5 <sys_init_module+525/5e0>
Trace; e599b860 <.bss.end+1/????>
Trace; e5995060 <[trident]trident_enable_loop_interrupts+0/80>
Trace; c0106ecb <system_call+33/38>
Code; e5991d7e <[ac97_codec]ac97_init_mixer+7e/e0>
00000000 <_EIP>:
Code; e5991d7e <[ac97_codec]ac97_init_mixer+7e/e0> <=====
0: 8b 00 mov (%eax),%eax <=====
Code; e5991d80 <[ac97_codec]ac97_init_mixer+80/e0>
2: 85 c0 test %eax,%eax
Code; e5991d82 <[ac97_codec]ac97_init_mixer+82/e0>
4: 74 04 je a <_EIP+0xa> e5991d88
<[ac97_codec]ac97_init_mixer+88/e0>
Code; e5991d84 <[ac97_codec]ac97_init_mixer+84/e0>
6: 53 push %ebx
Code; e5991d85 <[ac97_codec]ac97_init_mixer+85/e0>
7: ff d0 call *%eax
Code; e5991d87 <[ac97_codec]ac97_init_mixer+87/e0>
9: 5a pop %edx
Code; e5991d88 <[ac97_codec]ac97_init_mixer+88/e0>
a: 31 ed xor %ebp,%ebp
Code; e5991d8a <[ac97_codec]ac97_init_mixer+8a/e0>
c: 83 3d e0 31 99 e5 ff cmpl $0xffffffff,0xe59931e0
Code; e5991d91 <[ac97_codec]ac97_init_mixer+91/e0>
13: ba 00 00 00 00 mov $0x0,%edx
----------
Hello,
At 25 Oct 2001 09:24:21 -0400,
Michael F. Robbins <[email protected]> wrote:
>
> I just grabbed 2.4.12-ac6 and the OOPS continues. This is with
> soundcore, ac97_codec, and trident all built as modules.
>
> Again, like my previous report (which was on Linus' 2.4.12), I can
> 'modprobe soundcore' and 'modprobe ac97_codec' with no problems. Once I
> do the 'modprobe trident', I get the oops. After the oops, the system
> is still responsive, and just like Stuart Young reported, the trident
> module is stuck in "initalizing".
>
> See below for the details including the oops report itself.
>
> Mike Robbins
> [email protected]
> (Please also cc your reply to me.)
Following patch may fix your oops. Please try.
diff -u -r linux-2.4.12-ac5.org/drivers/sound/ac97_codec.c linux-2.4.12-ac5/drivers/sound/ac97_codec.c
--- linux-2.4.12-ac5.org/drivers/sound/ac97_codec.c Mon Oct 22 09:34:21 2001
+++ linux-2.4.12-ac5/drivers/sound/ac97_codec.c Fri Oct 26 10:26:41 2001
@@ -143,7 +143,6 @@
{0x83847656, "SigmaTel STAC9756/57", &sigmatel_9744_ops},
{0x83847684, "SigmaTel STAC9783/84?", &null_ops},
{0x57454301, "Winbond 83971D", &null_ops},
- {0,}
};
static const char *ac97_stereo_enhancements[] =
On Thu, 2001-10-25 at 21:37, Tachino Nobuhiro wrote:
> Following patch may fix your oops. Please try.
Hm, I don't think so. The last area is marked zero so code can know
when it ends. This is common practice.
> diff -u -r linux-2.4.12-ac5.org/drivers/sound/ac97_codec.c linux-2.4.12-ac5/drivers/sound/ac97_codec.c
> --- linux-2.4.12-ac5.org/drivers/sound/ac97_codec.c Mon Oct 22 09:34:21 2001
> +++ linux-2.4.12-ac5/drivers/sound/ac97_codec.c Fri Oct 26 10:26:41 2001
> @@ -143,7 +143,6 @@
> {0x83847656, "SigmaTel STAC9756/57", &sigmatel_9744_ops},
> {0x83847684, "SigmaTel STAC9783/84?", &null_ops},
> {0x57454301, "Winbond 83971D", &null_ops},
> - {0,}
> };
>
> static const char *ac97_stereo_enhancements[] =
Robert Love
Hello,
At 25 Oct 2001 21:45:58 -0400,
Robert Love wrote:
>
> On Thu, 2001-10-25 at 21:37, Tachino Nobuhiro wrote:
> > Following patch may fix your oops. Please try.
>
> Hm, I don't think so. The last area is marked zero so code can know
> when it ends. This is common practice.
But the code does not use the last area. this is the code in
ac97_probe_codec().
id1 = codec->codec_read(codec, AC97_VENDOR_ID1);
id2 = codec->codec_read(codec, AC97_VENDOR_ID2);
for (i = 0; i < ARRAY_SIZE(ac97_codec_ids); i++) {
if (ac97_codec_ids[i].id == ((id1 << 16) | id2)) {
codec->type = ac97_codec_ids[i].id;
codec->name = ac97_codec_ids[i].name;
codec->codec_ops = ac97_codec_ids[i].ops;
break;
}
}
If id1 and id2 happen to be 0, it matches the last entry and codec_ops
is set to uncertain value(maybe 0). it may cause the oops in ac97_init_mixer().
On Thu, 2001-10-25 at 21:56, Tachino Nobuhiro wrote:
> Robert Love wrote:
> > Hm, I don't think so. The last area is marked zero so code can know
> > when it ends. This is common practice.
>
> But the code does not use the last area. this is the code in
> ac97_probe_codec().
ARRAY_SIZE(x) returns the number of elements in x, but since everything
is 0-referenced going from 0 to i < ARRAY_SIZE isn't a problem.
ie int x[3];
ARRAY_SIZE(x) = 3;
but x[2] is last element... so no issue here.
> id1 = codec->codec_read(codec, AC97_VENDOR_ID1);
> id2 = codec->codec_read(codec, AC97_VENDOR_ID2);
> for (i = 0; i < ARRAY_SIZE(ac97_codec_ids); i++) {
> if (ac97_codec_ids[i].id == ((id1 << 16) | id2)) {
> codec->type = ac97_codec_ids[i].id;
> codec->name = ac97_codec_ids[i].name;
> codec->codec_ops = ac97_codec_ids[i].ops;
> break;
> }
> }
>
> If id1 and id2 happen to be 0, it matches the last entry and codec_ops
> is set to uncertain value(maybe 0). it may cause the oops in ac97_init_mixer().
Robert Love
At 25 Oct 2001 22:02:20 -0400,
Robert Love wrote:
>
> On Thu, 2001-10-25 at 21:56, Tachino Nobuhiro wrote:
> > Robert Love wrote:
> > > Hm, I don't think so. The last area is marked zero so code can know
> > > when it ends. This is common practice.
> >
> > But the code does not use the last area. this is the code in
> > ac97_probe_codec().
>
> ARRAY_SIZE(x) returns the number of elements in x, but since everything
> is 0-referenced going from 0 to i < ARRAY_SIZE isn't a problem.
>
> ie int x[3];
> ARRAY_SIZE(x) = 3;
> but x[2] is last element... so no issue here.
No. {0, } is the last elemnet of ac97_codec_ids[] and that index is
ARRAY_SIZE(ac97_code_ids) - 1. So this element which should be used as
a loop terminator is used as a valid entry in for loop incorrectly.
Please read ac97_codec.c
On Thu, 2001-10-25 at 22:36, Tachino Nobuhiro wrote:
> No. {0, } is the last elemnet of ac97_codec_ids[] and that index is
> ARRAY_SIZE(ac97_code_ids) - 1. So this element which should be used as
> a loop terminator is used as a valid entry in for loop incorrectly.
>
> Please read ac97_codec.c
You are right; I apologize.
Robert Love
On Thu, Oct 25, 2001 at 10:42:04PM -0400, Robert Love wrote:
> On Thu, 2001-10-25 at 22:36, Tachino Nobuhiro wrote:
> > No. {0, } is the last elemnet of ac97_codec_ids[] and that index is
> > ARRAY_SIZE(ac97_code_ids) - 1. So this element which should be used as
> > a loop terminator is used as a valid entry in for loop incorrectly.
> >
> > Please read ac97_codec.c
>
> You are right; I apologize.
I think the way this is coded stinks anyway. the {0,} should be used
as a loop-terminator, not ARRAY_SIZE(blaha) - 1. Yes, using 0-termination
wastes space. But it's cleaner and in line with what most other code
does.
/David Weinehall
_ _
// David Weinehall <[email protected]> /> Northern lights wander \\
// Project MCA Linux hacker // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
On Thu, 2001-10-25 at 23:13, David Weinehall wrote:
> I think the way this is coded stinks anyway. the {0,} should be used
> as a loop-terminator, not ARRAY_SIZE(blaha) - 1. Yes, using 0-termination
> wastes space. But it's cleaner and in line with what most other code
> does.
Agreed. Also, I didn't check if other ac97 code uses the {0,} as a
terminator. Removing it may break that.
The patch below accomplishes this.
However, now that I am actually looking at the code <g>, I don't see why
this would be a problem either way. Even though the loop reads the
"terminal" entry, it just checks whether it equals the specified id. It
is equal to 0 so I assume it never will...we aren't dereferencing it or
anything.
diff -u linux-2.4.12-ac6/drivers/sound/ac97_codec.c linux/drivers/sound/ac97_codec.c
--- linux-2.4.12-ac6/drivers/sound/ac97_codec.c Tue Oct 23 17:16:20 2001
+++ linux/drivers/sound/ac97_codec.c Thu Oct 25 23:21:02 2001
@@ -669,7 +669,7 @@
{
u16 id1, id2;
u16 audio, modem;
- int i;
+ int i = 0;
/* probing AC97 codec, AC97 2.0 says that bit 15 of register 0x00 (reset) should
* be read zero.
@@ -700,13 +700,14 @@
id1 = codec->codec_read(codec, AC97_VENDOR_ID1);
id2 = codec->codec_read(codec, AC97_VENDOR_ID2);
- for (i = 0; i < ARRAY_SIZE(ac97_codec_ids); i++) {
+ while(a97_codec_ids[i].id != 0) {
if (ac97_codec_ids[i].id == ((id1 << 16) | id2)) {
codec->type = ac97_codec_ids[i].id;
codec->name = ac97_codec_ids[i].name;
codec->codec_ops = ac97_codec_ids[i].ops;
break;
}
+ i++;
}
if (codec->name == NULL)
codec->name = "Unknown";
Robert Love
At 10:42 PM 25/10/01 -0400, Robert Love wrote:
>On Thu, 2001-10-25 at 22:36, Tachino Nobuhiro wrote:
> > No. {0, } is the last elemnet of ac97_codec_ids[] and that index is
> > ARRAY_SIZE(ac97_code_ids) - 1. So this element which should be used as
> > a loop terminator is used as a valid entry in for loop incorrectly.
> >
> > Please read ac97_codec.c
>
>You are right; I apologize.
Implemented the patch suggested, and the module no longer oops's, and I get
codec id's listed as 0x0000:0x0000 (Unknown). I still get no sound like I
did with 2.4.7 (using mpg123 as a test, with a known working mp3 file), and
output to the device is blocked (nothing gets written).
How can I find out the ac97 codec ID for this chipset (if there is one) so
it can be added to the ac97_codec_ids array? From what I can tell, it's as
though the codec->codec_read(codec, AC97_VENDOR_ID#) isn't returning the
codec value for this system at all.
Any suggestions?
AMC Enterprises P/L - Stuart Young
First Floor - Network and Systems Admin
3 Chesterville Rd - [email protected]
Cheltenham Vic 3192 - Ph: (03) 9584-2700
http://www.amc.com.au/ - Fax: (03) 9584-2755
> How can I find out the ac97 codec ID for this chipset (if there is one) so
> it can be added to the ac97_codec_ids array? From what I can tell, it's as
> though the codec->codec_read(codec, AC97_VENDOR_ID#) isn't returning the
> codec value for this system at all.
Something is failing to bring up the AC97 codec bus and/or set it up
properly. Can you find exactly which patch broke that for you (you'll
possibly want to keep fixing the codec table as you test older ones)
On Fri, 2001-10-26 at 10:36, Alan Cox wrote:
> > How can I find out the ac97 codec ID for this chipset (if there is one) so
> > it can be added to the ac97_codec_ids array? From what I can tell, it's as
> > though the codec->codec_read(codec, AC97_VENDOR_ID#) isn't returning the
> > codec value for this system at all.
>
> Something is failing to bring up the AC97 codec bus and/or set it up
> properly. Can you find exactly which patch broke that for you (you'll
> possibly want to keep fixing the codec table as you test older ones)
Other than my system works as a module, I have the same problems. I bet
you that 2.4.8 is the last kernel that worked for him. (It was for
me.) I do not know about pre-patches. If you want, I will find that
out for my case.
Trever Adams
Quick summary: sound now works on the ALi 5451 chip,
but has some non-fatal error messages.
On Thu, 2001-10-25 at 21:37, Tachino Nobuhiro wrote:
> diff -u -r linux-2.4.12-ac5.org/drivers/sound/ac97_codec.c linux-2.4.12-ac5/drivers/sound/ac97_codec.c
> --- linux-2.4.12-ac5.org/drivers/sound/ac97_codec.c Mon Oct 22 09:34:21 2001
> +++ linux-2.4.12-ac5/drivers/sound/ac97_codec.c Fri Oct 26 10:26:41 2001
> @@ -143,7 +143,6 @@
> {0x83847656, "SigmaTel STAC9756/57", &sigmatel_9744_ops},
> {0x83847684, "SigmaTel STAC9783/84?", &null_ops},
> {0x57454301, "Winbond 83971D", &null_ops},
> - {0,}
> };
>
> static const char *ac97_stereo_enhancements[] =
I just removed that final data set and the preceeding comma and
recompiled 2.4.12-ac6. I'm pleased to report that the sound now works
just fine! The module loads, and I do get some (non-fatal) error
messages, but once its loaded it runs like a champ.
BTW, I was also getting these error messages on my old 2.4.7 install.
This is my 2.4.12-ac6 log after `modprobe trident`. Take a look:
----------
Trident 4DWave/SiS 7018/ALi 5451,Tvia CyberPro 5050 PCI Audio, version
0.14.9d, 19:15:41 Oct 26 2001
PCI: Assigned IRQ 10 for device 00:03.0
trident: ALi Audio Accelerator found at IO 0xc400, IRQ 10
ac97_codec: AC97 Audio codec, id: 0x414c:0x4326 (Unknown)
ali: AC97 CODEC read timed out.
ali: AC97 CODEC write timed out.
ali: AC97 CODEC read timed out.
last message repeated 2 times
ac97_codec: AC97 codec, id: 0x0000:0x0000 (Unknown)
ali: AC97 CODEC write timed out.
ali: AC97 CODEC read timed out.
ali: AC97 CODEC write timed out.
last message repeated 10 times
ali: AC97 CODEC read timed out.
last message repeated 127 times
----------
This hangs the system totally for about 5 seconds. After this, it's all
fine and the sound works great. One strange thing I notice from the
above log is the different codec IDs showing up...
Thanks,
Mike Robbins
[email protected]
(Please also cc your reply to me.)
At 03:36 PM 26/10/01 +0100, Alan Cox wrote:
> > though the codec->codec_read(codec, AC97_VENDOR_ID#) isn't returning the
> > codec value for this system at all.
>
>Something is failing to bring up the AC97 codec bus and/or set it up
>properly. Can you find exactly which patch broke that for you (you'll
>possibly want to keep fixing the codec table as you test older ones)
Well the thing is this system has never had working sound. I've got 2 of
these machines, both with the array fix, and neither get sound. I've tried
2.4.7 (which didn't have the array fix), 2.4.9, 2.4.12, 2.4.13, and I'm
about to try some earlier kernels, but since this chip is "notoriously new"
I would not be suprised if it's not returning anything for what should be
valid codec calls. Will take a peek and get back to you.
PS: This is one of these SiS630S all in one integrated things, and also one
of the offenders in that SiS FrameBuffer stuff we've been discussing, so I
wouldn't be suprised in anomalies at all.
AMC Enterprises P/L - Stuart Young
First Floor - Network and Systems Admin
3 Chesterville Rd - [email protected]
Cheltenham Vic 3192 - Ph: (03) 9584-2700
http://www.amc.com.au/ - Fax: (03) 9584-2755
At 03:36 PM 26/10/01 +0100, Alan Cox wrote:
> > though the codec->codec_read(codec, AC97_VENDOR_ID#) isn't returning the
> > codec value for this system at all.
>
>Something is failing to bring up the AC97 codec bus and/or set it up
>properly. Can you find exactly which patch broke that for you (you'll
>possibly want to keep fixing the codec table as you test older ones)
Update: - 2.4.3 appears to have the same issue of no-find the codec.
2.2.19pre17 reports the wrong h/ware address for the sound device (the same
one as the IDE bus - urghy!), so I can't even load the driver to test if
it'll work (which I doubt).
Upon looking at the code between 2.4.0 and 2.4.13, in particular at
trident_ac97_get() and trident_ac97_set() there is practically no
difference between them, except for the addition of another option in the
switch statement for another card. Almost all the additions and changes
between versions have been specifically ALi or similar chipsets, and don't
seem to affect the SiS stuff.
So where to now?
Thinking mebbe I should hook this machine up to the net outside the
firewall, plug in the webcam and point it at it, give you an ssh account on
it, and connect an oscilloscope to the audio and let you fiddle. Useful for
the SiS FrameBuffer thing as well I'd guess. *grin*
Talk about remote debugging eh?
AMC Enterprises P/L - Stuart Young
First Floor - Network and Systems Admin
3 Chesterville Rd - [email protected]
Cheltenham Vic 3192 - Ph: (03) 9584-2700
http://www.amc.com.au/ - Fax: (03) 9584-2755
And more on the SiS7018/Trident audio driver...
Using 2.4.13-ac4, I get...
trident: can't allocate I/O space at 0x1000
.. and then insmod fails with...
/lib/modules/2.4.13-ac4/kernel/drivers/sound/trident.o: init_module: No
such device
.. which doesn't bode well I guess, least for my situation.
On the SiS FrameBuffer driver front, with 2.4.13-ac4 it comes up with the
same thing (blank/glowing display), except it flickers a bit more than the
last driver. Once again, the console and the rest of the machine works,
just no display output.
Going over the code, this looks a lot more like the core of the driver in
XFree86 4.1.0, which might prove useful. In fact, I'd guess it's pretty
much the same code, given some of the names of the functions, etc.
AMC Enterprises P/L - Stuart Young
First Floor - Network and Systems Admin
3 Chesterville Rd - [email protected]
Cheltenham Vic 3192 - Ph: (03) 9584-2700
http://www.amc.com.au/ - Fax: (03) 9584-2755