From owner-freebsd-hardware Wed Mar 18 17:06:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA08257 for freebsd-hardware-outgoing; Wed, 18 Mar 1998 17:06:28 -0800 (PST) (envelope-from owner-freebsd-hardware@FreeBSD.ORG) Received: from grayling.erg.sri.com (grayling.erg.sri.com [128.18.4.194]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id RAA08251; Wed, 18 Mar 1998 17:06:25 -0800 (PST) (envelope-from templin@erg.sri.com) Received: from grayling.erg.sri.com by grayling.erg.sri.com (8.6.12/2.7davy) id RAA03159; Wed, 18 Mar 1998 17:07:02 -0800 Message-Id: <199803190107.RAA03159@grayling.erg.sri.com> X-Mailer: exmh version 2.0delta 6/3/97 To: freebsd-hackers@FreeBSD.ORG, freebsd-hardware@FreeBSD.ORG, templin@erg.sri.com Subject: Re: L2 cache problems (??) on ThinkPad 560E In-reply-to: Your message of "Wed, 18 Mar 1998 10:37:23 PST." <199803181837.KAA02717@grayling.erg.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Mar 1998 17:07:01 -0800 From: "Fred L. Templin" Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Folks, This problem is solved. Matt Jacob gave me a gentle nudge in the right direction which led to the solution. By adding additional wait-states to the PCMCIA controller chip's memory window mapping for the Netwave card on the 560E the write-corruption problem disappeared. So, it really wasn't a caching problem at all, but rather a memory timing issue with the 560E's PC-CARD implementation. This may be something to watch out for with other memory-mapped PC-CARDs on the ThinkPad... Fred templin@erg.sri.com > Hello, > > I'm trying to debug a problem with a device driver I wrote for the Netwave > PCMCIA radio networking card on an IBM ThinkPad 560E. The Netwave card is > configured as both a memory and I/O mapped card (i.e. 33KB of control store > on the card are memory-mapped into ISA bus memory space, and a block of > registers on the card are mapped into ISA I/O port space.) The card and > driver work fine on a wide variety of laptop and desktop systems, but when > I tried it on the 560E I ran into problems which "smell" like cache coherency > issues. > > Basically, reads from the card's memory work fine on the 560E; I can receive > network packets and even display them with tcpdump to show that data integrity > is preserved. But, writes to the card's memory (as the result of transmit > packets) result in either corrupted data over the radio link or a loss of > synchronization between the driver and card - which strongly suggests to me > that the writes are being cached and not flushed out to the card's control > store memory. I have declared all data structures which are written to the > card as "volatile" in my driver - which I thought should have obviated any > caching issues. But, are there any other low-level system primitives I might > need to use to either flush the cache or avoid caching alltogether? Finally, > I may be making a dangerous leap of faith here in assuming that caching is > at the heart of the issue. Can anyone think of another scenario which might > be causing the problems I'm seeing? > > Thanks much, > > Fred > templin@erg.sri.com > > P.S. Another factor which makes me believe that caching is the issue is > the fact that the 560E includes a L2 cache chip which I don't see on > any of my other laptops (see the "dmesg" output below): > > > > FreeBSD 2.2.5-RELEASE #29: Tue Mar 17 10:00:06 GMT 1998 > > templin@gloom.erg.sri.com:/usr/src/sys/compile/RAPI > > CPU: Pentium (166.19-MHz 586-class CPU) > > Origin = "GenuineIntel" Id = 0x543 Stepping=3 > > Features=0x8001bf > > real memory = 50331648 (49152K bytes) > > avail memory = 46112768 (45032K bytes) > > Initializing PC-card drivers: aic gmc ed ep fe nw sn sio wdc ncv stg > > Probing for devices on PCI bus 0: > > chip0 rev 2 on pci0:0 > > chip1 rev 3 on pci0:1 > > vga0 rev 211 int a irq ?? on pci0:3 > > pcic0 rev 226 int a irq ?? on pci0:19 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message