Re: SiS/Trident 4DWave sound driver oops

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

[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

[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 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: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]

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

[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

[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

[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

[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

[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

[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

[Stuart Young]

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

[Stuart Young]

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

Re: SiS drivers (more)

[Stuart Young]

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