SiS/Trident 4DWave sound driver oops

SiS/Trident 4DWave sound driver oops

[Stuart Young]

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      - sgy@amc.com.au
Cheltenham Vic 3192    - Ph:  (03) 9584-2700
http://www.amc.com.au/ - Fax: (03) 9584-2755

Re: SiS/Trident 4DWave sound driver oops

[Alan Cox]

> 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

Re: SiS/Trident 4DWave sound driver oops

[Stuart Young]

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 - sgy@amc.com.au
(aka Cefiar) - cefiar1@optushome.com.au

[All opinions expressed in the above message are my]
[own and not necessarily the views of my employer..]

Re: SiS/Trident 4DWave sound driver oops

[Michael F. Robbins]

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
compumike@compumike.com
(Please also cc your reply to me.)

Re: SiS/Trident 4DWave sound driver oops

[Trever L. Adams]

[-- Attachment #1: Type: text/plain, Size: 800 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: SiS/Trident 4DWave sound driver oops

[Alan Cox]

> 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)

Re: SiS/Trident 4DWave sound driver oops

[Robert Love]

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

Re: SiS/Trident 4DWave sound driver oops

[Stuart Young]

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      - sgy@amc.com.au
Cheltenham Vic 3192    - Ph:  (03) 9584-2700
http://www.amc.com.au/ - Fax: (03) 9584-2755

Re: SiS/Trident 4DWave sound driver oops

[David Weinehall]

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 <tao@acc.umu.se> /> Northern lights wander      \\
//  Project MCA Linux hacker        //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: SiS/Trident 4DWave sound driver oops

[Robert Love]

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

Re: SiS/Trident 4DWave sound driver oops

[Tachino Nobuhiro]

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

Re: SiS/Trident 4DWave sound driver oops

[Robert Love]

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

Re: SiS/Trident 4DWave sound driver oops

[Tachino Nobuhiro]

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().

Re: SiS/Trident 4DWave sound driver oops

[Robert Love]

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

Re: SiS/Trident 4DWave sound driver oops

[Tachino Nobuhiro]

Hello,

At 25 Oct 2001 09:24:21 -0400,
Michael F. Robbins <compumike@compumike.com> 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
> compumike@compumike.com
> (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[] =

Re: SiS/Trident 4DWave sound driver oops

[Michael F. Robbins]

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
compumike@compumike.com
(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
----------

Re: SiS/Trident 4DWave sound driver oops

[Stuart Young]

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      - sgy@amc.com.au
Cheltenham Vic 3192    - Ph:  (03) 9584-2700
http://www.amc.com.au/ - Fax: (03) 9584-2755

Re: SiS/Trident 4DWave sound driver oops

[Stuart Young]

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      - sgy@amc.com.au
Cheltenham Vic 3192    - Ph:  (03) 9584-2700
http://www.amc.com.au/ - Fax: (03) 9584-2755

Re: SiS/Trident 4DWave sound driver oops

[Michael F. Robbins]

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
compumike@compumike.com
(Please also cc your reply to me.)