> Gerard Roudier writes:
>
> > 2) Has been unbreakable with my testings on my machine.
>
> OK. So it at least works one place.
Is this still a flame?
>
> > 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!
> > 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.
> > 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.
> 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.
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.
> CONFIG_SCSI_NCR53C8XX_SYNC=20
> # CONFIG_SCSI_NCR53C8XX_PROFILE is not set
> # CONFIG_SCSI_NCR53C8XX_IOMAPPED is not set
> # CONFIG_SCSI_NCR53C8XX_SYMBIOS_COMPAT is not set
Regards,
Gerard.
-
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/