Date: Tue, 15 Dec 1998 08:15:39 +0200 (SAT) From: John Hay <jhay@mikom.csir.co.za> To: mike@smith.net.au (Mike Smith) Cc: sanpei@sanpei.org, mike@smith.net.au, current@FreeBSD.ORG Subject: Re: PAO Integration? Message-ID: <199812150615.IAA06709@zibbi.mikom.csir.co.za> In-Reply-To: <199812141054.CAA00320@dingo.cdrom.com> from Mike Smith at "Dec 14, 98 02:54:58 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> > mike@smith.net.au wrote: > > >> > > > >> > Do NE2000 Compatible PCMCIA cards work under PAO3, as it is now? > > >> > If so, is the development snapshot available anywhere? > > >> > > >> They work fine under stock 2.2 and 3.0 (this message is being sent > > >> using one). > > Content-Type: Text/Plain; charset=us-ascii > > Content-Transfer-Encoding: 7bit > > ... > > Tuple #6, code = 0x1b (Configuration entry), length = 25 > > 000: c1 81 78 ca 61 00 03 0f 10 03 0f 30 fc be c9 04 > > 010: 00 00 40 0d 40 40 00 40 0d > > Config index = 0x1(default) > > Interface byte = 0x81 (I/O) wait signal supported > > Card decodes 10 address lines, limited 8/16 Bit I/O > > I/O address # 1: block start = 0x300 block length = 0x10 > > I/O address # 2: block start = 0x310 block length = 0x10 > > IRQ modes: Level > > IRQs: 2 3 4 5 6 7 9 10 11 12 13 15 > > Memory descriptor 1 <------------------- > > blk length = 0x400 card addr = 0x000 host addr = 0xd4000 > > Memory descriptor 2 <------------------- > > blk length = 0x4000 card addr = 0x4000 host addr = 0xd4000 > > ---------- > > Review pccardd. > > PAO's assign_io function in pccardd/cardd.c has related code but > > it's comment is ``XXX -- dirty hack for some 'ed' cards that have > > incomplete iomem CIS tupples.'' > > But FreeBSD-current's assign_io function does not have it. > > > > I think that Mike's card does not have Memory descriptor.. Is > > that right? > > Yes; there's a long-standing bug in the way that the stock pccardd > deals with memory blocks < 4096 bytes, where it tries to allocate a > zero-sized window, which fails and thus the card is rejected. > > The memory region in question's not actually used for the card's > operation; the simplest fix would be to correct pccardd to either > expand any window < 4096 to 4096 or to just not map it (bad but > simpler). Why not just check if there is a next (second) region defined that consumes the first one and use that for the mapping? All the cards that I have seen and all the complaints in the mailinglists with printouts of the CIS have a second memory region that totally overlaps the first, if you look at the host addr and blk length. John -- John Hay -- John.Hay@mikom.csir.co.za 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?199812150615.IAA06709>