netdev - Re: sd8686 linux system hang: not always

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] [day] [month] [year] [list]

Message-ID: <20090821225550.GA1634@kaos.fbx.proxad.net>
Date:	Sat, 22 Aug 2009 00:55:50 +0200
From:	Benoît Vaillant <benoit.vaillant@...log.org>
To:	Dan Williams <dcbw@...hat.com>
Cc:	Benoît Vaillant <benoit.vaillant@...log.org>,
	netdev@...r.kernel.org
Subject: Re: sd8686 linux system hang: not always

Hi,

On Fri, Aug 21, 2009 at 08:04:16AM -0500, Dan Williams wrote:
> Well, besides the fact that the Poulsbo SDHC driver hasn't actually
> passed review for the kernel yet... 

And other parts of Poulsbo drivers were removed from -at least-
debian, for the xorg part of it. I had that in mind.

> That doesn't mean the Poulsbo driver isn't a fine driver, but if
> Pierre hasn't acked it, I don't really trust it.  The largest # of
> problems people have had with Libertas SDIO have been with the host
> controller with things like transfer widths, clocking, interrupt
> vs. polled mode, chunk size, etc.  When the SDHC driver and hardware
> they are using actually starts working well, then libertas actually
> starts working well.

Ok. I'll check on parameters when I get spare time. I did consider
such things could be part (all? :) ) of the issue.

Pointers welcomed, if any other than browsing the web!

> So I don't mean to brush you off, but we know the chip works pretty well
> with the Ricoh line (which I'm typing this on right now with an sd8686)
> and a few other embedded-type controllers.  So I'd start diving down
> into the SDHC driver code for Poulsbo and try to figure out what's going
> on there and in the MMC layer.

Hehe, no worry, I know the chip works fine under midinux. Yet
compiling such working drivers would either lead me to revert to an
older kernel version (and not provide testing with newer ones, thus)
or adapt the marvell driver to newer kernel, task which I'm rather not
sure to be able to carry by some quite good amount of time :)

You didn't brush me off, I wasn't expecting a straight working
solution :)

TFYA,

-- 
Benoît

Download attachment "~/.gnupg/public_key.txt" of type "application/pgp-signature" (198 bytes)