From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?0JTQsNC90LjQu9CwINCW0YPQutC+0YbQutC40Lk=?= Subject: Re: [Bug #13001] PCI-DMA: Out of IOMMU space Date: Mon, 4 May 2009 10:27:11 +0500 Message-ID: References: <20090428172845R.fujita.tomonori@lab.ntt.co.jp> <20090428184431Z.fujita.tomonori@lab.ntt.co.jp> Mime-Version: 1.0 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9ZOxRXkikEOI/2Ln7mHDDCIPdXFLUpevmwKGUgKHnAY=; b=CzG6oiu+LJw4OPHdCaiCIIWBCjQ1D66QhzBl3rmQ5ZadktscExzPmjGzkbbHvUYri4 8vQ1mct0s0A4nF4T18LXoZk2wNTBspBFPYmVdSqwKTTmpYOTmaJ4h5YSaYR1zK1N/dYd NFQrCdyjY/IQPhrnnOf52VAlEW3Lz4ZRXqYzc= In-Reply-To: <20090428184431Z.fujita.tomonori-Zyj7fXuS5i5L9jVzuh4AOg@public.gmane.org> Sender: kernel-testers-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="utf-8" To: FUJITA Tomonori Cc: rjw-KKrjLPT3xs0@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kernel-testers-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, grundler-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org 2009/4/28 FUJITA Tomonori : > On Tue, 28 Apr 2009 14:18:57 +0500 > **UNKNOWN CHARSET** wrote: > >> No, it is regression. I can reproduce that without allowdac and any >> other unnecessary boot options. > > Hmm, in the bug repport, you said that you can't reproduce the proble= m: > > http://bugzilla.kernel.org/show_bug.cgi?id=3D13001#c15 > > I can't find your comment like, "I can reproduce that without > allowdac". I was under a misapprehension. Later discussion was been in linux-pci mailing list http://markmail.org/message/pbng73ojpllln5fl > >> In later discussion Grant Grundler ask >> me apply patch that show 32 bit dma devices in my system. Results I >> attached to bugreport. Looks like only one 32 bit dma device in my >> system is ata controller, sata-nv. > > Hmm, looks like http://bugzilla.kernel.org/attachment.cgi?id=3D20895 > said that pata_amd and sata_nv use 32bit dma mask. > > >> I can stable reproduce IOMMU out of space when I write data to sata >> drive. > > Ok, let's figure out what's wrong. > > First, can you test v2.6.30-rc3 with the following patch? > > http://www.kernel.org/pub/linux/kernel/people/tomo/misc/gart-debug.di= ff > > > Note that please enable CONFIG_DMA_API_DEBUG, CONFIG_IOMMU_DEBUG, and > CONFIG_IOMMU_LEAK and see if you can reproduce the problem (of course= , > don't use any kernel option). > > When the kernel is out of IOMMU space, it prints some useful > information. > I can't reproduce bug in 2.6.30-rc3. I read and wrote ~ 100gb data from and to sata drive. Dmesg has two warnings during boot, ------------[ cut here ]------------ WARNING: at lib/dma-debug.c:607 check_unmap+0x542/0x610() Hardware name: HP xw9400 Workstation 3w-9xxx 0001:45:00.0: DMA-API: device driver tries to free DMA memory it has not allocated [device address=3D0x0000000000000000] [size=3D36 bytes] Modules linked in: Pid: 0, comm: swapper Not tainted 2.6.30-rc3-git7 #1 Call Trace: [] ? warn_slowpath+0xea/0x160 [] ? sched_clock_cpu+0x6e/0x240 [] ? scheduler_tick+0xc2/0x220 [] ? getnstimeofday+0x5b/0xe0 [] ? ktime_get_ts+0x30/0x60 [] ? ktime_get+0xc/0x50 [] ? lapic_next_event+0x18/0x20 [] ? tick_dev_program_event+0x36/0xb0 [] ? smp_apic_timer_interrupt+0x6c/0xa0 [] ? apic_timer_interrupt+0x13/0x20 [] ? vprintk+0x2d3/0x420 [] ? check_unmap+0x542/0x610 [] ? debug_dma_unmap_sg+0xde/0x180 [] ? scsi_dma_unmap+0x6b/0xa0 [] ? twa_interrupt+0x3e9/0x6a0 [] ? __hrtimer_start_range_ns+0x12d/0x2b0 [] ? handle_IRQ_event+0x59/0x130 [] ? handle_edge_irq+0xc1/0x160 [] ? handle_irq+0x17/0x20 [] ? do_IRQ+0x65/0xf0 [] ? ret_from_intr+0x0/0xa [] ? default_idle+0x42/0x50 [] ? c1e_idle+0x34/0x100 [] ? __atomic_notifier_call_chain+0x19/0x50 [] ? cpu_idle+0x5a/0xc0 ---[ end trace eedd91b655a6fdac ]--- and ------------[ cut here ]------------ WARNING: at fs/namei.c:1251 lookup_one_len+0xe9/0x100() Hardware name: HP xw9400 Workstation Modules linked in: fuse nfs auth_rpcgss lockd sunrpc scsi_wait_scan usbhid ohci_hcd usb_storage usb_libusual ehci_hcd usbcore Pid: 2807, comm: mount Tainted: G W 2.6.30-rc3-git7 #1 Call Trace: [] ? warn_slowpath+0xea/0x160 [] ? printk+0x4e/0x58 [] ? prepare_error_buf+0x51a/0x610 [] ? new_slab+0x1ee/0x330 [] ? reiserfs_info+0x71/0xa0 [] ? lookup_one_len+0xe9/0x100 [] ? reiserfs_xattr_init+0x3d/0xb0 [] ? reiserfs_fill_super+0x663/0xb50 [] ? kobject_get+0x12/0x20 [] ? get_device+0x14/0x20 [] ? __down_write_nested+0xb2/0xc0 [] ? kmem_cache_alloc+0x65/0xa0 [] ? sget+0x3c2/0x410 [] ? get_sb_bdev+0x174/0x1a0 [] ? reiserfs_fill_super+0x0/0xb50 [] ? vfs_kern_mount+0x56/0xd0 [] ? do_kern_mount+0x53/0x120 [] ? do_mount+0x2ba/0x8c0 [] ? bad_gs+0xc34/0x1e0c [] ? sys_mount+0xcd/0x100 [] ? system_call_fastpath+0x16/0x1b ---[ end trace eedd91b655a6fdae ]--- So I hope that bug is gone. --=20 =D0=A1 =D1=83=D0=B2=D0=B0=D0=B6=D0=B5=D0=BD=D0=B8=D0=B5=D0=BC =D0=94=D0= =B0=D0=BD=D0=B8=D0=BB=D0=B0 =D0=96=D1=83=D0=BA=D0=BE=D1=86=D0=BA=D0=B8=D0= =B9, =D1=81=D0=B8=D1=81=D1=82=D0=B5=D0=BC=D0=BD=D1=8B=D0=B9 =D0=B0=D0=B4= =D0=BC=D0=B8=D0=BD=D0=B8=D1=81=D1=82=D1=80=D0=B0=D1=82=D0=BE=D1=80 =D0=97= =D0=90=D0=9E "=D0=A0=D0=BE=D1=81=D0=BD=D0=B5=D1=84=D1=82=D0=B5=D0=B3=D0= =B0=D0=B7=D0=BC=D0=B0=D1=88"