linux-kernel - Re: linux-next: Tree for September 3

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]

Message-Id: <20080904013743.0ecc9ec5.akpm@linux-foundation.org>
Date:	Thu, 4 Sep 2008 01:37:43 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	Yinghai Lu <yhlu.kernel@...il.com>
Cc:	Jesse Barnes <jbarnes@...tuousgeek.org>
Subject: Re: linux-next: Tree for September 3

On Thu, 4 Sep 2008 01:25:44 -0700 Andrew Morton <akpm@...ux-foundation.org> wrote:

> can't complain about that, apart from the apparently-bogus "unable to
> apply power".

ooh look, I fixed something:

--- a/drivers/pcmcia/cs.c~a
+++ a/drivers/pcmcia/cs.c
@@ -477,6 +477,8 @@ static int socket_setup(struct pcmcia_so
 	 */
 	msleep(vcc_settle * 10);
 
+	msleep(100);
+
 	skt->ops->get_status(skt, &status);
 	if (!(status & SS_POWERON)) {
 		cs_err(skt, "unable to apply power.\n");
_

we seem not to be giving that card enough settling time.  Or is it
a characteristic of the controller?  

It's a module option, but google(linux "unable to apply power") gets
859 hits.  Maybe the default is too short..


btw, do we really need to spew all this?

pccard: card ejected from slot 0
3c59x 0000:07:00.0: restoring config space at offset 0xf (was 0xffffffff, writing 0x50a0115)
3c59x 0000:07:00.0: restoring config space at offset 0xe (was 0xffffffff, writing 0x0)
3c59x 0000:07:00.0: restoring config space at offset 0xd (was 0xffffffff, writing 0x50)
3c59x 0000:07:00.0: restoring config space at offset 0xc (was 0xffffffff, writing 0x0)
3c59x 0000:07:00.0: restoring config space at offset 0xb (was 0xffffffff, writing 0x5c5710b7)
3c59x 0000:07:00.0: restoring config space at offset 0xa (was 0xffffffff, writing 0x90)
3c59x 0000:07:00.0: restoring config space at offset 0x9 (was 0xffffffff, writing 0x0)
3c59x 0000:07:00.0: restoring config space at offset 0x8 (was 0xffffffff, writing 0x0)
3c59x 0000:07:00.0: restoring config space at offset 0x7 (was 0xffffffff, writing 0x0)
3c59x 0000:07:00.0: restoring config space at offset 0x6 (was 0xffffffff, writing 0x58000080)
3c59x 0000:07:00.0: restoring config space at offset 0x5 (was 0xffffffff, writing 0x58000000)
3c59x 0000:07:00.0: restoring config space at offset 0x4 (was 0xffffffff, writing 0x2401)
3c59x 0000:07:00.0: restoring config space at offset 0x3 (was 0xffffffff, writing 0x4000)
3c59x 0000:07:00.0: restoring config space at offset 0x2 (was 0xffffffff, writing 0x2000010)
3c59x 0000:07:00.0: restoring config space at offset 0x1 (was 0xffffffff, writing 0x2100007)
3c59x 0000:07:00.0: restoring config space at offset 0x0 (was 0xffffffff, writing 0x525710b7)

--
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/