At 19:15 Uhr +0200 21.9.2001, Henry B. Hotz wrote:
>At 11:21 AM -0400 9/21/01, John Ruschmeyer wrote:
>>One minor issue, though, according to the Macsense website, this card has
>>64k of onboard memory. The ae probe, however, only sizes the card at 16k. =
In
>>looking at the memory sizing code, it appears that we do not even test for
>>cards having more than 32k of onboard memory. Is there a reason for this? =
Or
>>did the original author of the ae driver assume it could never happen?
>
>Email Allen Briggs if you can't find it, but there was a patch posted
>a year or two ago to fix this.  I thought it would be in the main
>deliveries by now.  The reason was simply a shortage of debugging
>time for the original author and a (probably spurious) appearance of
>a problem with probing larger size memories.

=46unny you should mention it... I was just about to build a custom 1.5.2
kernel and patch if_ae.c when I came across your mail.

I have a stack of noname half length ethernet nubus cards around that all
have 64K onboard. Back when I came up with the patch it was more a cosmetic
issue. When I put a teeny IIsi on a busy ethernet segment at work
(la.causeuse.org), though, I saw frequent buffer overruns from the ae
driver that disappeared when I applied the 64K patch.

Diffs against 1.5.2:

Index: if_ae.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/syssrc/sys/arch/mac68k/dev/if_ae.c,v
retrieving revision 1.67.26.2
diff -u -u -r1.67.26.2 if_ae.c
--- if_ae.c	2000/09/14 06:35:16	1.67.26.2
+++ if_ae.c	2001/09/22 16:01:46
@@ -37,7 +37,7 @@
 	bus_space_handle_t bsh;
 	int ofs;
 {
-	int i1, i2, i3, i4;
+	int i1, i2, i3, i4, i8;

 	/*
 	 * banks; also assume it will generally mirror in upper banks
@@ -47,11 +47,20 @@
 	i2 =3D (8192 * 1);
 	i3 =3D (8192 * 2);
 	i4 =3D (8192 * 3);
+	i8 =3D (8192 * 7);

 	bus_space_write_2(bst, bsh, ofs + i1, 0x1111);
 	bus_space_write_2(bst, bsh, ofs + i2, 0x2222);
 	bus_space_write_2(bst, bsh, ofs + i3, 0x3333);
 	bus_space_write_2(bst, bsh, ofs + i4, 0x4444);
+	bus_space_write_2(bst, bsh, ofs + i8, 0x8888);
+
+	if (bus_space_read_2(bst, bsh, ofs + i1) =3D=3D 0x1111 &&
+	    bus_space_read_2(bst, bsh, ofs + i2) =3D=3D 0x2222 &&
+	    bus_space_read_2(bst, bsh, ofs + i3) =3D=3D 0x3333 &&
+	    bus_space_read_2(bst, bsh, ofs + i4) =3D=3D 0x4444 &&
+	    bus_space_read_2(bst, bsh, ofs + i8) =3D=3D 0x8888)
+		return 8192 * 8;

 	if (bus_space_read_2(bst, bsh, ofs + i1) =3D=3D 0x1111 &&
 	    bus_space_read_2(bst, bsh, ofs + i2) =3D=3D 0x2222 &&

Back then, Allen suspected problems with cards that have fragmented buffer
memory. I have no such card, only some very old fullsize 3COM cards and an
Asant=E9 card in my SE/30 which all have 16K and run fine with the patch.

Of course, we could simply test for 64K and see if any complaints show up,
or enable the code with a kernel option.

If noone applies the patch I will send-pr.

	hauke


--
"It's never straight up and down"     (DEVO)