* Re: Fwd: SWIOTLB on 32-bit PAE. [not found] ` <560E92A0.9030707@t2data.com> @ 2015-10-03 14:36 ` Bjorn Helgaas 2015-10-03 18:00 ` Konrad Rzeszutek Wilk 0 siblings, 1 reply; 5+ messages in thread From: Bjorn Helgaas @ 2015-10-03 14:36 UTC (permalink / raw) To: Christian Melki; +Cc: linux-pci, Konrad Rzeszutek Wilk, Joerg Roedel, iommu [+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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Fwd: SWIOTLB on 32-bit PAE. 2015-10-03 14:36 ` Fwd: SWIOTLB on 32-bit PAE Bjorn Helgaas @ 2015-10-03 18:00 ` Konrad Rzeszutek Wilk 2015-10-05 10:00 ` Joerg Roedel [not found] ` <20151003180007.GA4732-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org> 0 siblings, 2 replies; 5+ messages in thread From: Konrad Rzeszutek Wilk @ 2015-10-03 18:00 UTC (permalink / raw) To: Bjorn Helgaas Cc: linux-pci-u79uwXL29TY76Z2rM5mHXA, Christian Melki, iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Fwd: SWIOTLB on 32-bit PAE. 2015-10-03 18:00 ` Konrad Rzeszutek Wilk @ 2015-10-05 10:00 ` Joerg Roedel [not found] ` <20151003180007.GA4732-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org> 1 sibling, 0 replies; 5+ messages in thread From: Joerg Roedel @ 2015-10-05 10:00 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: Bjorn Helgaas, christian.melki, linux-pci, iommu 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <20151003180007.GA4732-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>]
* Re: Fwd: SWIOTLB on 32-bit PAE. [not found] ` <20151003180007.GA4732-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org> @ 2015-10-05 11:35 ` Christian Melki [not found] ` <5612607B.2050208-VBSoEI6PWPXQT0dZR+AlfA@public.gmane.org> 0 siblings, 1 reply; 5+ messages in thread From: Christian Melki @ 2015-10-05 11:35 UTC (permalink / raw) To: Konrad Rzeszutek Wilk, joro-zLv9SwRftAIdnm+yROfE0A Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <5612607B.2050208-VBSoEI6PWPXQT0dZR+AlfA@public.gmane.org>]
* Re: Fwd: SWIOTLB on 32-bit PAE. [not found] ` <5612607B.2050208-VBSoEI6PWPXQT0dZR+AlfA@public.gmane.org> @ 2015-10-05 12:14 ` Christian Melki 0 siblings, 0 replies; 5+ messages in thread From: Christian Melki @ 2015-10-05 12:14 UTC (permalink / raw) To: Konrad Rzeszutek Wilk, joro-zLv9SwRftAIdnm+yROfE0A Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-10-05 12:14 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <560E9007.1000604@t2data.com>
[not found] ` <560E92A0.9030707@t2data.com>
2015-10-03 14:36 ` Fwd: SWIOTLB on 32-bit PAE Bjorn Helgaas
2015-10-03 18:00 ` Konrad Rzeszutek Wilk
2015-10-05 10:00 ` Joerg Roedel
[not found] ` <20151003180007.GA4732-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2015-10-05 11:35 ` Christian Melki
[not found] ` <5612607B.2050208-VBSoEI6PWPXQT0dZR+AlfA@public.gmane.org>
2015-10-05 12:14 ` Christian Melki
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox