From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Kreileder Date: Tue, 05 Aug 2008 01:12:03 +0200 Subject: [ath9k-devel] Running out of SWIOTLB space In-Reply-To: <20080804224421.GF6447@tesla> References: <4896157A.2020907@shaw.ca> <4896500E.2040304@blackdown.de> <48966728.5080901@kernel.org> <48966DAE.2020203@shaw.ca> <48977E1B.2090905@blackdown.de> <20080804224421.GF6447@tesla> Message-ID: <48978CC3.8000700@blackdown.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org Luis R. Rodriguez wrote: > On Mon, Aug 04, 2008 at 03:09:31PM -0700, Juergen Kreileder wrote: >> Robert Hancock wrote: >>> Tejun Heo wrote: >>>> Juergen Kreileder wrote: >>>>> Robert Hancock wrote: >>>>>> Juergen Kreileder wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I get lots of errors like this with 2.6.27-rc1 on my >>>>>>> Macbook Pro (3rd generation), 2.6.26 seems to work fine: >>>>>>> >>>>>>> [ 907.524509] DMA: Out of SW-IOMMU space for 45056 bytes at device 0000:00:1f.2 >>>>>>> [ 907.524783] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 >>>>>>> [ 907.524796] ata3.00: cmd 35/00:50:08:91:5c/00:01:0f:00:00/e0 tag 0 dma 172032 out >>>>>>> [ 907.524798] res 50/00:00:ff:90:5c/00:00:0f:00:00/ef Emask 0x40 (internal error) >>>>>>> [ 907.524805] ata3.00: status: { DRDY } >>>>>>> [ 907.646590] ata3.00: configured for UDMA/133 >>>>>>> [ 907.646624] ata3: EH complete >>>>>>> Any suggestions? >>>>>> You can try increasing the swiotlb size by booting with swiotlb=65536 >>>>>> (for 128MB) or swiotlb=131072 (for 256MB), and see if that makes the >>>>>> problem go away.. It's unclear why you'd be running out of SWIOTLB space >>>>>> now, though, if 2.6.26 worked fine.. >>>>> Still happening, although 256M make it a bit harder to trigger. >>>> Hmm... sounds like mapping is leaking. Eh... iommu leak debug seems to >>>> support only AMD GART IOMMU. How long does it take to reproduce the >>>> bug? Once it happens, it never recovers, right? Does the problem >>>> happen with minimal configuration w/ only libata enabled (no network, no >>>> sound, no usb...)? >>> Yes, that would be a good test.. Easiest way might be booting with >>> init=/bin/sh and running some processes that do lots of disk access.. >> After a bit more testing I'm pretty sure the problem is caused by an >> external driver, namely the new ath9k driver. >> >> Sorry for the noise on the wrong lists. > > Juergen, > > can you elaborate a bit on the details of when this happens? I may be > able to get a Power Book to try to reproduce. Are you testing ath9k > based on ath9k.git or my-wireless-testing.git? What was the last ath9k > patch you had? I'm using a 3rd gen Macbook Pro with 2.6.27-rc1 x86-64. The ath9k driver was pulled from ath9k.git on Saturday IIRC. $ dmesg | grep -i -e "ath9k\|atheros" [ 13.331818] ath9k: 0.1 [ 13.331861] ath9k 0000:0b:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 13.331882] ath9k 0000:0b:00.0: setting latency timer to 64 [ 13.462713] phy0: Selected rate control algorithm 'ath9k_rate_control' [ 13.564127] phy0: Atheros 5416: mem=0xffffc200000c0000, irq=16 Apparently it doesn't require much ath9k activity to trigger the problem. I only had the module loaded but not connected to any network, the disk driver freaks out pretty soon then. Without the ath9k module I'm unable to reproduce any SW-IOMMU problems. > Please note ath9k is now part of wireless-testing.git. I'll give that a shot tomorrow. I did a short test with the current version of ath9k.git this evening. I got an oops from sched-powersave but the driver actually tried to connect to an network. It timed out after entering the passphrase though. Then the machine ran out of SW-IOMMU space again (reported against the ath9k device this time). Juergen -- Juergen Kreileder, Blackdown Java-Linux Team http://blog.blackdown.de/