linux-kernel - Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep

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:	Sun, 13 Jan 2008 12:26:12 +0100
From:	Takashi Iwai <tiwai@...e.de>
To:	Harald Dunkel <harald.dunkel@...nline.de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: 2.6.24-rc7, intel audio: alsa doesn't say a beep

At Sat, 12 Jan 2008 10:41:21 +0100,
Harald Dunkel wrote:
> 
> Takashi Iwai wrote:
> > At Thu, 10 Jan 2008 23:02:53 +0100,
> > Harald Dunkel wrote:
> >> Takashi Iwai wrote:
> >>> Hm...  Just to be sure, try the patch below.  It's a clean up patch
> >>> that I'd like to apply later.
> >>>
> >> Sorry, no sound.
> > 
> > OK, but I'd like to know whether this makes no regression to rc6.
> > Could you check?
> > 
> > Also, what exactly did you test?  "No sound" means that no sound from
> > the headphone / line-out or from the speaker?
> > 
> > One interesting test would be to increase the value of udelay() in the
> > reverted patch.  What happens if it's set to 500?
> > 
> 
> There is no udelay() in the reverted patch.

Hm?  Ingo's patch replaces msleep(1) with udelay(10) +
cond_resched().  This is the patch we're arguing.  This was already
reverted (based on your report) on git.

> If I replace "udelay(10)"
> by "udelay(500)" in the original rc7, then there is still no sound.

Interesting...  What about udelay(1000)?  Then it'll be closer to
msleep(1).

> This is like fishing in the dark. We've got a working version. Why not
> keep it?

Yes, we are shooting in the dark now indeed.  Honestly, I have no
concrete idea why the patch breaks the sound initialization.

It seems that Dell machines (or STAC codecs) have problems with the
initialization timing.  I don't think that all commands but only
certain some command sequences that are so sensitive to the access
timing.  We need to identify this.

Ingo's patch is basically a really nice fix.  It reduces the
unnecessary delay, especially improves resume speed much.  I'd love to
have it.  And above all, I need to understand what is the real
problem.  Unfortunately, I have no this hardware and the precise h/w
data, so must rely on testers and a guess work.

thanks,

Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/