Arrggh! No! I already said it wasn't meant to be a flame. What I mean
is that it is therefore known to work under at least one
configuration. That's information that may (or may not) be useful.
I'm musing over the problem, not flaming.
> > > 3) Patch sent to both linux-scsi and linux-kernel lists (on oct 25) 4 days
>
> Was in fact on 21 october. First break report 2 weeks later, with
> suspicion changes haven't been tested directly sent to public lists.
> Very nice!
Erm, assuming this is sarcasm, please read again my comments where I
explained it was a simple question and why I thought it might be
untested.
> > > before sending it to Linus. No breakage report until this timeout
> > > problem.
> >
> > I must have overlooked that, or ignored it because it didn't seem to
> > confer any benefit (for me).
>
> If pissing into a violin will have same effect as submitting patches to
> linux lists for testing before committing changes, I will purchase a
> violin and unsubscribe from these lists. That will spare time to me
> being given all the off-topic these lists are flooded with.
Sigh. Calm down. I'm not trying to denegrate your work. Just try to
see it from the other point of view: downloading/applying every patch
that comes out is not something we all have time for.
It's no good apportioning blame in this context, as each "side" has
different needs, each valid. It's an imperfect world and we just have
to make the best of it ;-)
> > > 5) pre-2.1.127-7 with NCR-3.1a default settings works on my machine with
> > > no timeouts at all.
> >
> > Hm. I'll append my .config in case that yields a clue.
> >
> > > If kernel and sci list subscribers just discard partial patches and
> > > wait for global kernel patches before testing, what can I do ?
> >
> > I sympathise. Unfortunately it's a bit of work to download patches to
> > different subsystems. In my case it's even more work since my working
>
> The patch was an attachment, so apart the mail nothing had to be
> downloaded.
OK, I guess I should have been more precise. Yes, downloading is an
added burden, but even when the patch is in my mailbox, applying the
patch does present me with problems (as I explained below).
> > kernel tree contains devfs. Maintaining or dealing with multiple
> > kernel patches is a pain (my life became much easier when the MTRR
> > code went in).
> > Nevertheless, that doesn't help you when it comes to getting your code
> > tested, I'll agree.
>
> I understand all of that.
>
> > I suspect reads are OK but writes trigger the timeout, but I've not
> > tested this suspicion), so I thought that maybe the breakage was
> > universal, in which case it may have been an untested "this looks
> > right" style patch. We've seen those before ;-) That's why I asked.
> > I guess something more subtle is happening, in which case it may be a
> > configuration-related problem.
>
> > CONFIG_SCSI_NCR53C8XX=y
> > CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=8
> > CONFIG_SCSI_NCR53C8XX_MAX_TAGS=4
>
> A default value of 8 for a max value of 4 for the same thing is
> bogus.
Hm. I think this is an artefact of using make oldconfig: originally
there was the MAX_TAGS option IIRC and I took the default value of
4. Later the DEFAULT_TAGS option came along and I took the default
again. Since that new option came first, I didn't realise there was an
inconsistency. Once I selected the default for the new option,
make oldconfig would zoom past the MAX_TAGS option.
While I agree that config is bogus, I think it would be a good idea
for the driver to safely handle such a misconfiguration. Even if the
driver refuses to compile and a rude message is generated (hence no
object code bloat) would be fine, I think.
My concern is that it's aparrentely fairly easy to generate this
misconfiguration.
> Will try your bogus config and let you know how it behaves on my
> system. You also could give a try with a DEFAULT_TAGS=4 instead of
> 8 and let me know if it makes difference.
OK, I can do that. Would it be better to set both to 8 instead? What
do you use?
Regards,
Richard....
-
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/