Date: Mon, 30 Dec 2002 22:38:35 -0600 (CST) From: "M. Warner Losh" <imp@bsdimp.com> To: mranner@inode.at Cc: freebsd-current@FreeBSD.ORG Subject: Re: My wi(4) ate itself (or Fun with no memory). Message-ID: <20021230.223835.69319274.imp@bsdimp.com> In-Reply-To: <200212302328.46783.mranner@inode.at> References: <200212302210.gBUMAKZc068550@castle.org> <200212302328.46783.mranner@inode.at>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <200212302328.46783.mranner@inode.at>
Michael Ranner <mranner@inode.at> writes:
: Am Montag, 30. Dezember 2002 23:10 schrieb Lee Damon:
: > I have the same problems on an IBM T30 with integrated wi running
: > 4.7-STABLE. In fact, I've had this problem since 4.5 (which is where I
: > started on this system.)
:
: I think the "wi0: timeout in wi_cmd 0x0000; event status 0x8000"
: messages started around 4.4, 4.5 or so. With my old FreeBSD 4 I had no
: "visible" problems, but after upgrading to 4.7 I have tons of wi_timeout's
:
: I fixed it with:
:
: 1359c1359
: < DELAY(WI_DELAY);
: ---
: > /*DELAY(WI_DELAY);*/
This delay is needed on far too many cards to just delete it.
: 1363,1364c1363,1364
: < device_printf(sc->dev, "timeout in wi_seek to %x/%x; last
: status %x\n",
: < id, off, status);
: ---
: > /*device_printf(sc->dev, "timeout in wi_seek to %x/%x; last
: status %x\n",
: > id, off, status);*/
this isn't a fix.
: The big problem was the "DELAY", because this call freezes the system and that
: was not acceptable for a router, but I also increased the value of the
: surrounding loop.
The big problem is that we have a horrible reset policy in the wi
driver. When it gets into this state, we're screwing the system into
the ground in the driver.
Warner
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021230.223835.69319274.imp>