;-)
> 2) Has been unbreakable with my testings on my machine.
OK. So it at least works one place.
> 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.
I must have overlooked that, or ignored it because it didn't seem to
confer any benefit (for me).
> 4) pre-2.1.127-3 was broken with cc1 internal error in sched.c for me.
Yep, I had that too :-(
> 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
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.
> PS: BTW, it _is_ a flame.
Well, not really. It seemed that the breakage was rather extreme (BTW:
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.
Regards,
Richard....
CONFIG_SCSI_NCR53C8XX=y
CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=8
CONFIG_SCSI_NCR53C8XX_MAX_TAGS=4
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
-
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/