public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: "Justin T. Gibbs" <gibbs@scsiguy.com>
To: Andrew Morton <akpm@digeo.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: aic7xxx woes in 2.5
Date: Mon, 16 Dec 2002 11:52:26 -0700	[thread overview]
Message-ID: <32310000.1040064745@aslan.btc.adaptec.com> (raw)
In-Reply-To: <3DFD9F89.4B994586@digeo.com>

> The driver still has a serious bug in ahc_linux_queue_recovery_cmd().
> It does
> 
> 	ahc_unlock(ahc, &s);

The sole ahc_unlock() in that routine looks like this:

#if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,0)
                ahc_unlock(ahc, &s);
#else
                spin_unlock_irq(ahc->platform_data->host->host_lock);
#endif

Since you are running 2.5.X, the ahc_unlock never occurs.
In 2.4.X, ahd_midlayer_entrypoint_lock() saves the cpu flags
for us, so the variable is never uninitialized in the case
where it actually is compiled in.

> The driver got through recognising the disks and then locked up
> strangely:
> 
> Program received signal SIGEMT, Emulation trap.
> cache_alloc_refill (cachep=0xd00675a0, flags=0) at
> include/linux/list.h:127 127             prev->next = next;
> (gdb) bt
># 0  cache_alloc_refill (cachep=0xd00675a0, flags=0) at
># include/linux/list.h:127 1  0x00000246 in ?? ()
># 2  0xc0135947 in kmalloc (size=256, flags=0) at mm/slab.c:1652
># 3  0xc0239835 in ahc_linux_dv_inq (ahc=0xc175e400, cmd=0xc3dd0c00,
># devinfo=0xc3d77fb0, targ=0xc3dcee00, request_length=96)
>     at drivers/scsi/aic7xxx/aic7xxx_osm.c:3303
># 4  0xc0237f5d in ahc_linux_dv_target (ahc=0xc175e400, target_offset=4)
># at drivers/scsi/aic7xxx/aic7xxx_osm.c:2060 5  0xc0237d47 in
># ahc_linux_dv_thread (data=0xc175e400) at
># drivers/scsi/aic7xxx/aic7xxx_osm.c:1955
> 
> This is an NMI watchdog interrupt.  In here:
> 
> 1571                    while (slabp->inuse < cachep->num && batchcount--)
> 1572                            ac_entry(ac)[ac->avail++] =
> 1573                                    cache_alloc_one_tail(cachep,
> slabp);
> 
> Presumably due to errors in use of slab-allocated memory.

I'll look into this today.

> I can debug further if you like, but would really appreciate unified
> diffs, thanks.

Against???  That's the whole problem with diffs.  Every person wants them
against something different.  If you can use BK, the  James Bottomley 
has integrated the latest driver into here:

http://linux-scsi.bkbits.net/scsi-aic7xxx-2.5

I have not pulled down this repro to verify it yet though.

--
Justin

  reply	other threads:[~2002-12-16 18:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-15  4:31 aic7xxx woes in 2.5 Andrew Morton
2002-12-15  6:06 ` Ishikawa
2002-12-15  6:48   ` Andrew Morton
2002-12-15 13:48     ` Ishikawa
2002-12-15 20:17   ` Justin T. Gibbs
2002-12-15 20:09 ` Justin T. Gibbs
2002-12-16  9:40   ` Andrew Morton
2002-12-16 18:52     ` Justin T. Gibbs [this message]
2002-12-16 19:03       ` Christoph Hellwig
2002-12-16 19:08       ` Andrew Morton
2002-12-16 19:26         ` Justin T. Gibbs

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=32310000.1040064745@aslan.btc.adaptec.com \
    --to=gibbs@scsiguy.com \
    --cc=akpm@digeo.com \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox