MWDMA Issue: sda: unknown partition table

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

That's AC_ERR_ATA_BUS.

Yeah, someone is reporting CRC error.

tejun

Tejun,

Thanks for your prompt reply!!

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

Tejun,

This error:

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

Hey,

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

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.

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

Ok. Will debug this.

Yes

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

Hello,

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.

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

Thanks.

tejun

Tejun,

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

Tejun,

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

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
[email protected]

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.

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

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.

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
[email protected]

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

viresh