Bug 239717

Has LSI tested this with a different/open source driver?

I find it not likely that kmap() is broken, because a) it is a trivial function
on 64bit systems and b) if kmap() didn't work, hardly any driver would.

This issue was not duplicated on the LSI's open source MegaRAID SAS driver. This
leads us to a hypothesis that:

Since our software raid stack generates kernel virtual addresses in a low
priority thread (outside the mid-layer's queuecommand interface) using work
queues, these addresses may not be valid when we access them later.
(Experimental) MegaRAID SAS driver kmaps the buffer in ISR and therefore has
correct virtual addresses.

Is this a correct hypothesis?

To verify this, we are implementing a double buffering mechanism in our software
raid driver. With double buffering in place, we would be able to generate
virtual addresses in the ISR context.

Also, as we informed Red Hat in our last conference call; the Linux specific
portion of our software stack can be shared with Red Hat. That's the code which
does the translation for the raid stack.

Thanks
-Atul

> I find it not likely that kmap() is broken, because a) it is a trivial function
> on 64bit systems and b) if kmap() didn't work, hardly any driver would.

Please see a previous data sent to Red Hat and also the fact that we are
generating these addresses in a low priority thread.

<quote>
One more piece of information I would like to add. If I limit the amount of
kernel memory available by providing "mem=" kernel parameter, the behavior can
be toggled.

At about "mem=4350M", things seem to work ok, "mem=4360M", data corruption
happens. In between, it works sometimes and sometimes doesn't.

Other stark contrast is the about the page address and the corresponding kernel
virtual address:

Working configuration:
----------------------
PAGE ADDRESS	KERNEL VIRTUAL ADDRESSS
0xBF7C9000		0xFFFF8100BF7C9000
0x37FB7000		0xFFFF810037FB7000
0xBF0EA000		0xFFFF8100BF0EA000
0xBDA1A000		0xFFFF8100BDA1A000

Non Working Configuration:
--------------------------
PAGE ADDRESS	KERNEL VIRTUAL ADDRESSS
0x91D5000		0xFFFF81010982F000
0x91D6000		0xFFFF81010995F000
0x91D7000		0xFFFF81010AF00000
0x91D8000		0xFFFF81010DED7000

In the working configuration, the kernel virtual address contain the page
address as lower word, whereas the non working configuration does not?
</quote>

(In reply to comment #4)
>
> Other stark contrast is the about the page address and the corresponding kernel
> virtual address:
> 
> Working configuration:
> ----------------------
> PAGE ADDRESS	KERNEL VIRTUAL ADDRESSS
> 0xBF7C9000		0xFFFF8100BF7C9000
> 0x37FB7000		0xFFFF810037FB7000
> 0xBF0EA000		0xFFFF8100BF0EA000
> 0xBDA1A000		0xFFFF8100BDA1A000
> 
> Non Working Configuration:
> --------------------------
> PAGE ADDRESS	KERNEL VIRTUAL ADDRESSS
> 0x91D5000		0xFFFF81010982F000
> 0x91D6000		0xFFFF81010995F000
> 0x91D7000		0xFFFF81010AF00000
> 0x91D8000		0xFFFF81010DED7000
> 
> In the working configuration, the kernel virtual address contain the page
> address as lower word, whereas the non working configuration does not?

In the tables above, I assume that the PAGE ADDRESS column refers to
page_address(page), not the address of the page pointer itself, right?

Chip

Actually, that would be the scatterlist::dma_address, wrong header there.
kmap(page) and page_address(page) returns the same value.

Atul, it would be really helpful if you could come up with a small piece of
open-source code that demonstrates the problem.

Please close this defect. We found out that we have to set the DMA mask to
0xffffffffffffffff for it to work ok.