Date: Tue, 21 Apr 1998 01:50:29 +0800 From: Peter Wemm <peter@netplex.com.au> To: "Justin T. Gibbs" <gibbs@plutotech.com> Cc: gibbs@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: ahh, I think I see part of the problem.. (CAM bouncing) Message-ID: <199804201750.BAA07818@spinner.netplex.com.au> In-Reply-To: Your message of "Mon, 20 Apr 1998 10:53:12 CST." <199804201657.KAA28393@pluto.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Justin T. Gibbs" wrote: > >It seems that bus_dmamem_alloc() is flawed if a filter function is active, > >for starters. With a Bt-445S, it's got to bounce the 'paddr % 16MB == > >biosaddr' pages, so the contigmalloc() will allocate pages from the entire > >memory pool (since the 445S has a 32bit dma limit), and yet bouncing may > >still need to happen. Incidently, what happens if contigmalloc() > >allocates a page from the shadow of the bios rom addr? :-) > > Take a good look at the initialization code in bt_isa.c. If we have to > install a filter, we set the address range for the filter to be 16MB->4GB. > bus_dmamem_alloc and the code that allocates bounce pages only allocates > space below the low address specified in the dma tag. This should ensure > that we allocate pages that can replace any page rejected by the filter. > So, the setup for a broken 445S is the same as an ISA card except that we > include a filter that will allow 99% of the pages above 16MB. Right, I hadn't got that far along in working out what was happening.. I was confused about what lowaddr actually meant, and I thought the filter was running on all queries. > >Also, there doesn't appear to be anything to stop the DMA counters crossing > >the dreaded 16MB boundary.. > > ??? If you are talking about the problem below, feel free to adjust the > filter to exclude the pages that may cause a wrap. Well, a page won't cause a wrap, but a single dma transfer shouldn't be allowed to cross the boundary. I guess the 'if (paddr == nextpaddr)' test would be the place to be thinking about attacking that. contigmalloc() can be told to not cross the boundary by specifying the 'boundary' as 0x1000000. Hmm.. after some rummaging around, I found some (very) old notes that suggest that there is a different firmware rom image for card revs A-D (3.36) and rev E only (3.37). Rev.E has the known hardware problems fixed on the PCB. Going from memory, rev 3.35 firmware (which I have) had the 16MB boundary wrap problem, and I think it was patched in firmware rev 3.36 and later. > >I have a revision of the card that does not > >incrememt the top 8 bits at the end of the 16MB space. Ie: the counters > >wrap from 15MB->0MB instead of 15MB->16MB (and 31MB->16MB instead of 31MB-> > >32MB). Damn this card. :-) (However, I seem to recall that this > >particular problem was fixable with a firmware upgrade (microprocessor > >firmware, not the PC bios), unlike the incomplete address decode problem > >that creates the bios shadow). > > This I don't know about, but Mylex was happy to send me a firmware upgrade > for my 747C without charge, just last week. I can ask I guess. :-) I have the v3.36/v4.72 firmware/bios images ready to burn onto eprom - but last time I tried, I couldn't get eproms fast enough and the slower set that I used had to have the clock speed lowered. > >Cheers, > >-Peter > >-- > >Peter Wemm <peter@netplex.com.au> Netplex Consulting > > Here are the patches I promised... Thanks.. :-) Cheers, -Peter -- Peter Wemm <peter@netplex.com.au> Netplex Consulting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804201750.BAA07818>