lkml.org 
[lkml]   [2004]   [Mar]   [2]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
    /
    DateTue, 02 Mar 2004 08:52:27 +0200
    FromJaco Kroon <>
    SubjectRe: 2.6.3 adaptec I2O will not compile
    Eek, that does not bear good.  Somebody else mailed me this patch, so 
    would you mind sending me your orriginal patch for comparison?
    
    And I assume that the scsi_unregister call should in fact not be in 
    there?  If I understand it correctly there is either some function that 
    first calls adpt_release (from the address given in the info struct) and 
    then scsi_unregister, or scsi_unregister itself calls us.
    
    Btw, none of this code was yet incorporated into the 2.6.3 kernel which 
    is why I started looking around for patches and actually looking at 
    making the changes myself.  Btw, I also note that a couple of free's has 
    moved around - this gives me the idea that either a memory corruption 
    bug has been fixed (which leaves at least two of our machines in danger 
    of crashing) or a memory leak has been introduced.  Or is it simply that 
    memory handling has been optimized a bit?
    
    Jaco
    
    Salyzyn, Mark wrote:
    
    >My code fragment has (original multiversion and version in 2.4.24):
    >
    >/*
    > * scsi_unregister will be called AFTER we return.
    > */
    >static int adpt_release(struct Scsi_Host *host)
    >{
    >        adpt_hba* pHba = (adpt_hba*) host->hostdata[0];
    >//      adpt_i2o_quiesce_hba(pHba);
    >        adpt_i2o_delete_hba(pHba);
    >        return 0;
    >}
    >
    >So I am unsure as to how *that* (the scsi_unregister call) got in there
    >in the 2.6.3 stream. adpt_i2o_queisce was commented out in version 2.4.5
    >of the driver (Prior to the `historical documents' and at least the
    >in-box driver for RH7.3). It was not part of the 2.6.2 tree I based my
    >patch on and not part of the submitted 2.6 patch for the dpt_i2o driver.
    >
    >adpt_i2o_quiesce tells the adapter to stop all activity, including
    >builds, and is a blocking command with a 4 minute timeout.
    >
    >Sincerely -- Mark Salyzyn
    >
    >-----Original Message-----
    >From: David Lang [mailto:david.lang@digitalinsight.com] 
    >Sent: Thursday, February 26, 2004 5:24 AM
    >To: Salyzyn, Mark; Jaco Kroon
    >Cc: Adrian Bunk; Linux Kernel Mailing List
    >Subject: Re: 2.6.3 adaptec I2O will not compile
    >
    >Mark, do you have any comments on this?
    >
    >On Thu, 26 Feb 2004, Jaco Kroon wrote:
    >
    > 
    >
    >>Date: Thu, 26 Feb 2004 01:28:14 -0800
    >>From: Jaco Kroon <jkroon@cs.up.ac.za>
    >>To: David Lang <david.lang@digitalinsight.com>
    >>Cc: Adrian Bunk <bunk@fs.tum.de>,
    >>     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
    >>Subject: Re: 2.6.3 adaptec I2O will not compile
    >>
    >>David Lang wrote:
    >>
    >> 
    >>
    >>>I received a post from Mark Salyzyn with a new driver that does
    >>> 
    >>>
    >>compile,
    >> 
    >>
    >>>he said that he has submitted the patches (I didn't get a chance to
    >>> 
    >>>
    >try
    > 
    >
    >>>the new kernel yet, I expect to do that shortly and will report any
    >>>problems)
    >>>
    >>>D
    >>>
    >>> 
    >>>
    >>Somebody just mailed me a patch too, but I found the following
    >>discrepancy:
    >>
    >>/*
    >> * scsi_unregister will be called AFTER we return.
    >> */
    >>static int adpt_release(struct Scsi_Host *host)
    >>{
    >>    adpt_hba* pHba = (adpt_hba*) host->hostdata[0];
    >>//  adpt_i2o_quiesce_hba(pHba);
    >>    adpt_i2o_delete_hba(pHba);
    >>    scsi_unregister(host);
    >>    return 0;
    >>}
    >>
    >>This is used to release the host, now read the comment, and then the
    >>line just before the return.  This line was added by the patch, which
    >>also commented out the quiesce line.  Is it possible to get any
    >>confirmation on how this is supposed to function?
    >>
    >>Jaco
    >>
    >>===========================================
    >>This message and attachments are subject to a disclaimer. Please refer
    >>to www.it.up.ac.za/documentation/governance/disclaimer/ for full
    >>details.
    >>Hierdie boodskap en aanhangsels is aan 'n vrywaringsklousule
    >> 
    >>
    >onderhewig.
    > 
    >
    >>Volledige besonderhede is by
    >>www.it.up.ac.za/documentation/governance/disclaimer/ beskikbaar.
    >>===========================================
    >>
    >>
    >> 
    >>
    >
    > 
    >
    
    -- 
    That that is is that that is not is not.
    ===========================================
    This message and attachments are subject to a disclaimer. Please refer to www.it.up.ac.za/documentation/governance/disclaimer/ for full details.
    Hierdie boodskap en aanhangsels is aan 'n vrywaringsklousule onderhewig. Volledige besonderhede is by www.it.up.ac.za/documentation/governance/disclaimer/ beskikbaar.
    ===========================================
    [unhandled content-type:application/x-pkcs7-signature]
    \
     
     \ /
      Last update: 2005-03-22 14:01    [from the cache]
    ©2003-2008