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
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
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
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
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 driver is using IRQ driven PIO. Maybe
Oops had done a reply instead of a reply to all...
---BeginMessage---
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
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
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 localhost
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
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=116546272916399=2
Right. Thanks for reminding me. :-)
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-idem=116546272916399w=2
Right. Thanks for reminding me. :-)
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
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=116546272916399=2
Right. Thanks for reminding me. :-)
--
tejun
-
To
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-idem=116546272916399w=2
Right. Thanks for reminding me. :-)
--
tejun
-
To unsubscribe
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
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
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:
(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
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 inserted
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
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
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
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
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
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
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
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 port
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
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
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
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:
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
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 I know of. Not devices anyway
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:
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
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
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
> > 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
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
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
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
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
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
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
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
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,
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
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
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
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 new
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.
The CF
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 attached
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
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
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,
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
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
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
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
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
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
I tried 2.6.22rc1-git5 with both the libata pcmcia and the legacy ide
pcmcia support, both failed as can be seen below...
Linux localhost.localdomain 2.6.22-rc1-git5 #5 SMP Thu May 17 21:23:42
CEST 2007 i686 i686 i386 GNU/Linux
** libata **
May 17 21:55:06 localhost kernel: pccard: PCMCIA
I tried 2.6.22rc1-git5 with both the libata pcmcia and the legacy ide
pcmcia support, both failed as can be seen below...
Linux localhost.localdomain 2.6.22-rc1-git5 #5 SMP Thu May 17 21:23:42
CEST 2007 i686 i686 i386 GNU/Linux
** libata **
May 17 21:55:06 localhost kernel: pccard: PCMCIA
68 matches
Mail list logo
