Re: [Madwifi-users] PCI memory reservation failures

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 
alot 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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBAnSheRyiS5YyoyKkRAhwwAJ9CGn6Bo1HaKD92ApH1pLudt6U2kwCgsVCV
vlCpXY9WWV8Ki+eL/0UBJDM=
=mUHJ
-----END PGP SIGNATURE-----