MWDMA Issue: sda: unknown partition table

MWDMA Issue: sda: unknown partition table

[viresh kumar]

Hi,

I am implementing mwdma interface for arasan compact flash controller.
I am facing a strange problem, when i insert CF card on my board (after bootup),
in mwdma mode, i get following:

ata1: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xe frozen
ata1: soft resetting link
ata1.00: CFA: TRANSCEND, 20091215, max UDMA/66
ata1.00: 62537328 sectors, multi 0: LBA 
ata1.00: configured for MWDMA4
ata1: EH complete
scsi 0:0:0:0: Direct-Access     ATA      TRANSCEND        2009 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 62537328 512-byte logical blocks: (32.0 GB/29.8 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
 sda: unknown partition table
sd 0:0:0:0: [sda] Attached SCSI disk


I tried PIO mode on same card and it worked fine i got sda1 created.
I suspected that there is some problem with DMA, so i took dump of all data read by PIO
and DMA. After configuring in MWDMA4 mode at:
ata1.00: configured for MWDMA4
a read request of 4096 bytes occurs (both in PIO (handled by libata-sff) and MWDMA).

These 4096 bytes are exactly same in case of PIO and MWDMA. Also all data read before configuring
MWDMA4 mode is also same, as that is done by common PIO code.

In my interrupt handler, after controller specific code i am calling:
ata_bmdma_interrupt(irq, dev);

also i am returning ATA_DMA_INTR from my bmdma_status routine.
ata_port_operations is:

static struct ata_port_operations arasan_cf_ops = {
	.inherits		= &ata_bmdma_port_ops,
	.set_piomode		= arasan_cf_set_piomode,
	.set_dmamode		= arasan_cf_set_dmamode,
	.bmdma_setup		= arasan_cf_bmdma_setup,
	.bmdma_start		= arasan_cf_bmdma_start,
	.bmdma_stop		= arasan_cf_bmdma_stop,
	.bmdma_status		= arasan_cf_bmdma_status,
	.sff_irq_clear		= arasan_cf_bmdma_irq_clear,
};

There are no BMDMA registers in my controller.

Can somebody give any clue on which part i should try to look at?

thanks in advance,
viresh

Re: MWDMA Issue: sda: unknown partition table

[Tejun Heo]

On Fri, Jan 21, 2011 at 03:39:56PM +0530, viresh kumar wrote:
> I am implementing mwdma interface for arasan compact flash controller.
> I am facing a strange problem, when i insert CF card on my board (after bootup),
> in mwdma mode, i get following:
> 
> ata1: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xe frozen

That's AC_ERR_ATA_BUS.

> Can somebody give any clue on which part i should try to look at?

Yeah, someone is reporting CRC error.

-- 
tejun

Re: MWDMA Issue: sda: unknown partition table

[viresh kumar]

Tejun,

Thanks for your prompt reply!!

On 01/21/2011 03:44 PM, Tejun Heo wrote:
> On Fri, Jan 21, 2011 at 03:39:56PM +0530, viresh kumar wrote:
>> > I am implementing mwdma interface for arasan compact flash controller.
>> > I am facing a strange problem, when i insert CF card on my board (after bootup),
>> > in mwdma mode, i get following:
>> > 
>> > ata1: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xe frozen
> That's AC_ERR_ATA_BUS.
> 
>> > Can somebody give any clue on which part i should try to look at?
> Yeah, someone is reporting CRC error.

I will check this.

But it seems unknown partition table is a different issue,
as this error is also coming in PIO mode, where i am able to get sda1 node
and able to read/write to card.

print in PIO mode:

# ata1: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xe frozen
ata1: soft resetting link
ata1.00: CFA: TRANSCEND, 20091215, max UDMA/66
ata1.00: 62537328 sectors, multi 0: LBA 
ata1.00: configured for PIO6
ata1.00: configured for PIO6
ata1: EH complete
scsi 0:0:0:0: Direct-Access     ATA      TRANSCEND        2009 PQ: 0 ANSI: 5
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 0:0:0:0: [sda] 62537328 512-byte logical blocks: (32.0 GB/29.8 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
 sda: sda1
sd 0:0:0:0: [sda] Attached SCSI disk

-- 
viresh

Re: MWDMA Issue: sda: unknown partition table

[viresh kumar]

On 01/21/2011 03:58 PM, viresh kumar wrote:
> Tejun,
> 
> Thanks for your prompt reply!!
> 
> On 01/21/2011 03:44 PM, Tejun Heo wrote:
>> On Fri, Jan 21, 2011 at 03:39:56PM +0530, viresh kumar wrote:
>>>> I am implementing mwdma interface for arasan compact flash controller.
>>>> I am facing a strange problem, when i insert CF card on my board (after bootup),
>>>> in mwdma mode, i get following:
>>>>
>>>> ata1: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xe frozen
>> That's AC_ERR_ATA_BUS.
>>
>>>> Can somebody give any clue on which part i should try to look at?
>> Yeah, someone is reporting CRC error.
> 
> I will check this.
> 
> But it seems unknown partition table is a different issue,
> as this error is also coming in PIO mode, where i am able to get sda1 node
> and able to read/write to card.
> 
> print in PIO mode:
> 
> # ata1: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xe frozen
> ata1: soft resetting link
> ata1.00: CFA: TRANSCEND, 20091215, max UDMA/66
> ata1.00: 62537328 sectors, multi 0: LBA 
> ata1.00: configured for PIO6
> ata1.00: configured for PIO6
> ata1: EH complete
> scsi 0:0:0:0: Direct-Access     ATA      TRANSCEND        2009 PQ: 0 ANSI: 5
> sd 0:0:0:0: Attached scsi generic sg0 type 0
> sd 0:0:0:0: [sda] 62537328 512-byte logical blocks: (32.0 GB/29.8 GiB)
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
>  sda: sda1
> sd 0:0:0:0: [sda] Attached SCSI disk
> 

Tejun,

This error:
> # ata1: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xe frozen

is coming only when i insert/remove my card after board has booted up. If i keep it
inserted, and then boot the board: No such error occurs.

As suggested by you earlier, i am doing following on card insertion and removal,
after resetting card through controller.

		ata_ehi_hotplugged(ehi);
		ata_port_freeze(ap);

and after that only i get that error message through following path:
Kthread()->scsi_error_handler()->ata_scsi_error()->ata_bmdma_error_handler()
->ata_sff_error_handler()->ata_do_eh()

I tried again, but couldn't find why i am getting these two issues:
	ata1: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xe frozen
	sda: unknown partition table

-- 
viresh

Re: MWDMA Issue: sda: unknown partition table

[Tejun Heo]

Hey,

On Fri, Jan 21, 2011 at 05:29:39PM +0530, viresh kumar wrote:
> This error:
> > # ata1: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xe frozen
> 
> is coming only when i insert/remove my card after board has booted up. If i keep it
> inserted, and then boot the board: No such error occurs.
> 
> As suggested by you earlier, i am doing following on card insertion and removal,
> after resetting card through controller.
> 
> 		ata_ehi_hotplugged(ehi);
> 		ata_port_freeze(ap);
> 
> and after that only i get that error message through following path:
> Kthread()->scsi_error_handler()->ata_scsi_error()->ata_bmdma_error_handler()
> ->ata_sff_error_handler()->ata_do_eh()

Hmmm... okay, so that's from the hotplugging.

> I tried again, but couldn't find why i am getting these two issues:
> 	ata1: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xe frozen

Yeah, it should be possible to avoid the above if it's coming from
hotplug.  Identify where and why AC_ERR_ATA_BUS is being set and work
around it.  There's no reason for it to be set after a hotplug anyway.

> 	sda: unknown partition table

and then this probably is unrelated.  So, no IO error is being
reported but the above still fails?  How did you verify the read data
are actually the same?  Maybe there's a cache alias issue?

-- 
tejun

Re: MWDMA Issue: sda: unknown partition table

[Viresh Kumar]

On 1/21/11, Tejun Heo <tj@kernel.org> wrote:
> On Fri, Jan 21, 2011 at 05:29:39PM +0530, viresh kumar wrote:
>> I tried again, but couldn't find why i am getting these two issues:
>> 	ata1: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xe frozen
>
> Yeah, it should be possible to avoid the above if it's coming from
> hotplug.  Identify where and why AC_ERR_ATA_BUS is being set and work
> around it.  There's no reason for it to be set after a hotplug anyway.
>

Ok. Will debug this.

>> 	sda: unknown partition table
>
> and then this probably is unrelated.  So, no IO error is being
> reported but the above still fails?

Yes

> How did you verify the read data
> are actually the same?  Maybe there's a cache alias issue?
>

I printed buffer data at two places
: ata_sff_data_xfer (in PIO mode)
: my drivers dma read routine after all data is read (In MWDMA Mode).

As soon as handshaking is done, a read request of 4096 bytes is given:
Here in both cases (PIO and MWDMA) first block of 512 bytes contained
non-zero data but the other 7 blocks contained 0.

Also Arasan Controller, as far i have understood, doesn't transfer data directly
to a memory location. Instead we need to read data from Controllers FIFO.
So, probably it wouldn't be cache issue, as ARM is reading data directly from
FIFO to our buffer (using its virtual address).

Note: I am working on linux-2.6.37 and Card was formatted before
testing and so is empty.

--
viresh

Re: MWDMA Issue: sda: unknown partition table

[Tejun Heo]

Hello,

On Sat, Jan 22, 2011 at 09:38:46AM +0530, Viresh Kumar wrote:
> As soon as handshaking is done, a read request of 4096 bytes is given:
> Here in both cases (PIO and MWDMA) first block of 512 bytes contained
> non-zero data but the other 7 blocks contained 0.

Hmmm, okay.  Well, I'm afraid you'll have to find out where things are
going wrong.  fs/partitions/check.h::read_part_sector() is the read
function used by partition check code.  You'll have to find where the
difference between what that code and your drive sees comes from.
Playing with dd in userland on the device node and see how reads and
writes behave would be helpful too.

> Also Arasan Controller, as far i have understood, doesn't transfer data directly
> to a memory location. Instead we need to read data from Controllers FIFO.
> So, probably it wouldn't be cache issue, as ARM is reading data directly from
> FIFO to our buffer (using its virtual address).

I don't really follow.  It's DMA.  The controller is writing to
memory.

Thanks.

-- 
tejun

Re: MWDMA Issue: sda: unknown partition table

[viresh kumar]

Tejun,

On 01/21/2011 10:09 PM, Tejun Heo wrote:
>> > As suggested by you earlier, i am doing following on card insertion and removal,
>> > after resetting card through controller.
>> > 
>> > 		ata_ehi_hotplugged(ehi);
>> > 		ata_port_freeze(ap);
>> > 
>> > and after that only i get that error message through following path:
>> > Kthread()->scsi_error_handler()->ata_scsi_error()->ata_bmdma_error_handler()
>> > ->ata_sff_error_handler()->ata_do_eh()
> Hmmm... okay, so that's from the hotplugging.
> 
>> > I tried again, but couldn't find why i am getting these two issues:
>> > 	ata1: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xe frozen
> Yeah, it should be possible to avoid the above if it's coming from
> hotplug.  Identify where and why AC_ERR_ATA_BUS is being set and work
> around it.  There's no reason for it to be set after a hotplug anyway.
> 

I debugged it further, ehi->err_mask |= AC_ERR_ATA_BUS is done in
ata_ehi_hotplugged(). I tried to find the place where it should be cleared in
code path, but couldn't find it.

Further i checked the order in which code is executed and taken dump of that:
ata_ehi_hotplugged, ata_port_freeze, ata_port_abort, ata_do_link_abort,
ata_port_schedule_eh, scsi_schedule_eh.

And just after this following error was printed:
ata1: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xe frozen

I feel ata_port_schedule_eh() shouldn't have been called. It is called because
there were no qc's in ata_port.

--
viresh

Re: MWDMA Issue: sda: unknown partition table

[Viresh Kumar]

Tejun,

On 1/21/11, Tejun Heo <tj@kernel.org> wrote:
> On Fri, Jan 21, 2011 at 05:29:39PM +0530, viresh kumar wrote:
>> 	sda: unknown partition table
>
> and then this probably is unrelated.  So, no IO error is being
> reported but the above still fails?  How did you verify the read data
> are actually the same?  Maybe there's a cache alias issue?
>

This issue is solved now and was related to cache only. As i mentioned earlier
Arasan CF controller doesn't xfer data from/to RAM. And so i was using CPU
to copy data. After data is passed to libata, in page_unmap, cache was
getting invalidated.
And so data written by CPU is lost.

Now i am using external DMA controller to copy data to CF FIFO, and am able to
read/write data to CF card.

But i am facing another issue now. I am getting following error
sometimes, when i
copy > 10 MB of data to CF card.

ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
ata1.00: BMDMA stat 0x5
ata1.00: failed command: WRITE DMA
ata1.00: cmd ca/00:00:3f:7f:3c/00:00:00:00:00/e0 tag 0 dma 131072 out
        res d0/00:00:3f:7f:3c/00:00:00:00:00/e0 Emask 0x2 (HSM violation)
ata1.00: status: { Busy }


I debugged it further and found that after data is transferred,
altstatus register is
returning status 0xd0, which means ATA_BUSY.

I am not sure why this must be returned by card after data is transferred?

--
viresh

Re: MWDMA Issue: sda: unknown partition table

[Eric D. Mudama]

On Tue, Feb  1 at 21:02, Viresh Kumar wrote:
>But i am facing another issue now. I am getting following error
>sometimes, when i
>copy > 10 MB of data to CF card.
>
>ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
>ata1.00: BMDMA stat 0x5
>ata1.00: failed command: WRITE DMA
>ata1.00: cmd ca/00:00:3f:7f:3c/00:00:00:00:00/e0 tag 0 dma 131072 out
>        res d0/00:00:3f:7f:3c/00:00:00:00:00/e0 Emask 0x2 (HSM violation)
>ata1.00: status: { Busy }
>
>
>I debugged it further and found that after data is transferred,
>altstatus register is returning status 0xd0, which means ATA_BUSY.
>
>I am not sure why this must be returned by card after data is transferred?

Did you wait for the interrupt?  Or is this polling alt status
immediately after completing the data transfer?

If I remember correctly (been a long time), there's a busy phase after
the last word is transferred, until the command actually completes.
This may or may not generate an interrupt.  Eventually, the alt status
register should transition to a status without the HOB set (0xD0->0x50
most of the time) when the command has finished, and a read of the
regular status register should clear an outstanding interrupt.

--eric

-- 
Eric D. Mudama
edmudama@mail.bounceswoosh.org

Re: MWDMA Issue: sda: unknown partition table

[viresh kumar]

On 02/01/2011 11:29 PM, Eric D. Mudama wrote:
> On Tue, Feb  1 at 21:02, Viresh Kumar wrote:
>> But i am facing another issue now. I am getting following error
>> sometimes, when i
>> copy > 10 MB of data to CF card.
>>
>> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
>> ata1.00: BMDMA stat 0x5
>> ata1.00: failed command: WRITE DMA
>> ata1.00: cmd ca/00:00:3f:7f:3c/00:00:00:00:00/e0 tag 0 dma 131072 out
>>        res d0/00:00:3f:7f:3c/00:00:00:00:00/e0 Emask 0x2 (HSM violation)
>> ata1.00: status: { Busy }
>>
>>
>> I debugged it further and found that after data is transferred,
>> altstatus register is returning status 0xd0, which means ATA_BUSY.
>>
>> I am not sure why this must be returned by card after data is transferred?
> 
> Did you wait for the interrupt?  Or is this polling alt status
> immediately after completing the data transfer?

I waited for this interrupt:

INTRQ_Int: This is the direct assignment of the CF/CF+ Interface pin 37 (INTRQ) when the
Interface is operating in TrueIDE Mode. This is the Interrupt from the Card.
The Software must read the ATA Status Register to find the source of Interrupt.

And i think that is sufficient enough.

> 
> If I remember correctly (been a long time), there's a busy phase after
> the last word is transferred, until the command actually completes.
> This may or may not generate an interrupt.  Eventually, the alt status
> register should transition to a status without the HOB set (0xD0->0x50
> most of the time) when the command has finished, and a read of the
> regular status register should clear an outstanding interrupt.
> 

Just to get over this doubt, i will try place a small udelay after data is transferred
and before framework is communicated for successful xfer.

-- 
viresh

Re: MWDMA Issue: sda: unknown partition table

[Eric D. Mudama]

On Wed, Feb  2 at  9:13, viresh kumar wrote:
>On 02/01/2011 11:29 PM, Eric D. Mudama wrote:
>> On Tue, Feb  1 at 21:02, Viresh Kumar wrote:
>>>
>>> I debugged it further and found that after data is transferred,
>>> altstatus register is returning status 0xd0, which means ATA_BUSY.
>>>
>>> I am not sure why this must be returned by card after data is transferred?
>>
>> Did you wait for the interrupt?  Or is this polling alt status
>> immediately after completing the data transfer?
>
>I waited for this interrupt:
>
>INTRQ_Int: This is the direct assignment of the CF/CF+ Interface pin 37 (INTRQ) when the
>Interface is operating in TrueIDE Mode. This is the Interrupt from the Card.
>The Software must read the ATA Status Register to find the source of Interrupt.
>
>And i think that is sufficient enough.

Yes, should be.  Do both alt status and regular status show this signature?

Possible there's some kind of hardware race condition, though IDE is
pretty much a "known" interface.

>Just to get over this doubt, i will try place a small udelay after data is transferred
>and before framework is communicated for successful xfer.

That's a good thing to try, wouldn't be the first time I've heard of
things like that being required.

-- 
Eric D. Mudama
edmudama@mail.bounceswoosh.org

Re: MWDMA Issue: sda: unknown partition table

[viresh kumar]

On 02/02/2011 11:25 AM, Eric D. Mudama wrote:
>> >Just to get over this doubt, i will try place a small udelay after data is transferred
>> >and before framework is communicated for successful xfer.
> That's a good thing to try, wouldn't be the first time I've heard of
> things like that being required.

I tried this, and still get same error sometimes. I took a 100ms delay.

-- 
viresh