From alsa-devel-owner@alsa.jcu.cz  Mon Oct 26 19:55:57 1998
Received: from cyphyn.219.org (nwhn-sh8-port112.snet.net [204.60.16.112])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id TAA09606
	for <alsa-devel@jcu.cz>; Mon, 26 Oct 1998 19:55:29 +0100
Received: from localhost (emng@localhost)
          by cyphyn.219.org (8.8.4/8.8.4) with SMTP
	  id OAA00957 for <alsa-devel@jcu.cz>; Mon, 26 Oct 1998 14:58:23 -0500
Date: Mon, 26 Oct 1998 14:58:22 -0500 (EST)
From: Fred Floberg <emng@geocities.com>
To: alsa-devel@jcu.cz
Subject: ES1371 bug hunting question
In-Reply-To: <199810260115.UAA09111@cyphyn.219.org>
Message-ID: <Pine.LNX.3.95.981026134143.705A-100000@cyphyn.219.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list



On Sun, 25 Oct 1998 perex@jcu.cz wrote:

> On Sun, 25 Oct 1998, Fred Floberg wrote:
> 
> > On my own machine:
> > 
> > # dmesg | grep es1371
> > snd: es1371: codec write timeout at 0x14 [0xffffffff]
> > <repeated many times>
> 
> 0xffffffff value looks very badly.. Please, look to codec i/o routines and
> verify my work....
> 

I've run across something that has me puzzled...

In alsa-driver/lowlevel/pci/es1370.c, in snd_es1371_codec_write(....)
there is the snd_printk(....) function which generates the kernel message
above.

The value 0xffffffff is the return value of

           inl( ES_REG( ensoniq, 1371_CODEC ) )

which expands to

           inl( ensoniq -> port + 0x14 )

ensoniq is defined as a struct of type snd_stru_ensoniq and
ensoniq -> port is defined as an unsigned int.

        alsa-driver/include/audiopci.h, line 276:

struct snd_stru_ensoniq {
       ....
       unsigned int port;
       ....
};

However, in snd_ensoniq_create(.... struct snd_pci_dev *pci ....)
that unsigned int is being initialized with an unsigned long:

        alsa-driver/lowlevel/pci/es1370.c, line 995:

ensoniq -> port = pci -> base_address[ 0 ] & ~PCI_BASE_ADDRESS_SPACE;

In alsa-driver/include/sndpci.h, line 40, I find:

struct snd_pci_dev {
       ....
       unsigned long base_address[6];
       ....
};

So it looks as though the initialization in snd_ensoniq_create(...)
would cause overflow of the structure member ensoniq -> port, possibly
causing inl( ensoniq -> port + 0x14 ) to read from the wrong location.

Am I missing something here?

I don't understand why the compiler didn't warn about that...

Fred

(I have the day off today, so I'll spend some time doing more digging)



