2.2.8/2.3.0 SCSI problems?

2.2.8/2.3.0 SCSI problems?

[Matt Porter]

I was running vger 2.2.5 with patches for Motorola support on a variety
of systems here successfully.

These patches made it into 2.3.0 so I'm testing it and finding that SCSI
support is broken.  On an MTX with a 53c875 chipset, the 2.3.0 kernel
hangs scanning the SCSI bus.  The ncr8xx driver has been updated since
2.2.5, but I get the same results if I patch the driver from 2.2.5 into
2.3.0.

Seems like it's either a generic scsi support issue or something PPC
specific.  It is reporting that PCI interrupts are set properly and all
the driver resources are allocated the same as in my 2.2.5 kernel so I'm
at a loss for answers. :-/

--
Matt Porter
mmporter@home.com


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: 2.2.8/2.3.0 SCSI problems?

[Corey Minyard]

Matt Porter <mmporter@home.com> writes:

> I was running vger 2.2.5 with patches for Motorola support on a variety
> of systems here successfully.
> 
> These patches made it into 2.3.0 so I'm testing it and finding that SCSI
> support is broken.  On an MTX with a 53c875 chipset, the 2.3.0 kernel
> hangs scanning the SCSI bus.  The ncr8xx driver has been updated since
> 2.2.5, but I get the same results if I patch the driver from 2.2.5 into
> 2.3.0.
> 
> Seems like it's either a generic scsi support issue or something PPC
> specific.  It is reporting that PCI interrupts are set properly and all
> the driver resources are allocated the same as in my 2.2.5 kernel so I'm
> at a loss for answers. :-/
> 
> --
> Matt Porter
> mmporter@home.com

I'm having the same problem with my MVME2700 with an ncr53c8xx chip.
I did a little debugging and checking.  In my previous kernel version
that I had running (2.2p4), it chose to use interrupt 14 for the chip.
In 2.2.9, it chose to use interrupt 19.  But that is the only thing I
can find.

If anyone has a solution I'd like to know.

Thanks,

-- 
Corey Minyard                   Internet:  minyard@acm.org
  Work: minyard@nortelnetworks.com  UUCP:  minyard@wf-rch.cirr.com

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: 2.2.8/2.3.0 SCSI problems?

[Matt Porter]

On 14 May 1999, Corey Minyard wrote:

> I'm having the same problem with my MVME2700 with an ncr53c8xx chip.
> I did a little debugging and checking.  In my previous kernel version
> that I had running (2.2p4), it chose to use interrupt 14 for the chip.
> In 2.2.9, it chose to use interrupt 19.  But that is the only thing I
> can find.
> 
> If anyone has a solution I'd like to know.

The change in interrupts is due to it now using the MPIC for PCI
interrupts instead of the legacy PIC support in with the MPIC
in the default passthrough mode. Raven/Hawk boards got support starting at
2.2.8 but a couple lines of code got dropped somewhere.  My patch I posted
yesterday solves this problem...it wasn't setting the interrupt handler to
the openpic code as it should.  Thus, the first PCI device that tried to
init during boot hangs the system (SCSI).  I've tested this patch on MTX,
MVME2300SC, 2400. and 2700.

--
Matt Porter
mmporter@home.com
This is Linux Country. On a quiet night, you can hear Windows reboot.


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]