Jens Axboe <[email protected]> wrote:
>
> > > better candidate to fix that :-)
> >
> > It's not ZONE_DMA32. It's the 12MB ZONE_DMA which is being exhausted on
> > this 4GB 64-bit machine.
> >
> > Andy put a dump_stack() into the oom code and it pointed at
> >
> >
> > Call Trace:<ffffffff8014d7bc>{out_of_memory+48}
> > <ffffffff8014f4b0>{__alloc_pages+536}
> > <ffffffff80169788>{bio_alloc_bioset+232}
> > <ffffffff80169d03>{bio_copy_user+218}
> > <ffffffff801bd657>{blk_rq_map_user+136}
> > <ffffffff801c0008>{sg_io+328}
> > <ffffffff801c047c>{scsi_cmd_ioctl+491}
> > <ffffffff88005e22>{:ide_core:generic_ide_ioctl+631}
> > <ffffffff88202d0c>{:sd_mod:sd_ioctl+371}
> > <ffffffff802a6db6>{schedule_timeout+158}
> > <ffffffff801bf165>{blkdev_ioctl+1365}
> > <ffffffff80243cb2>{sys_sendto+251}
> > <ffffffff801751e5>{__pollwait+0}
> > <ffffffff8016b16a>{block_ioctl+25}
> > <ffffffff801749f4>{do_ioctl+24} <ffffffff80174c46>{vfs_ioctl+541}
> > <ffffffff80174cb4>{sys_ioctl+89}
>
> Hmm strange, what kind of device is this? I'm guessing it's not ISA.
sata_via 0000:00:0f.0: routed to hard irq line 1
ata1: SATA max UDMA/133 cmd 0xD000 ctl 0xC802 bmdma 0xB800 irq 17
ata2: SATA max UDMA/133 cmd 0xC400 ctl 0xC002 bmdma 0xB808 irq 17
sata_promise 0000:00:08.0: version 1.03
ACPI: PCI Interrupt 0000:00:08.0[A] -> GSI 18 (level, low) -> IRQ 19
ata3: SATA max UDMA/133 cmd 0xFFFFC20000006200 ctl 0xFFFFC20000006238
bmdma 0x0 irq 19
ata4: SATA max UDMA/133 cmd 0xFFFFC20000006280 ctl 0xFFFFC200000062B8
bmdma 0x0 irq 19
...
ata4: no device found (phy stat 00000000)
scsi3 : sata_promise
ata1: dev 0 cfg 49:2f00 82:3069 83:7c01 84:4003 85:3069 86:3c01 87:4003
88:203f
ata1: dev 0 ATA-6, max UDMA/100, 390721968 sectors: LBA48
ata1: dev 0 configured for UDMA/100
scsi0 : sata_via
ata2: no device found (phy stat 00000000)
scsi1 : sata_via
Vendor: ATA Model: ST3200822AS Rev: 3.01
Type: Direct-Access ANSI SCSI revision: 05
> Andy, can you try and boot with this applied?
yes, that'll be interesting.
> Did the blk_max_low_pfn stuff get a different meaning with the addition
> of the DMA32 zone?
The Fedora reporter
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175173) hit what
appears to be the same thing (gfp_mask=0xd1 - that's ZONE_DMA unless I've
lost it completely?) in 2.6.14, which doesn't have ZONE_DMA32.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
