Date: Sat, 13 Nov 2004 20:48:49 +0100 From: hans@lambermont.dyndns.org (Hans Lambermont) To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Cc: FreeBSD amd64 mailing list <freebsd-amd64@freebsd.org> Subject: Re: [PATCH] if_sk(4) rx/tx "hangs" Message-ID: <20041113194849.GE40364@moya.lambermont.dyndns.org> In-Reply-To: <Pine.BSF.4.53.0411130912020.85716@e0-0.zab2.int.zabbadoz.net> References: <Pine.BSF.4.53.0411130037360.85716@e0-0.zab2.int.zabbadoz.net> <200411121739.40804.peter@wemm.org> <Pine.BSF.4.53.0411130912020.85716@e0-0.zab2.int.zabbadoz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Bjoern A. Zeeb wrote: > On Fri, 12 Nov 2004, Peter Wemm wrote: >> Anyway, the point was that it worked! Could the problem with the K8V >> SE really be as simple as we've been hardcoding 128K of ram for a >> device that only has 64K? > > It's not directly a matter of the K8V SE. > > It's the 88E8001 (but at least my K8V SE deluxe has this one acording > to the PN from VPD data). The 88E8010 already has 128k according to > the pdf mentioned in my diff. > > Anyone actually tested it ? Mine still seems to be fine after the > night. I have a Marvell Semiconductor, Inc. Yukon 88E8000 on my Asus P4P800-E (according to dmesg that is, the booklet claims it's a 88E8001). Using the patch on a stock 5.3R system did not help (could not even get a dhcp lease). Adding debug.mpsafenet="0" in /boot/loader.conf also did not help. Adding SK_LOCK/SK_UNLOCK patch of http://www.freebsd.org/cgi/query-pr.cgi?pr=kern%2F73038 also did not help. Someone suggested upgrading the BIOS to >1003, the system now runs 1005.002, which ;-) did not help. Hans Lambermont -- http://lambermont.webhop.org/ () ASCII-ribbon campaign against vCards, /\ HTML-mail and proprietary formats.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041113194849.GE40364>