> Gerard Roudier writes:
> >
> > On Thu, 5 Nov 1998, Richard Gooch wrote:
> >
> > It should be interesting to have results using driver 3.0i and 3.1a on the
> > same kernel version and configuration, for example:
> >
> > - linux-2.1.126 that has driver 3.0i
> > - linux-2.1.126 patched for driver 3.1a
> >
> > Patch location:
> > ftp://ftp.tux.org/pub/roudier/ncr53c8xx-3.0i-to-3.1a-for-linux-2.1.125.patch.gz
> >
> > And you may want to also compile the kernel using gcc-2.7.x if driver 3.1a
> > has the timeout problem. If booting with tags disabled, asynchronous
> > transfers, etc..., makes difference, this may also help find the cause
> > of the problem.
>
> I've tried plain 2.1.127-pre7 (which has NCR 3.1a) and that fails.
> I then tried 2.1.127-pre7 with the 3.0i driver (from 2.1.127-pre1) and
> that works fine.
> So the problem looks like being with v3.1a of the NCR driver.
Ok.
> I use gcc 2.7.2.1, always.
>
> BTW: this isn't meant as a flame, but was NCR 3.1a tested before going
> into the kernel?
That is indeed the question I ask me at the moment.
1) NCR 3.1a looked like code simplification and trivial changes to me.
2) Has been unbreakable with my testings on my machine.
3) Patch sent to both linux-scsi and linux-kernel lists (on oct 25) 4 days
before sending it to Linus. No breakage report until this timeout
problem.
4) pre-2.1.127-3 was broken with cc1 internal error in sched.c for me.
5) pre-2.1.127-7 with NCR-3.1a default settings works on my machine with
no timeouts at all.
If kernel and sci list subscribers just discard partial patches and wait
for global kernel patches before testing, what can I do ?
Regards,
Gerard.
PS: BTW, it _is_ a flame.
-
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/