[9fans] MK5002MPL pc card power on problem (digital hinote 2000)

[9fans] MK5002MPL pc card power on problem (digital hinote 2000)

[Axel Belinfante]

I'm very unsucesful trying to get the toshiba MK500MPL pc card
drive to work on a digital hinote 2000 (sape should know that one :-)

in the plan9.ini I have pccard0=disabled  and explicit
lines for pcmcia[01] including irq.

I think I have traced the problem (good ol' print statements)
to the card not getting power in

   /sys/src/9/pc/devi82365.c:/^slotena

in the slotinfo called from slotena, only pp->occupied gets set,
but none of the other values. The comment in the slotena code says
that the wait's are empiral, so I'll just play a bit.

In the meantime, anyone a more constructive idea?

Thanks,
Axel.

Re: [9fans] MK5002MPL pc card power on problem (digital hinote 2000)

[Axel Belinfante]

playing with timing in slotena did not help, so far.
of course, the MK5002MPL works in a toshiba tecra 8000.
of course, an orinico wavelan card works in digital hinote ultra 2000.

below follow some symptoms, a hypothesis, a suggestion,
and some hardware details at the end.
I have no idea where to look further, so suggestions
of things to try are welcome.

Axel.

symptoms:
with the MK5002MPL in a digital hinote ultra 2000,
(configured to use #y instead of #Y -- pccard0=disabled in plan9.ini)
booting with card inserted hangs after the apm0 line is printed.
booting without card works, then inserting card and doing
cat '#y'/pcm?ctl freezes the machine.

hypothesis:
my guess is that slotena fails to put power to the
card without noticing that it fails. I base this on
the result of print statements added to slotinfo.
So, a bit later an attempt is done to read (config?)
info from the card and then it freezes in
        /sys/src/9/port/cis.c:/^readc
when it tries to execute
	*x = cis->cisbase[cis->cisskip*cis->cispos];
I guess at that point it tries to access memory from the
card and fails because the card has no power.

suggestion:
Just as a safety precaution, to avoid the freeze
due to a hanging readc, I'm tempted to suggest an
additional check in slotena, to bail out (with a warning?)
   if pp->occupied && !pp->powered
Maybe it is sufficient to set pp->enabled only
if above condition holds.
However, I do not know much about this,
and have no idea what could break when doing that.

hardware:
Unfortunately I do not have the machine here at work so
cannot report details reported by kernel about hardware.
(I thought I saved, cannot find back)
It has an internal pc card (network/modem), and
a dual external slot. Some info from memory, some from
digital legacy support doc from the website.

9load recognizes two some #Y TI .... (1131 acc. to doc)
The interesting thing is that the kernel reporst two
different #y (pcmcia) 'mode' controllers.
One of the two is reported as a i82365, other I don't recall.
According to doc, for the internal slot there is a
CL-PD6722 dual slot pcmcia controller (of which 1 slot is used)
So, I guess there is a TI1131 for the external slot
(that also works in i82365 compatible mode?)
and a CL-PD6722 for the internal slot.


I wrote:
> I think I have traced the problem (good ol' print statements)
> to the card not getting power in
> 
>    /sys/src/9/pc/devi82365.c:/^slotena
> 
> in the slotinfo called from slotena, only pp->occupied gets set,
> but none of the other values. The comment in the slotena code says
> that the wait's are empiral, so I'll just play a bit.