Linux-kernel mailing list archive 1999-36,: Re: Adaptec 1542 and kernel 2.2.11&12 not working?

# Re: Adaptec 1542 and kernel 2.2.11&12 not working?

Andries.Brouwer@cwi.nl
Sat, 11 Sep 1999 14:43:29 +0200 (MET DST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Andreas K. Huettel: "Re: ftape: update to version 4.xx sometime?"
- Previous message: Dan Hollis: "Re: > 15,000 Simultaneous Connections"
- Maybe in reply to: tommiy@ozemail.com.au: "Adaptec 1542 and kernel 2.2.11&12 not working?"
- Next in thread: Chris D. Faulhaber: "Re: Adaptec 1542 and kernel 2.2.11&12 not working?"
- Reply: Chris D. Faulhaber: "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/

- Next message: Andreas K. Huettel: "Re: ftape: update to version 4.xx sometime?"
- Previous message: Dan Hollis: "Re: > 15,000 Simultaneous Connections"
- Maybe in reply to: tommiy@ozemail.com.au: "Adaptec 1542 and kernel 2.2.11&12 not working?"
- Next in thread: Chris D. Faulhaber: "Re: Adaptec 1542 and kernel 2.2.11&12 not working?"
- Reply: Chris D. Faulhaber: "Re: Adaptec 1542 and kernel 2.2.11&12 not working?"