Le mercredi 5 juin 2002 vers 8:19, Michel Lanners écrivait :
> On 4 Jun, this message from Antoine Delvaux echoed through
> cyberspace:
>> Since two days I've been in touch with the developper of the eata.c
>> driver (Ballabio Dario) and he gave me a few debug version of that
>> driver to play with. Unfortunately we have come to a point where he
>> can't do more since the problem seems to come from PCI code of the
>> ppc kernel tree.
>>
>> If anyone here have experience in this field, I welcome his advices
>> as do not know where to start to search. With the latest debugging
>> enabled eata.c module given by Ballabio, I've got the following
>> output :
>
> I had some similar problems when trying to make a Promise IDE card
> work in my Mac... but that was a few years ago.
>
>> # insmod eata.o io_port=0x1400
> ^^^^^^
> Where are you getting this value from? I'm sure it is wrong... Have a
> look at the boot messages of your kernel, and also send along the
> output of 'lspci -vv'.
I'm getting this addresse from lspci and from previous tries with
modprobe eata.o (which gives exactly the same results as insmod BTW)
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-
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]
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
>
> This message means you are trying to read from an address where no
> device is listening. Either the IO port (0x1408) is wrong, or the
> device isn't configured to reply to IO accesses on the PCI bus.
Why could the device not be configured to reply to IO accesses on the
PCI bus ?
>> And here is his answer :
>>
>> ------------ The message IN from bad port 1408 at d005392c comes from
>> linux/arch/ppc/kernel/traps.c (about line 162, inside #ifdef
>> CONFIG_ALL_PPC) It looks like your setup is not able to read a single
>> byte from location 0x1408. This is what I'm trying to do to see if
>> the board is there (inb(0x1400 + eata_reg_offset). So either you can
>> fix your hw/kernel parameters in order to allow inb() from a legal
>> I/O port address,
>
> There's no such thing as legal I/O port address on powerpc. I/O ports
> are just another memory-mapped device; and accessing non-existing
> memory dosn't work on any machine ;-).
>
>> otherwise there is nothing I can do for you. I had a look to the
>> sources of the other 2 scsi drivers you use (mesh and mac53C94) and
>> they use an approach to I/O very specific to the MAC architecture.
>> Nothing that can be implemented in the EATA driver without a full
>> rewrite. -------------
>>
>> I do not know where to start, is the inb() function supposed to do
>> exactly the same on i386 and ppc ? Where could the problem come from
>> ?
>
> inb() works as expected as long as you feed it the right port value.
>
> 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.
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)...
Antoine.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
