Re: Fwd: SWIOTLB on 32-bit PAE.

Re: Fwd: SWIOTLB on 32-bit PAE.

[Bjorn Helgaas]

[+cc Konrad, Joerg, iommu list]

On Fri, Oct 02, 2015 at 04:20:16PM +0200, Christian Melki wrote:
> I discovered a strange error on my machine. 32-bit PAE 4.2.0 without
> IOMMU code (yeah, I know).
> When writing to an ext4 filesystem on a USB disk my kernel would hang
> and not return control to userspace. It would spew kernel messages to
> syslog as fast as it could without giving userspace any time, ie "hang"
> as far as a user sees it. The device itself is ok and the filesystem is
> clean.
> I get messages like this, millions of them.
> 
> Oct  2 14:33:06 voodoochild kernel: [  223.287447] nommu_map_sg:
> overflow 25dcac000+1024 of device mask ffffffff
> Oct  2 14:33:06 voodoochild kernel: [  223.287448] nommu_map_sg:
> overflow 25dcac000+1024 of device mask ffffffff
> Oct  2 14:33:06 voodoochild kernel: [  223.287449] nommu_map_sg:
> overflow 25dcac000+1024 of device mask ffffffff
> 
> I disovered that SWIOTLB was not on. It is only provided for 64-bit
> machines where it is default. On 32-bit SWIOTLB seems disabled
> unless you are running with some IOMMU/AGPGART code.
> 
> But what about 32-bit PAE? Would that not qualify for SWIOTLB without IOMMU?
> 
> I am a novice in this area. Maybe this is a Kconfig "bug" for us
> that like to hang ourselves with CONFIG_* rope? :) I'd like to think
> that SWIOTLB should be default for 32-bit PAE too?
> 
> Best regards,
> Christian
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: SWIOTLB on 32-bit PAE.

[Konrad Rzeszutek Wilk]

On Sat, Oct 03, 2015 at 09:36:30AM -0500, Bjorn Helgaas wrote:
> [+cc Konrad, Joerg, iommu list]
> 
> On Fri, Oct 02, 2015 at 04:20:16PM +0200, Christian Melki wrote:
> > I discovered a strange error on my machine. 32-bit PAE 4.2.0 without
> > IOMMU code (yeah, I know).
> > When writing to an ext4 filesystem on a USB disk my kernel would hang
> > and not return control to userspace. It would spew kernel messages to
> > syslog as fast as it could without giving userspace any time, ie "hang"
> > as far as a user sees it. The device itself is ok and the filesystem is
> > clean.
> > I get messages like this, millions of them.
> > 
> > Oct  2 14:33:06 voodoochild kernel: [  223.287447] nommu_map_sg:
> > overflow 25dcac000+1024 of device mask ffffffff
> > Oct  2 14:33:06 voodoochild kernel: [  223.287448] nommu_map_sg:
> > overflow 25dcac000+1024 of device mask ffffffff
> > Oct  2 14:33:06 voodoochild kernel: [  223.287449] nommu_map_sg:
> > overflow 25dcac000+1024 of device mask ffffffff
> > 
> > I disovered that SWIOTLB was not on. It is only provided for 64-bit
> > machines where it is default. On 32-bit SWIOTLB seems disabled
> > unless you are running with some IOMMU/AGPGART code.
> > 
> > But what about 32-bit PAE? Would that not qualify for SWIOTLB without IOMMU?

It most certainly would!
> > 
> > I am a novice in this area. Maybe this is a Kconfig "bug" for us
> > that like to hang ourselves with CONFIG_* rope? :) I'd like to think
> > that SWIOTLB should be default for 32-bit PAE too?

Aye. I presume that you had done a small change already for this?
Would you be willing to post it on lkml and CC me ?

Thank you.
> > 
> > Best regards,
> > Christian
> > 
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: SWIOTLB on 32-bit PAE.

[Joerg Roedel]

On Sat, Oct 03, 2015 at 02:00:19PM -0400, Konrad Rzeszutek Wilk wrote:
> Aye. I presume that you had done a small change already for this?
> Would you be willing to post it on lkml and CC me ?

Yes, I also think it is needed. SWIOTLB already correctly handles
buffers in HighMem, so enabling it for 32-bit PAE should be easy. Please
also CC me on the patch.


	Joerg

Re: Fwd: SWIOTLB on 32-bit PAE.

[Christian Melki]

Hi.

I think I rang the bell a bit early. The corruption is in grub legacy (I 
assumed that would be in Linux too, but it wasn't). The on disk format 
of ext4 apparently stores byte ordering somehow? I thought the on disk 
format of ext4 was a specific endian (little). Since only that file is 
unreadable in grub, but readable in Linux.. I am guessing endian issues 
somehow.. which still is strange.

Regards,
Christian

On 10/03/2015 08:00 PM, Konrad Rzeszutek Wilk wrote:
> On Sat, Oct 03, 2015 at 09:36:30AM -0500, Bjorn Helgaas wrote:
>> [+cc Konrad, Joerg, iommu list]
>>
>> On Fri, Oct 02, 2015 at 04:20:16PM +0200, Christian Melki wrote:
>>> I discovered a strange error on my machine. 32-bit PAE 4.2.0 without
>>> IOMMU code (yeah, I know).
>>> When writing to an ext4 filesystem on a USB disk my kernel would hang
>>> and not return control to userspace. It would spew kernel messages to
>>> syslog as fast as it could without giving userspace any time, ie "hang"
>>> as far as a user sees it. The device itself is ok and the filesystem is
>>> clean.
>>> I get messages like this, millions of them.
>>>
>>> Oct  2 14:33:06 voodoochild kernel: [  223.287447] nommu_map_sg:
>>> overflow 25dcac000+1024 of device mask ffffffff
>>> Oct  2 14:33:06 voodoochild kernel: [  223.287448] nommu_map_sg:
>>> overflow 25dcac000+1024 of device mask ffffffff
>>> Oct  2 14:33:06 voodoochild kernel: [  223.287449] nommu_map_sg:
>>> overflow 25dcac000+1024 of device mask ffffffff
>>>
>>> I disovered that SWIOTLB was not on. It is only provided for 64-bit
>>> machines where it is default. On 32-bit SWIOTLB seems disabled
>>> unless you are running with some IOMMU/AGPGART code.
>>>
>>> But what about 32-bit PAE? Would that not qualify for SWIOTLB without IOMMU?
>
> It most certainly would!
>>>
>>> I am a novice in this area. Maybe this is a Kconfig "bug" for us
>>> that like to hang ourselves with CONFIG_* rope? :) I'd like to think
>>> that SWIOTLB should be default for 32-bit PAE too?
>
> Aye. I presume that you had done a small change already for this?
> Would you be willing to post it on lkml and CC me ?
>
> Thank you.
>>>
>>> Best regards,
>>> Christian
>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: SWIOTLB on 32-bit PAE.

[Christian Melki]

Never mind my ranting.
The problem was in the extent disk format of ext4. I had forgot that 
ext4 uses extents for all new files by default. Old grub won't read extents.

Oh, well... nothing like wasting hard working peoples time with stupid 
things. Anyway. SWIOTLB for 32-bit PAE should be a good thing though. :)

Regards,
Christian

On 10/05/2015 01:35 PM, Christian Melki wrote:
> Hi.
>
> I think I rang the bell a bit early. The corruption is in grub legacy (I
> assumed that would be in Linux too, but it wasn't). The on disk format
> of ext4 apparently stores byte ordering somehow? I thought the on disk
> format of ext4 was a specific endian (little). Since only that file is
> unreadable in grub, but readable in Linux.. I am guessing endian issues
> somehow.. which still is strange.
>
> Regards,
> Christian
>
> On 10/03/2015 08:00 PM, Konrad Rzeszutek Wilk wrote:
>> On Sat, Oct 03, 2015 at 09:36:30AM -0500, Bjorn Helgaas wrote:
>>> [+cc Konrad, Joerg, iommu list]
>>>
>>> On Fri, Oct 02, 2015 at 04:20:16PM +0200, Christian Melki wrote:
>>>> I discovered a strange error on my machine. 32-bit PAE 4.2.0 without
>>>> IOMMU code (yeah, I know).
>>>> When writing to an ext4 filesystem on a USB disk my kernel would hang
>>>> and not return control to userspace. It would spew kernel messages to
>>>> syslog as fast as it could without giving userspace any time, ie "hang"
>>>> as far as a user sees it. The device itself is ok and the filesystem is
>>>> clean.
>>>> I get messages like this, millions of them.
>>>>
>>>> Oct  2 14:33:06 voodoochild kernel: [  223.287447] nommu_map_sg:
>>>> overflow 25dcac000+1024 of device mask ffffffff
>>>> Oct  2 14:33:06 voodoochild kernel: [  223.287448] nommu_map_sg:
>>>> overflow 25dcac000+1024 of device mask ffffffff
>>>> Oct  2 14:33:06 voodoochild kernel: [  223.287449] nommu_map_sg:
>>>> overflow 25dcac000+1024 of device mask ffffffff
>>>>
>>>> I disovered that SWIOTLB was not on. It is only provided for 64-bit
>>>> machines where it is default. On 32-bit SWIOTLB seems disabled
>>>> unless you are running with some IOMMU/AGPGART code.
>>>>
>>>> But what about 32-bit PAE? Would that not qualify for SWIOTLB
>>>> without IOMMU?
>>
>> It most certainly would!
>>>>
>>>> I am a novice in this area. Maybe this is a Kconfig "bug" for us
>>>> that like to hang ourselves with CONFIG_* rope? :) I'd like to think
>>>> that SWIOTLB should be default for 32-bit PAE too?
>>
>> Aye. I presume that you had done a small change already for this?
>> Would you be willing to post it on lkml and CC me ?
>>
>> Thank you.
>>>>
>>>> Best regards,
>>>> Christian
>>>>
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>>>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html