Hi!
After some more careful testing, I was able to identify the exact moment
when the changes in the Linux kernel broke SPDIF passthru of Emu10k1
cards. I tested all the pre-patches between kernels 2.4.12 and 2.4.13
and I found that kernel 2.4.13-pre2 was the one that broke it. Up until
2.4.13-pre1, everything works fine. From 2.4.13-pre2 on, passthru sound
is broken (if kernel option CONFIG_HIGHMEM4G or CONFIG_HIGHMEM64G is
used).
According to the kernel Changelog, it appears that one of these changes
was the responsible for it:
2.4.13-pre2:
- Alan Cox: more merging
- Ben Fennema: UDF module license
- Jeff Mahoney: reiserfs endian safeness
- Chris Mason: reiserfs O_SYNC/fsync performance improvements
- Jean Tourrilhes: wireless extension update
- Joerg Reuter: AX.25 updates
- David Miller: 64-bit DMA interfaces
I hope this helps and I hope you can fix it soon.
Regards
Z?
PS- I'm not a subscriber of the lkml. Please send any messages to
[email protected] if you want to contact me.
On Thu, 21 Feb 2002, Jos? Carlos Monteiro wrote:
> Emu10k1 SPDIF passthru with the creative/kernel OSS driver only works
> if the kernel option CONFIG_NOHIGHMEM is set. If one of the other two
> related options (CONFIG_HIGHMEM4G or CONFIG_HIGHMEM64G) is used
> instead, the sound card is unable to "pass" AC3 streams "through" the
> SPDIF output; only PCM and multi-channel sound gets to the
> amp/speakers. This bug is present since kernel 2.4.13 (with kernel
> 2.4.12 and earlier it worked fine),and it's still present in 2.4.18-rc4
*********************************************************************
I noticed that my first message didn't reach this list before, so I'm
reposting it now. Here's its original contents:
***********************************************
Hi!
After several tests with lots of different kernels, and thanks to the help
of Hubert Mantel from SuSE, the following conclusion has been reached:
Emu10k1 SPDIF passthru with the kernel OSS driver works only if the kernel
option CONFIG_NOHIGHMEM is set. If one of the other two related options
(CONFIG_HIGHMEM4G or CONFIG_HIGHMEM64G) is used instead, the sound card is
unable to "pass" AC3 streams "through" the SPDIF output; only PCM and
multi-channel sound gets to the amp/speakers.
Emu10k1 SPDIF passthru is especially important for users who play DVDs on
their Linux boxes with digital sound from a SBLive 5.1 card.
This bug is present since kernel 2.4.13 (kernel 2.4.12 and earlier
versions don't suffer from it), and it's still present in the lastest
kernel (2.4.18-rc4).
I did all the tests using both the OSS emu10k1 driver that comes with each
kernel, and the latest driver from Creative website (v0.18). The results
were always the same. So this bug does not depend on the driver version,
it depends solely on the kernel version. I guess this is a kernel issue
then. Something that changed on kernel 2.4.13 must be the cause of this
problem.
I hope I was able to make myself clear enough. :)
Regards,
Z?
PS - I'm not a member of the mailing list, so please email me to my
personal mailbox (mailto:[email protected]) if you need to contact me.
*************************************************************************
Somehow this message didn't reach this list when I first sent it a couple
of days ago, so this is a repost. Development of this story can be found
on the message that I posted also to this list some minutes ago.
****************************************************************
On Seg, 2002-02-25 at 18:16, John Alvord wrote:
> I know it is again more work, but the next usual step is to determine
> the differences between the two pre levels and add them in one at a
> time to the working pre level until the function break occurs.
Ok, but I think that may be a little bit out of my league. I mean, I'd
like to help, but where am I supposed to find all the individual patches?
Is is possible to break the pre1-pre2 patch file into individual files?
Or, is there a repository for that sort of thing? Or if someone emailed me
all the 7 patches in individual files, I could test them one by one.
Regards
Z?
> On Sun, 24 Feb 2002 22:28:34 +0000 (WET), I wrote:
> >> Emu10k1 SPDIF passthru with the creative/kernel OSS driver only works
> >> if the kernel option CONFIG_NOHIGHMEM is set. If one of the other two
> >> related options (CONFIG_HIGHMEM4G or CONFIG_HIGHMEM64G) is used
> >> instead, the sound card is unable to "pass" AC3 streams "through" the
> >> SPDIF output; only PCM and multi-channel sound gets out.
> >
> >I tested all the pre-patches between kernels 2.4.12 and 2.4.13
> >and I found that kernel 2.4.13-pre2 was the one that broke it.
> >2.4.13-pre2:
> >- Alan Cox: more merging
> >- Ben Fennema: UDF module license
> >- Jeff Mahoney: reiserfs endian safeness
> >- Chris Mason: reiserfs O_SYNC/fsync performance improvements
> >- Jean Tourrilhes: wireless extension update
> >- Joerg Reuter: AX.25 updates
> >- David Miller: 64-bit DMA interfaces
On 24 Feb 2002, Jos? Carlos Monteiro wrote:
> Hi!
> After some more careful testing, I was able to identify the exact moment
> when the changes in the Linux kernel broke SPDIF passthru of Emu10k1
> cards. I tested all the pre-patches between kernels 2.4.12 and 2.4.13
> and I found that kernel 2.4.13-pre2 was the one that broke it. Up until
> 2.4.13-pre1, everything works fine. From 2.4.13-pre2 on, passthru sound
> is broken (if kernel option CONFIG_HIGHMEM4G or CONFIG_HIGHMEM64G is
> used).
>
> According to the kernel Changelog, it appears that one of these changes
> was the responsible for it:
>
> 2.4.13-pre2:
> - Alan Cox: more merging
> - Ben Fennema: UDF module license
> - Jeff Mahoney: reiserfs endian safeness
> - Chris Mason: reiserfs O_SYNC/fsync performance improvements
> - Jean Tourrilhes: wireless extension update
> - Joerg Reuter: AX.25 updates
> - David Miller: 64-bit DMA interfaces
Does the emu10k1 driver support the new DMA interface? I've
downloaded the patch-2.4.13-pre1-pre2.bz2 from
ftp://ftp.kernel.org/pub/linux/kernel/v2.4/testing/incr/
and checking it, it seems that the BIG change was the inclussion of
David Miller 64-bit DMA. Does emu10k1 use DMA for SPDIF output? the
main change affecting dma when HIGHMEM is enabled is in types.h, that
define dma_addr_t as a u64 instead of u32, so does the hardware in the
live or the driver (or whatever :-) support that?
Best regards,
- german
-------------------------------------------------------------------------
German Gomez Garcia | Send email with "SEND GPG KEY" as subject
<[email protected]> | to receive my GnuPG public key.
On Tue, 26 Feb 2002, German Gomez Garcia wrote:
> On 24 Feb 2002, Jos? Carlos Monteiro wrote:
>
> > Hi!
> > After some more careful testing, I was able to identify the exact moment
> > when the changes in the Linux kernel broke SPDIF passthru of Emu10k1
> > cards. I tested all the pre-patches between kernels 2.4.12 and 2.4.13
> > and I found that kernel 2.4.13-pre2 was the one that broke it. Up until
> > 2.4.13-pre1, everything works fine. From 2.4.13-pre2 on, passthru sound
> > is broken (if kernel option CONFIG_HIGHMEM4G or CONFIG_HIGHMEM64G is
> > used).
> >
> > According to the kernel Changelog, it appears that one of these changes
> > was the responsible for it:
> >
> > 2.4.13-pre2:
> > - Alan Cox: more merging
> > - Ben Fennema: UDF module license
> > - Jeff Mahoney: reiserfs endian safeness
> > - Chris Mason: reiserfs O_SYNC/fsync performance improvements
> > - Jean Tourrilhes: wireless extension update
> > - Joerg Reuter: AX.25 updates
> > - David Miller: 64-bit DMA interfaces
>
> Does the emu10k1 driver support the new DMA interface? I've
> downloaded the patch-2.4.13-pre1-pre2.bz2 from
We allocate memory with pci_alloc_consistent() which according to
DMA-mapping.txt assures 32-bits PCI addresses. On top of that
we set a dma_mask (with pci_set_dma_mask) of 29 bits (512Mib).
> ftp://ftp.kernel.org/pub/linux/kernel/v2.4/testing/incr/
>
> and checking it, it seems that the BIG change was the inclussion of
> David Miller 64-bit DMA. Does emu10k1 use DMA for SPDIF output?
It uses DMA for all sound input/output.
> the
> main change affecting dma when HIGHMEM is enabled is in types.h, that
> define dma_addr_t as a u64 instead of u32, so does the hardware in the
> live or the driver (or whatever :-) support that?
>
> Best regards,
>
> - german
The most bizzare is that in a machine with 192Mib of memory but with a
kernel compiled with HIGHMEM support I see the same type of problems.
Rui Sousa
> The most bizzare is that in a machine with 192Mib of memory but with a=20
> kernel compiled with HIGHMEM support I see the same type of problems.
Change of size in a structure or type ?
On Wed, 27 Feb 2002, Alan Cox wrote:
It's true dma_addr_t does change from u32 to u64 and we do thinks like:
(32 bit pci register) = cpu_to_le32(dma_handle)
What is the correct way of doing this?
(32 bit pci register) = cpu_to_le32((u32)dma_handle)
?
Rui Sousa
> > The most bizzare is that in a machine with 192Mib of memory but with a=20
> > kernel compiled with HIGHMEM support I see the same type of problems.
>
> Change of size in a structure or type ?
>
> _______________________________________________
> Emu10k1-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/emu10k1-devel
>
Rui Sousa wrote:
>
> On Wed, 27 Feb 2002, Alan Cox wrote:
>
> It's true dma_addr_t does change from u32 to u64 and we do thinks like:
>
> (32 bit pci register) = cpu_to_le32(dma_handle)
>
> What is the correct way of doing this?
>
> (32 bit pci register) = cpu_to_le32((u32)dma_handle)
If you only have 32 bits, then I presume 64-bit DMA isn't supported.
So, (1) never pass more than 0xffffffff to pci_set_dma_mask, and (2)
just truncate dma_addr_t (addr & 0xffffffff) so that you only read the
low 32-bits, always.
Jeff
--
Jeff Garzik | "UNIX enhancements aren't."
Building 1024 | -- says /usr/games/fortune
MandrakeSoft |
> It's true dma_addr_t does change from u32 to u64 and we do thinks like:
> (32 bit pci register) = cpu_to_le32(dma_handle)
>
> What is the correct way of doing this?
> (32 bit pci register) = cpu_to_le32((u32)dma_handle)
The cast befor ethe cpu_to_ is safe if its 32bit I/O only. Maybe we should
have cpu_to_le_dma_addr_t 8)
Hi,
Looks like the bug is from pushing the 64bit dma_handle on a 32bit va_arg
list. Its fixed in CVS, and at least one person has reported success.
On Thu, 28 Feb 2002, David S. Miller wrote:
> From: Alan Cox <[email protected]>
> Date: Fri, 1 Mar 2002 01:07:27 +0000 (GMT)
>
> The cast befor ethe cpu_to_ is safe if its 32bit I/O only. Maybe we should
> have cpu_to_le_dma_addr_t 8)
>
> Actually, the cast to 32-bit is safe if you've set your DMA mask
> properly :-)
>
--
Daniel Bertrand
From: Alan Cox <[email protected]>
Date: Fri, 1 Mar 2002 01:07:27 +0000 (GMT)
The cast befor ethe cpu_to_ is safe if its 32bit I/O only. Maybe we should
have cpu_to_le_dma_addr_t 8)
Actually, the cast to 32-bit is safe if you've set your DMA mask
properly :-)
Hi,
Sorry to beat a dead horse, but wouldn't it be better if sizes didn't
change within the same CPU arch? I don't see how binary-only modules can
ever work reliably if the size of types change depending on people's
.config file. (not that I use any binary-only modules :-).
Is this a common thing done in the kernel? For dma_addr_t, why not just
have it always be 64bit?
On Thu, 28 Feb 2002, David S. Miller wrote:
> From: Alan Cox <[email protected]>
> Date: Fri, 1 Mar 2002 01:07:27 +0000 (GMT)
>
> The cast befor ethe cpu_to_ is safe if its 32bit I/O only. Maybe we should
> have cpu_to_le_dma_addr_t 8)
>
> Actually, the cast to 32-bit is safe if you've set your DMA mask
> properly :-)
>
--
Daniel Bertrand