Re: [Madwifi-users] PCI memory reservation failures

Actually, for 2.6 you should use BRIDGE_MEM_MIN and BRIDGE_MEM_MAX. 
However, if your card is being seen by the driver then you have a different 
problem than this fix was built for.  However, the fact that your card 
continues be seen by the driver with this fix in place is a very useful 
datapoint.

Thanks!

Alec

--On Saturday, May 8, 2004 8:35 PM +0200 Mathias B <[email protected]> 
wrote:

> Hi
>
> Just thought somebody might want to know...
> I saw this post, and even though it said it was for the 2.4 kernel i
> thought i  would try it out (i'm running 2.6.4) as i am having some small
> problems with  my smc2835w. I copied the patch into
> drivers/pcmcia/yenta_socket.c at the  spot in yenta_allocate_res() that
> looked about right and changed  BRIDGE_SIZE_MIN to BRIDGE_IO_MIN as the
> compiler was complaining that this  variable didn't exist (don't now if
> it's the correct one i changed it to, but  it did compile).
>
> The result is that i am still having the same problems i had before (i
> have to  try a couple of times to get the wireless device up), but now
> the card seems  a lot snappier and it gets a link 4 or 5 times quicker
> than before (and that's  good as i also have problems with my card
> loosing the link ;) ).
>
> --
> Mvh.
> 	Mathias Bertelsen
>
>
> On Friday 07 May 2004 03:45, Alec H. Peterson wrote:
>> Sorry for the crosspost, but this issue seems to have surfaced for users
>> of both of these drivers.  And yes I know this is not describing a
>> problem with either of the drivers represented on these lists, but
>> hopefully people will find it relevant.
>>
>> I believe I have found a fix to these problems.  The root cause of the
>> problem is the fact that the BIOS in question is not aligning the memory
>> it is assigning to the CardBus slots.  So the kernel is attempting to
>> align it on its own, but then another problem comes up because in this
>> case there is only 8K of memory available, and that is how much some of
>> the cards need (in some cases they need even more).  According to the
>> yenta driver the minimum amount of memory that should be allocated to
>> each slot is 16K. Anyway, I have put a patch into drivers/pcmcia/yenta.c
>> that looks like this (in yenta_allocate_res(), kernel 2.4.25):
>>
>>         start = config_readl(socket, offset) & mask;
>>         end = config_readl(socket, offset+4) | ~mask;
>> # if 1
>>         if (!(type & IORESOURCE_IO) && (((end - start) < BRIDGE_SIZE_MIN)
>> || (start & (end - start))))
>>         {
>>                 printk(KERN_INFO "yenta %s: Preassigned resource start
>>                 %lx
>> end %lx too small or not aligned.\n", socket->dev->slot_name, start,
>> end); res->start = res->end = 0;
>>         }
>>         else
>> # endif
>>         if (start && end > start) {
>>                 res->start = start;
>>
>> Basically it is doing sanity checking on the memory that the PCI BIOS has
>> pre-allocated, and if the sanity check fails it goes ahead and allocates
>> a new block of memory (that happens automatically further along in
>> yenta_allocate_res()).  With this patch in place I can now initialize and
>> use both PrismGT and Atheros cards with no problems.
>>
>> I welcome any feedback or input about this.  If this is good, bad, or an
>> abomination against the kernel I would really like to hear about it.
>> I've sent it to the linux-kernel list as well (I received some helpful
>> suggestions there) but I have not yet had any feedback about whether or
>> not this is a good thing.  I don't have a huge variety of systems to
>> test this against so I would really love to hear how this works on other
>> systems.
>>
>> Thanks!
>>
>> Alec
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by Sleepycat Software
>> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
>> deliver higher performing products faster, at low TCO.
>> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
>> _______________________________________________
>> Madwifi-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/madwifi-users
>>
>> _______________________________________________
>> Prism54-users mailing list
>> [email protected]
>> http://prism54.org/mailman/listinfo/prism54-users
>