All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@digeo.com>
To: Doug Ledford <dledford@redhat.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: aix7xxx_old woes in 2.5
Date: Mon, 16 Dec 2002 02:39:14 -0800	[thread overview]
Message-ID: <3DFDAD52.BB836AA4@digeo.com> (raw)
In-Reply-To: 20021216074008.GC13989@redhat.com

Doug Ledford wrote:
> 
> On Sat, Dec 14, 2002 at 08:36:25PM -0800, Andrew Morton wrote:
> >
> > ho hum.
> >
> > It just doesn't start at all:
> >
> > scsi HBA driver <NULL> didn't set max_sectors, please fix the template<6>(scsi0) <Adaptec AIC-7892 Ultra 160/m SCSI host adapter> found at PCI 3/4/0
> > (scsi0) Wide Channel, SCSI ID=7, 32/255 SCBs
> > (scsi0) Downloading sequencer code... 396 instructions downloaded
> > (scsi1) <Adaptec AIC-7880 Ultra SCSI host adapter> found at PCI 0/10/0
> > (scsi1) Wide Channel, SCSI ID=7, 16/255 SCBs
> > (scsi1) Downloading sequencer code... 436 instructions downloaded
> > scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.6/5.2.0
> >        <Adaptec AIC-7892 Ultra 160/m SCSI host adapter>
> > scsi: Device offlined - not ready or command retry failed after error recovery: host 0 channel 0 id 0 lun 0
> > scsi: Device offlined - not ready or command retry failed after error recovery: host 0 channel 0 id 1 lun 0
> > scsi: Device offlined - not ready or command retry failed after error recovery: host 0 channel 0 id 2 lun 0
> > scsi: Device offlined - not ready or command retry failed after error recovery: host 0 channel 0 id 3 lun 0
> > scsi: Device offlined - not ready or command retry failed after error recovery: host 0 channel 0 id 4 lun 0
> > scsi: Device offlined - not ready or command retry failed after error recovery: host 0 channel 0 id 5 lun 0
> > scsi: Device offlined - not ready or command retry failed after error recovery: host 0 channel 0 id 6 lun 0
> > scsi: Device offlined - not ready or command retry failed after error recovery: host 0 channel 0 id 8 lun 0
> >
> > (The above took three minutes or more)
> 
> Interrupt routing problems is what that looks like to me, not driver
> problems.  Try booting with different interrupt settings or with a
> different kernel (smp vs. up, that sort of thing).

Uniprocessor, no IO-APIC.  No go:

           CPU0       
  0:     736412          XT-PIC  timer
  1:         15          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  4:          0          XT-PIC  GDB-stub
  8:          1          XT-PIC  rtc
 11:        294          XT-PIC  ide2, ide3, ide4, ide5, aic7xxx, aic7xxx, eth0
 12:         52          XT-PIC  i8042
 14:       2848          XT-PIC  ide0
 15:          8          XT-PIC  ide1
NMI:          0 
ERR:          0

(Doesn't this rule out your theory?  If it's asserting the IRQ, we will
take an interrupt with this configuration?)

Uniprocessor, IO-APIC:

           CPU0       
  0:     654721    IO-APIC-edge  timer
  1:         15    IO-APIC-edge  i8042
  2:          0          XT-PIC  cascade
  4:          0    IO-APIC-edge  GDB-stub
  8:          1    IO-APIC-edge  rtc
 12:         55    IO-APIC-edge  i8042
 14:       2835    IO-APIC-edge  ide0
 15:         10    IO-APIC-edge  ide1
 19:         43   IO-APIC-level  ide2, ide3, ide4, ide5
 35:          0   IO-APIC-level  aic7xxx
 38:        296   IO-APIC-level  eth0
 58:        137   IO-APIC-level  aic7xxx
NMI:        668 
LOC:     654631 
ERR:          0
MIS:          0


I assume SMP/IO-APIC will do the same thing (takes too darn long
to go through them all).

Why should aic7xxx_old have this problem, and not aic7xxx?

Here's /proc/interrupts with aic7xxx, uniproc, IO-APIC:

           CPU0       
  0:      38650    IO-APIC-edge  timer
  1:         16    IO-APIC-edge  i8042
  2:          0          XT-PIC  cascade
  4:          0    IO-APIC-edge  GDB-stub
  8:          1    IO-APIC-edge  rtc
 12:         55    IO-APIC-edge  i8042
 14:       2726    IO-APIC-edge  ide0
 15:         10    IO-APIC-edge  ide1
 19:         43   IO-APIC-level  ide2, ide3, ide4, ide5
 35:        391   IO-APIC-level  aic7xxx
 38:        115   IO-APIC-level  eth0
 58:        284   IO-APIC-level  aic7xxx
NMI:         48 
LOC:      38516 
ERR:          0
MIS:          0

Just the same, only this time it's generating interrupts.
I don't think this is a mainboard problem.

The logs say:


scsi HBA driver <NULL> didn't set max_sectors, please fix the template
(scsi0) <Adaptec AIC-7892 Ultra 160/m SCSI host adapter> found at PCI 3/4/0
(scsi0) Wide Channel, SCSI ID=7, 32/255 SCBs
(scsi0) Downloading sequencer code... 396 instructions downloaded
(scsi1) <Adaptec AIC-7880 Ultra SCSI host adapter> found at PCI 0/10/0
(scsi1) Wide Channel, SCSI ID=7, 16/255 SCBs
(scsi1) Downloading sequencer code... 436 instructions downloaded
scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.6/5.2.0
       <Adaptec AIC-7892 Ultra 160/m SCSI host adapter>
scsi: Device offlined - not ready or command retry failed after error recovery: host 0 channel 0 id 0 lun 0
scsi: Device offlined - not ready or command retry failed after error recovery: host 0 channel 0 id 1 lun 0

Maybe the 7892 sequencer code is bust??

  reply	other threads:[~2002-12-16 10:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-15  4:36 aix7xxx_old woes in 2.5 Andrew Morton
2002-12-16  7:40 ` Doug Ledford
2002-12-16 10:39   ` Andrew Morton [this message]
2002-12-16 18:01 ` Mark Haverkamp

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=3DFDAD52.BB836AA4@digeo.com \
    --to=akpm@digeo.com \
    --cc=dledford@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.