Re: 2.6.12-rc3 won't boot from aic7899

From: James Bottomley (James.Bottomley_at_SteelEye.com)
Date: 04/28/05

  • Next message: Ram: "Re: [PATCH] private mounts" 
    To: "K.R. Foley" <kr@cybsft.com>
Date:	Thu, 28 Apr 2005 12:30:11 -0700

    On Fri, 2005-04-22 at 22:50 -0500, K.R. Foley wrote:
    > scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36
    > <Adaptec aic7899 Ultra160 SCSI adapter>
    > aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs
    >
    > Vendor: SEAGATE Model: SX118273LC Rev: 6679
    > Type: Direct-Access ANSI SCSI revision: 02
    > scsi1:A:0:0: Tagged Queuing enabled. Depth 32
    > target1:0:0: Beginning Domain Validation
    > (scsi1:A:0): 6.600MB/s transfers (16bit)
    > (scsi1:A:0:0): parity error detected in Data-in phase. SEQADDR(0x6b)
    > SCSIRATE(0x80)

    I assume it just locks up after this?

    It looks like the parity error isn't propagating upwards like it should.
    What did a 2.6.11 boot sequence show for this (i.e. did the internal
    aic7xxx DV configure the device narrow)?

    I suspect the attached patch might fix this in the core driver, if you
    could try it out.

    Thanks,

    James

    --- k/drivers/scsi/aic7xxx/aic7xxx_core.c (mode:100644)
    +++ l/drivers/scsi/aic7xxx/aic7xxx_core.c (mode:100644)
    @@ -1125,16 +1125,9 @@ ahc_handle_scsiint(struct ahc_softc *ahc
                             else
                                     ahc_outb(ahc, MSG_OUT, mesg_out);
                     }
    - /*
    - * Force a renegotiation with this target just in
    - * case we are out of sync for some external reason
    - * unknown (or unreported) by the target.
    - */
    - ahc_fetch_devinfo(ahc, &devinfo);
    - ahc_force_renegotiation(ahc, &devinfo);
    -
    - ahc_outb(ahc, CLRINT, CLRSCSIINT);
    - ahc_unpause(ahc);
    + if (scb != NULL)
    + ahc_set_transaction_status(scb, CAM_UNCOR_PARITY);
    + ahc_reset_channel(ahc, devinfo.channel, TRUE);
             } else if ((status & SELTO) != 0) {
                     u_int scbptr;
     

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Ram: "Re: [PATCH] private mounts"

    Relevant Pages

    • Re: 2.6.11-rc3-mm1
      ... >> hangs. ... > That's very strange... ... boot sequence. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Really annoying bug in the mouse driver
      ... Processor load we usually handle well, loaded disks are usually the ... KBC then would not detect parity error and psmouse would ... I was wondering if you hit parity error twice in a row and it ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [BUG][Resend] 2.6.12-rc3-mm3: Kernel BUG at "mm/slab.c":1219
      ... >> boot sequence? ... > The funny thing is that it seems to be the name being NULL, ... smells like bad code generation or hardware. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: 2.6.0 vs. vga option
      ... Give my latest patch a try. ... > some to compile as modules, so that early in the boot sequence the screen ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: 2.6.14-rc5-mm1
      ... If the parity error is real then it would indicate a bad PCI transfer ... some vendors don't use PCI parity checking much and some card vendors ... That'll help the EDAC folk build up a view ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)