[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: eata.c module and PCI setup problem (RAID SCSI card)



On   5 Jun, this message from Antoine Delvaux echoed through cyberspace:
> Le mercredi 5 juin 2002 vers 8:19, Michel Lanners écrivait :
>>> # insmod eata.o io_port=0x1400
>>                           ^^^^^^
>> Where are you getting this value from?
>
> I'm getting this addresse from lspci and from previous tries with
> modprobe eata.o (which gives exactly the same results as insmod BTW)

Mmmhh...

> Here is the lspci -vv output regarding this card :
> 
> 00:0f.0 SCSI storage controller: Distributed Processing Technology
> SmartCache/Raid I-IV Controller (rev 02)
>     Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV+ VGASnoop-
               ^^^^
Here is one of your problems: IO port response is disabled.

>     ParErr- Stepping- SERR- FastB2B-
>     Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
>     <TAbort- <MAbort- >SERR- <PERR-
>     Latency: 32 (1000ns min, 2000ns max), cache line size 08
>     Interrupt: pin A routed to IRQ 25
>     BIST result: 00
>     Region 0: I/O ports at 1400 [disabled] [size=32]
                                  ^^^^^^^^^^
This has the same meaning as 'I/O-' above: the device will not answer
PCI bus IO cycles for its address. That's like talking to a wall, really
:). On PowerMacs (at least), doing this kind of things results in a
Machine Check exception (meaning literally: 'Your computer is broken.
Fix it' :)

>     Expansion ROM at 80908000 [disabled] [size=32K]
> 
>>> # tail /var/log/syslog Jun  4 13:52:38 brocoli kernel: IN from bad
>>> port 1408 at d005392c

Luckily, accesses to IO ports where no device answers are caught by the
exception handler and reported like you have seen above.

>> I've looked at the code a bit; can you try to recompile the eata
>> module with DEBUG_PCI_DETECT defined, and send the kernel's log
>> output? Also, try an insmod without the io= option.
> 
> I already have 
> 
> #define  DEBUG_DETECT
> #define  DEBUG_PCI_DETECT
> 
> in the module source.  That doesn't output much though... 
> 
> Jun  5 09:23:22 brocoli kernel: >IN from bad port 338 at d006092c
> Jun  5 09:23:22 brocoli kernel: IN from bad port 338 at d006092c
> Jun  5 09:23:22 brocoli last message repeated 452 times
> Jun  5 09:23:22 brocoli kernel: EATA0: detect, do_dma failed at 0x330.

Is there any particular reason why you have different IO ports now?

> I also tried to put the card in another PCI slot (already in use before,
> I swaped two cards) and I've got the same result (when doing a
> modprobe)...

That won't help in a 7500; the three PCI slots are 100% identical.

On   5 Jun, this message from Geert Uytterhoeven echoed through cyberspace:
> Apparently your PowerMac doesn't support PCI I/O??

Na, nonsense. For once Apple respected some standards and made the PCI
bus really do IO cycles :)

Antoine, why are you not getting any output from this code:

static void add_pci_ports(void) {
#if defined(CONFIG_PCI)
   unsigned int addr, k;
   struct pci_dev *dev = NULL;
   if (!pci_present()) return;
   for (k = 0; k < MAX_PCI; k++) {
      if (!(dev = pci_find_class(PCI_CLASS_STORAGE_SCSI << 8, dev))) break;
      if (pci_enable_device (dev)) {
#if defined(DEBUG_PCI_DETECT)
         printk("%s: detect, bus %d, devfn 0x%x, pci_enable_device failed.\n",
                driver_name, dev->bus->number, dev->devfn);
#endif
         continue;
         }
      addr = pci_resource_start (dev, 0);
#if defined(DEBUG_PCI_DETECT)
      printk("%s: detect, seq. %d, bus %d, devfn 0x%x, addr 0x%x.\n",
             driver_name, k, dev->bus->number, dev->devfn, addr);
#endif
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This here above should print something, shouldn't it? Are you sure you
have nothing in your logs?

      /* Order addresses according to rev_scan value */
      io_port[MAX_INT_PARAM + (rev_scan ? (MAX_PCI - k) : (1 + k))] =
             addr + PCI_BASE_ADDRESS_0;
      }
#endif /* end CONFIG_PCI */
   return;
}


Hm, also in eata2x_detect:

#if defined(MODULE)
   /* io_port could have been modified when loading as a module */
   if(io_port[0] != SKIP) {
      setup_done = TRUE;
      io_port[MAX_INT_PARAM] = 0;
      }
#endif
....
   if (!setup_done) add_pci_ports();

Which means that if you give it an io= option as a module, then the PCI
bus will not be probed, and the device will not be enabled. So, make
sure to remove any io= options when doing an insmod.

Here's something else I don't understand:

      /* Order addresses according to rev_scan value */
      io_port[MAX_INT_PARAM + (rev_scan ? (MAX_PCI - k) : (1 + k))] =
             addr + PCI_BASE_ADDRESS_0;
      }

addr + PCI_BASE_ADDRESS_0??

Later, while probing deivce type, the driver tries to do DMA with the
newly found device. That may also fail the way the driver tries to do
it.

But it's easier to debug after seing the logs produced without io=
options. You should definitely get some more debug output.

Cheers

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


--
To UNSUBSCRIBE, email to debian-powerpc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: