lkml.org 
[lkml]   [1998]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: timeouts with ncr53c8xx
    Gerard Roudier writes:
    >
    > On Sat, 7 Nov 1998, Richard Gooch wrote:
    > > 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.

    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/

    \
     
     \ /
      Last update: 2005-03-22 13:45    [W:0.025 / U:0.048 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site