[Madwifi-users] Re: [Prism54-users] PCI memory reservation failures

[Luis R. Rodriguez]

--y0ulUmNC+osPPQO6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


Hello Alec,

Post/fwd this to the netdev@oss.sgi.com. You'll get more=20
replies there with people with more experience.=20

	Luis

On Thu, May 06, 2004 at 07:45:41PM -0600, Alec H. Peterson wrote:
> Sorry for the crosspost, but this issue seems to have surfaced for users =
of=20
> both of these drivers.  And yes I know this is not describing a problem=
=20
> with either of the drivers represented on these lists, but hopefully peop=
le=20
> will find it relevant.
>=20
> I believe I have found a fix to these problems.  The root cause of the=20
> problem is the fact that the BIOS in question is not aligning the memory =
it=20
> is assigning to the CardBus slots.  So the kernel is attempting to align =
it=20
> on its own, but then another problem comes up because in this case there =
is=20
> only 8K of memory available, and that is how much some of the cards need=
=20
> (in some cases they need even more).  According to the yenta driver the=
=20
> minimum amount of memory that should be allocated to each slot is 16K.=20
> Anyway, I have put a patch into drivers/pcmcia/yenta.c that looks like th=
is=20
> (in yenta_allocate_res(), kernel 2.4.25):
>=20
>        start =3D config_readl(socket, offset) & mask;
>        end =3D 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=
=20
> end %lx too small or not aligned.\n", socket->dev->slot_name, start, end);
>                res->start =3D res->end =3D 0;
>        }
>        else
> #endif
>        if (start && end > start) {
>                res->start =3D start;
>=20
> Basically it is doing sanity checking on the memory that the PCI BIOS has=
=20
> pre-allocated, and if the sanity check fails it goes ahead and allocates =
a=20
> new block of memory (that happens automatically further along in=20
> yenta_allocate_res()).  With this patch in place I can now initialize and=
=20
> use both PrismGT and Atheros cards with no problems.
>=20
> I welcome any feedback or input about this.  If this is good, bad, or an=
=20
> abomination against the kernel I would really like to hear about it.  I'v=
e=20
> sent it to the linux-kernel list as well (I received some helpful=20
> suggestions there) but I have not yet had any feedback about whether or n=
ot=20
> this is a good thing.  I don't have a huge variety of systems to test thi=
s=20
> against so I would really love to hear how this works on other systems.
>=20
> Thanks!
>=20
> Alec
>=20
> _______________________________________________
> Prism54-users mailing list
> Prism54-users@prism54.org
> http://prism54.org/mailman/listinfo/prism54-users

--=20
GnuPG Key fingerprint =3D 113F B290 C6D2 0251 4D84  A34A 6ADD 4937 E20A 525E

--y0ulUmNC+osPPQO6
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFAnxgwat1JN+IKUl4RAoejAKCBakQ6An0mpM8Iapex1B5Zh0Nz7QCdEhDE
PYY460TdEYpG1NV5D0COoqg=
=znjK
-----END PGP SIGNATURE-----

--y0ulUmNC+osPPQO6--


-------------------------------------------------------
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
Madwifi-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/madwifi-users