Messages in this thread | | | Date | Sat, 11 Sep 1999 14:43:29 +0200 (MET DST) | From | Andries.Brouwer@cwi ... | Subject | Re: Adaptec 1542 and kernel 2.2.11&12 not working? |
| |
tommiy@ozemail.com.au writes:
: I have an old aha1542 card thats driving a sony dat drive, with all the : scsi options set for module and under kernel 2.2.9 everything works : fine. : However, if I use kernel 2.2.11 or 2.2.12 then it will not find the : scsi card at boot time and I cannot convince it to find it at all using : modprobe or insmod.
I am not surprised - patch-2.2.11 contains a very strange patch on aha1542.c by Chris Faulhaber. Maybe it somehow was munged. Anyway, the easiest is to just revert it.
(Let us look at the patch:
+#ifdef MODULE + bases[0] = 4; + bases[1] = aha1542[0]; + bases[2] = aha1542[1]; + bases[3] = aha1542[2]; + bases[4] = aha1542[3]; +#endif
and the declaration of bases:
#define MAXBOARDS 2 static unsigned int bases[MAXBOARDS]={0x330, 0x334};
So, it seems this will scribble on memory past bases. Also: bases[] contains the addresses being probed for. But the patch has
+#if defined(MODULE) +int aha1542[] = { 0x330, 11, 4, -1 }; +MODULE_PARM(aha1542, "1-4i"); +#endif
numbers that do not look like bases at all. Maybe this was copied from some other driver and happened to do what the patcher wanted?)
Andries
P.S. patch-2.2.11 contains one other change to aha1542.c, namely
- if(mbenable_result[1] & 0x03) retval = BIOS_TRANSLATION_25563; + if((mbenable_result[0] & 0x08) && (mbenable_result[1] & 0x03)) + retval = BIOS_TRANSLATION_25563;
I do not think this is precisely right, but certainly the new code is better than the old, so this part of the patch should not be reverted.
Andries
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |