linux-kernel - Re: [alsa-devel] [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 17 Mar 2008 23:00:41 +0100
From:	Rene Herman <rene.herman@...access.nl>
To:	Bob Tracy <rct@...s.com>
CC:	Michael Cree <mcree@...on.net.nz>, Takashi Iwai <tiwai@...e.de>,
	ALSA devel <alsa-devel@...a-project.org>,
	linux-kernel@...r.kernel.org,
	Ivan Kokshaysky <ink@...assic.park.msu.ru>,
	linux-alpha@...r.kernel.org, Krzysztof Helt <krzysztof.h1@...pl>
Subject: Re: [alsa-devel] [regression] 2.6.25-rc4 snd-es18xx broken on Alpha

On 13-03-08 05:24, Bob Tracy wrote:

> Rene Herman wrote:
>> Okay, and applying the attached just makes your sound completely dead in the 
>> water?
>> (patch to delete es1888_init function)
> 
> Oddly enough, the patch had no effect whatsoever (at least with the
> ALSA drivers: I didn't try building a kernel with the OSS "sb" driver).
> Just to make sure I wasn't "benefiting" from initialization inherited
> from a prior boot, I even powered-down the machine for 30 seconds
> before booting on the new kernel.  snd-sb8 still works, and snd-es18xx
> is still broken (in exactly the same way as before).

Okay, thought I'd stare at this thing a bit -- there's no specific 1888 
documentation available it seems but I did notice something in the 1878 
datasheet which might mean something. The docs says that bits 0-1 are don't 
care for DMA but don't for IRQ, so could it possibly be as simple as the 
attached?

1878 sheet doesn't document register 0x7f, it seems...

Assuming it's not just this, this thing is going to require quite a bit of 
trial and error and without the hardware this will be troublesome. I expect 
this is not it, since the arch init code also doesn't care about bit 0 when 
setting that same register for IRQ 5.

If this is not it -- I'd try s/0x50/0x10/ in that line, even completely 
commenting out the IRQ setting line (with the arch code built in) and just 
generally frolic around 'till something blows up...

Rene.

View attachment "es18xx_trial_and_error.diff" of type "text/plain" (1274 bytes)