Oops had done a reply instead of a reply to all...
--- Begin Message ---
Albert Lee wrote:
The patch just workarounds the "lost irq" problem by polling; not real
fix. We still need to find out why irq is lost per Mark's comment:
"This proves that the device does work correctly in most respects
Robert de Rooy wrote:
> Albert Lee wrote:
>
>> Mark Lord wrote:
>>
>>
>>> ...
>>>
>>> Mmm.. I don't know about the first failure there,
>>> but after that it gets into the "stuck DRQ" state
>>> which libata makes no attempt to handle at present.
>>>
>>>
>>
>>
>> It seems the pata_pcmcia dri
Albert Lee wrote:
Mark Lord wrote:
...
Mmm.. I don't know about the first failure there,
but after that it gets into the "stuck DRQ" state
which libata makes no attempt to handle at present.
It seems the pata_pcmcia driver is using IRQ driven PIO. Maybe Robert
could try the following
Mark Lord wrote:
> Robert de Rooy wrote:
>
>>
>> I did another try with libata pcmcia support using 2.6.22-rc5 which
>> already includes the nodata polling fix, in combination with
>> disable-dev_init_param-and-setxfermode-for-CFA.patch and the
>> timing-debug.patch
>
> ...
>
>> Jun 22 13:19:44
Robert de Rooy wrote:
I did another try with libata pcmcia support using 2.6.22-rc5 which
already includes the nodata polling fix, in combination with
disable-dev_init_param-and-setxfermode-for-CFA.patch and the
timing-debug.patch
...
Jun 22 13:19:44 localhost kernel: ata3.00: issuing IDENT
Tejun Heo wrote:
Albert Lee wrote:
libata can do most of this too by using ATA_FLAG_PIO_POLLING (doesn't
cover nodata commands tho).
Hi Tejun,
Polling of nodata commands was fixed in:
http://marc.info/?l=linux-ide&m=116546272916399&w=2
Right. Thanks for reminding me. :-)
Albert Lee wrote:
>>
>> libata can do most of this too by using ATA_FLAG_PIO_POLLING (doesn't
>> cover nodata commands tho).
>>
>
> Hi Tejun,
>
> Polling of nodata commands was fixed in:
> http://marc.info/?l=linux-ide&m=116546272916399&w=2
Right. Thanks for reminding me. :-)
--
tejun
-
To u
Mark Lord wrote:
> Robert de Rooy wrote:
>> (after applying the ide-polling experimental patch)
>>
>> With this I can declare success!! I was able to read and write to the
>> card without any problems, although I did not try to stress it.
>>
>> Jun 12 00:19:42 localhost kernel: pccard: PCMCIA card
Robert de Rooy wrote:
(after applying the ide-polling experimental patch)
With this I can declare success!! I was able to read and write to the
card without any problems, although I did not try to stress it.
Jun 12 00:19:42 localhost kernel: pccard: PCMCIA card inserted into slot 0
Jun 12 00:
Mark Lord wrote:
Russell King wrote:
Before you do, it might help to build the ide-disk module and insert
that
as well?
ARrrggghh!! Of course, that would explain the utter lack
of disk partition check messages, now wouldn't it!
Thanks Russell !
Doh! yes that would obviously help.
With
Robert de Rooy wrote:
Mark Lord wrote:
Oh crap. I did test it a couple of months ago, but my boot/root drive
is libata not IDE -- so no panic on boot with it. After booting, it
worked
just fine talking to PC-CARD CF devices using the polling.
Ok, no problem. I recompiled the kernel with li
Mark Lord wrote:
Oh crap. I did test it a couple of months ago, but my boot/root drive
is libata not IDE -- so no panic on boot with it. After booting, it
worked
just fine talking to PC-CARD CF devices using the polling.
=ml
Ok, no problem. I recompiled the kernel with libata (but without
Robert de Rooy wrote:
Mark Lord wrote:
I still don't see much evidence that interrupts are actually
functioning here.
It would be good to see /proc/interrupts before/after libata tries to
talk to it.
Let's assume for the moment that interrupts are b0rken.
The legacy IDE driver can talk to suc
Mark Lord wrote:
I still don't see much evidence that interrupts are actually
functioning here.
It would be good to see /proc/interrupts before/after libata tries to
talk to it.
Let's assume for the moment that interrupts are b0rken.
The legacy IDE driver can talk to such devices completely wi
Tejun Heo wrote:
Jun 7 21:10:29 localhost kernel: ata3.00: CFA: Memory Card Adapter,
20011212, max PIO1
Jun 7 21:10:29 localhost kernel: ata3.00: 253696 sectors, multi 0: LBA
Jun 7 21:10:29 localhost kernel: ata3.00: issuing IDENTIFY
Jun 7 21:10:29 localhost kernel: ata3.00: IDENTIFY comple
Hello,
Robert de Rooy wrote:
> Jun 7 21:10:28 localhost kernel: ata3: soft resetting port
> Jun 7 21:10:28 localhost kernel: ata3: reset complete
> Jun 7 21:10:28 localhost kernel: ATA: abnormal status 0x80 on port
> 0x00014107
> Jun 7 21:10:28 localhost kernel: ATA: abnormal status 0x80 on po
Tejun Heo wrote:
Can you test the attached patch
Here is what I get on the T41 (TI Cardbus controller) with 2.6.22-rc4 +
timing-debug.patch +
disable-dev_init_param-and-setxfermode-for-CFA.patch +
libata-dont-test-slave-register-readiness-after-srst.patch
Jun 7 21:10:28 localhost kernel: pc
Robert de Rooy wrote:
> Alan Cox wrote:
http://thread.gmane.org/gmane.linux.kernel/530099
It seems we're losing interrupts from the CFA device. Any ideas?
>>> Alan probably knows more, but ISTR some CFA PCMCIA devices that
>>> needed polling...
>>>
>>
>> Not that
Alan Cox wrote:
http://thread.gmane.org/gmane.linux.kernel/530099
It seems we're losing interrupts from the CFA device. Any ideas?
Alan probably knows more, but ISTR some CFA PCMCIA devices that needed
polling...
Not that I know of. Not devices anyway - there are embedded boxes
Alan Cox wrote:
http://thread.gmane.org/gmane.linux.kernel/530099
It seems we're losing interrupts from the CFA device. Any ideas?
Alan probably knows more, but ISTR some CFA PCMCIA devices that needed
polling...
Not that I know of. Not devices anyway - there are embedded boxes
> > http://thread.gmane.org/gmane.linux.kernel/530099
> >
> > It seems we're losing interrupts from the CFA device. Any ideas?
>
> Alan probably knows more, but ISTR some CFA PCMCIA devices that needed
> polling...
Not that I know of. Not devices anyway - there are embedded boxes with no
IRQ
Jeff Garzik wrote:
Tejun Heo wrote:
Robert de Rooy wrote:
Hmm, good question. I do not have any other PCMCIA device to test.
The only other device I have is a Cardbus Wi-Fi adapter without Linux
support (Marvell). If I insert that adapter lspci seems to list it
properly, but without resorting t
Tejun Heo wrote:
Robert de Rooy wrote:
Hmm, good question. I do not have any other PCMCIA device to test.
The only other device I have is a Cardbus Wi-Fi adapter without Linux
support (Marvell). If I insert that adapter lspci seems to list it
properly, but without resorting to ndiswrapper I have
I don't know if linux-pcmcia is members only, so this might not reach
that list.
Here are some log files...
Tejun Heo wrote:
Robert de Rooy wrote:
Hmm, good question. I do not have any other PCMCIA device to test.
The only other device I have is a Cardbus Wi-Fi adapter without Linux
suppor
Robert de Rooy wrote:
> Hmm, good question. I do not have any other PCMCIA device to test.
> The only other device I have is a Cardbus Wi-Fi adapter without Linux
> support (Marvell). If I insert that adapter lspci seems to list it
> properly, but without resorting to ndiswrapper I have no way of t
Hmm, good question. I do not have any other PCMCIA device to test.
The only other device I have is a Cardbus Wi-Fi adapter without Linux
support (Marvell). If I insert that adapter lspci seems to list it
properly, but without resorting to ndiswrapper I have no way of testing
it. In any case, se
Robert de Rooy wrote:
> This gets a little bit further again, but now I get lots of new errors
Alright, this doesn't seem to be the CF reader's problem anymore. It
seems the PCMCIA controller isn't passing interrupts properly. Does any
other device work in the slot?
--
tejun
-
To unsubscri
This gets a little bit further again, but now I get lots of new errors
** 2.6.22rc1-git5 + timing-debug.patch +
disable-dev_init_param-and-setxfermode-for-CFA.patch
May 21 16:58:06 localhost kernel: pccard: PCMCIA card inserted into slot 0
May 21 16:58:06 localhost kernel: cs: memory probe
Alan Cox wrote:
> On Mon, May 21, 2007 at 01:50:48PM +0200, Tejun Heo wrote:
>>> May 20 23:02:56 localhost kernel: ata3.00: qc timeout (cmd 0xef)
>>> May 20 23:02:56 localhost kernel: ata3.00: failed to set xfermode
>>> (err_mask=0x4)
>> Hmmm... It doesn't like SETXFERMASK either. Please try the a
On Mon, May 21, 2007 at 01:50:48PM +0200, Tejun Heo wrote:
> > May 20 23:02:56 localhost kernel: ata3.00: qc timeout (cmd 0xef)
> > May 20 23:02:56 localhost kernel: ata3.00: failed to set xfermode
> > (err_mask=0x4)
>
> Hmmm... It doesn't like SETXFERMASK either. Please try the attached patch.
Robert de Rooy wrote:
> Thanks for looking into this!
>
> I tried the patches on 2.6.22rc1-git5. The second patch unfortunately
> did not resolve the issue, although it seems to get a bit further. Here
> are the logs.
>
> ** 2.6.22rc1-git5 + timing-debug.patch
Oh I see. The 2.6.22rc1-git5 has n
Thanks for looking into this!
I tried the patches on 2.6.22rc1-git5. The second patch unfortunately
did not resolve the issue, although it seems to get a bit further. Here
are the logs.
** 2.6.22rc1-git5 + timing-debug.patch
May 20 22:40:49 localhost kernel: pccard: PCMCIA card inserted into
1. Please apply timing-debug.patch on 2.6.22rc1-git5 or later and report
the log with timestamp as before. Let's see why the timeout has doubled.
2. Does the attached disable-dev_init_params.patch fix your problem?
--
tejun
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
inde
33 matches
Mail list logo