* 4.1.0rc3 page fault on boot prior to kernel loading
From: Nathan March @ 2011-02-02 0:05 UTC (permalink / raw)
To: xen-devel@lists.xensource.com
I ran into this on 4.0.2 as well, posted it to xen-users a couple weeks
ago but didn't get any useful responses.
Anyone have any idea what might be going on here? This is using the
latest dom0 kernel from jeremy. The kernel boots fine directly (without
xen). Full boot log is below.
Thanks,
Nathan
root (hd0,0)
Filesystem type is ext2fs, partition type 0xfd
kernel /boot/xen.gz console=com1,com2,vga com1=115200,8n1
com2=115200,8n1 dom0_
mem=1024M dom0_max_vcpus=1 dom0_vcpus_pin=true earlyprintk=xen
[Multiboot-elf, <0x100000:0x188518:0x4cae8>, shtab=0x2d5078,
entry=0x100000]
module /boot/vmlinuz root=/dev/md0 max_loop=128 console=tty0
console=ttyS0,1152
00 console=ttyS1,115200
[Multiboot-module @ 0x2d6000, 0x4a2440 bytes]
{ __ __ _ _ _ ___ _____
\ \/ /___ _ __ | || | / | / _ \ _ __ ___|___ / _ __ _ __ ___
\ // _ \ '_ \ | || |_ | || | | |__| '__/ __| |_ \ __| '_ \| '__/ _ \
/ \ __/ | | | |__ _|| || |_| |__| | | (__ ___) |__| |_) | | | __/
/_/\_\___|_| |_| |_|(_)_(_)___/ |_| \___|____/ | .__/|_| \___|
|_|
(XEN) Xen version 4.1.0-rc3-pre (root@nmsrv.com) (gcc version 4.3.4
(Gentoo 4.3.4 p1.1, pie-10.1.5) ) Tue Feb 1 15:59:16 PST 2011
(XEN) Latest ChangeSet: Tue Feb 01 19:26:36 2011 +0000 22858:9a6458e0c3f5
(XEN) Bootloader: GNU GRUB 0.97
(XEN) Command line: console=com1,com2,vga com1=115200,8n1
com2=115200,8n1 dom0_mem=1024M dom0_max_vcpus=1 dom0_vcpus_pin=true
earlyprintk=xen
(XEN) Video information:
(XEN) VGA is text mode 80x25, font 8x16
(XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds
(XEN) EDID info not retrieved because no DDC retrieval method
detected 00AB
(XEN) Disc information:
(XEN) Found 3 MBR signatures
(XEN) Found 3 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN) 0000000000000000 - 000000000009dc00 (usable)
(XEN) 000000000009dc00 - 00000000000a0000 (reserved)
(XEN) 00000000000e6000 - 0000000000100000 (reserved)
(XEN) 0000000000100000 - 00000000bf760000 (usable)
(XEN) 00000000bf76e000 - 00000000bf770000 type 9
(XEN) 00000000bf770000 - 00000000bf77e000 (ACPI data)
(XEN) 00000000bf77e000 - 00000000bf7d0000 (ACPI NVS)
(XEN) 00000000bf7d0000 - 00000000bf7e0000 (reserved)
(XEN) 00000000bf7ec000 - 00000000c0000000 (reserved)
(XEN) 00000000e0000000 - 00000000f0000000 (reserved)
(XEN) 00000000fee00000 - 00000000fee01000 (reserved)
(XEN) 00000000ffc00000 - 0000000100000000 (reserved)
(XEN) 0000000100000000 - 0000000a40000000 (usable)
(XEN) ACPI: RSDP 000F9FB0, 0024 (r2 ACPIAM)
(XEN) ACPI: XSDT BF770100, 008C (r1 SMCI 20101005 MSFT 97)
(XEN) ACPI: FACP BF770290, 00F4 (r3 100510 FACP1516 20101005 MSFT 97)
(XEN) ACPI: DSDT BF7706A0, 5A4A (r1 30007 30007000 0 INTL 20051117)
(XEN) ACPI: FACS BF77E000, 0040
(XEN) ACPI: APIC BF770390, 011E (r1 100510 APIC1516 20101005 MSFT 97)
(XEN) ACPI: MCFG BF7704B0, 003C (r1 100510 OEMMCFG 20101005 MSFT 97)
(XEN) ACPI: SLIT BF7704F0, 0030 (r1 100510 OEMSLIT 20101005 MSFT 97)
(XEN) ACPI: OEMB BF77E040, 0082 (r1 100510 OEMB1516 20101005 MSFT 97)
(XEN) ACPI: SRAT BF77A6A0, 0190 (r1 100510 OEMSRAT 1 INTL 1)
(XEN) ACPI: HPET BF77A830, 0038 (r1 100510 OEMHPET 20101005 MSFT 97)
(XEN) ACPI: DMAR BF77E0D0, 0130 (r1 AMI OEMDMAR 1 MSFT 97)
(XEN) ACPI: SSDT BF780AC0, 12C9 (r1 DpgPmm CpuPm 12 INTL 20051117)
(XEN) ACPI: EINJ BF77A870, 0130 (r1 AMIER AMI_EINJ 20101005 MSFT 97)
(XEN) ACPI: BERT BF77AA00, 0030 (r1 AMIER AMI_BERT 20101005 MSFT 97)
(XEN) ACPI: ERST BF77AA30, 01B0 (r1 AMIER AMI_ERST 20101005 MSFT 97)
(XEN) ACPI: HEST BF77ABE0, 00A8 (r1 AMIER ABC_HEST 20101005 MSFT 97)
(XEN) System RAM: 40950MB (41933812kB)
(XEN) SRAT: PXM 0
(XEN) SRAT: PXM 0 -> APIC 4 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 16 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 18 -> Node 0
(XEN) SRAT: PXM 0 -> APIC 20 -> Node 0
(XEN) SRAT: PXM 1 -> APIC 32 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 34 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 36 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 48 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 50 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 52 -> Node 1
(XEN) SRAT: Node 0 PXM 0 0-a0000
(XEN) SRAT: Node 0 PXM 0 100000-c0000000
(XEN) SRAT: Node 0 PXM 0 100000000-640000000
(XEN) SRAT: Node 1 PXM 1 640000000-a40000000
(XEN) NUMA: Allocated memnodemap from a3eac5000 - a3ead0000
(XEN) NUMA: Using 8 for the hash shift.
(XEN) Domain heap initialised DMA width 32 bits
(XEN) found SMP MP-table at 000ff780
(XEN) DMI present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x808
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[800,0]
(XEN) ACPI: wakeup_vec[bf77e00c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee00000
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) Processor #0 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) Processor #2 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled)
(XEN) Processor #4 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x10] enabled)
(XEN) Processor #16 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x12] enabled)
(XEN) Processor #18 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x14] enabled)
(XEN) Processor #20 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x20] enabled)
(XEN) Processor #32 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x22] enabled)
(XEN) Processor #34 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x24] enabled)
(XEN) Processor #36 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x30] enabled)
(XEN) Processor #48 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x32] enabled)
(XEN) Processor #50 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x34] enabled)
(XEN) Processor #52 6:12 APIC version 21
(XEN) ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x8c] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x8d] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x8e] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x10] lapic_id[0x8f] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x11] lapic_id[0x90] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x12] lapic_id[0x91] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x13] lapic_id[0x92] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x14] lapic_id[0x93] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x15] lapic_id[0x94] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x16] lapic_id[0x95] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x17] lapic_id[0x96] disabled)
(XEN) ACPI: LAPIC (acpi_id[0x18] lapic_id[0x97] disabled)
(XEN) ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
(XEN) Overriding APIC driver with bigsmp
(XEN) ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
(XEN) ACPI: IOAPIC (id[0x03] address[0xfec8a000] gsi_base[24])
(XEN) IOAPIC[1]: apic_id 3, version 32, address 0xfec8a000, GSI 24-47
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode: Phys. Using 2 I/O APICs
(XEN) ACPI: HPET id: 0x8086a301 base: 0xfed00000
(XEN) PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
(XEN) PCI: MCFG area at e0000000 reserved in E820
(XEN) ERST table is invalid
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) IRQ limits: 48 GSI, 2272 MSI/MSI-X
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2266.813 MHz processor.
(XEN) Initing memory sharing.
(XEN) mce_intel.c:1162: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0
extended MCE MSR 0
(XEN) Intel machine check reporting enabled
(XEN) Intel VT-d Snoop Control enabled.
(XEN) Intel VT-d Dom0 DMA Passthrough not enabled.
(XEN) Intel VT-d Queued Invalidation enabled.
(XEN) Intel VT-d Interrupt Remapping not enabled.
(XEN) I/O virtualisation enabled
(XEN) - Dom0 mode: Relaxed
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN) -> Using old ACK method
(XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
(XEN) Platform timer is 14.318MHz HPET
N) Allocated console ring of 128 KiB.
(XEN) VMX: Supported advanced features:
(XEN) - APIC MMIO access virtualisation
(XEN) - APIC TPR shadow
(XEN) - Extended Page Tables (EPT)
(XEN) - Virtual-Processor Identifiers (VPID)
(XEN) - Virtual NMI
(XEN) - MSR direct-access bitmap
(XEN) - Unrestricted Guest
(XEN) EPT supports 1GB super page.
(XEN) EPT supports 2MB super page.
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging detected.
(XEN) Brought up 12 CPUs
(XEN) ACPI sleep modes: S3
(XEN) mcheck_poll: Machine check polling timer started.
(XEN) *** LOADING DOMAIN 0 ***
(XEN) elf_parse_binary: phdr: paddr=0x1000000 memsz=0x90e000
(XEN) elf_parse_binary: phdr: paddr=0x190e000 memsz=0xd0228
(XEN) elf_parse_binary: phdr: paddr=0x19df000 memsz=0x888
(XEN) elf_parse_binary: phdr: paddr=0x19e0000 memsz=0x159d8
(XEN) elf_parse_binary: phdr: paddr=0x19f6000 memsz=0x289000
(XEN) elf_parse_binary: memory: 0x1000000 -> 0x1c7f000
(XEN) elf_xen_parse_note: GUEST_OS = "linux"
(XEN) elf_xen_parse_note: GUEST_VERSION = "2.6"
(XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0"
(XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000
(XEN) elf_xen_parse_note: ENTRY = 0xffffffff819f6200
(XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81009000
(XEN) elf_xen_parse_note: FEATURES =
"!writable_page_tables|pae_pgdir_above_4gb"
(XEN) elf_xen_parse_note: PAE_MODE = "yes"
(XEN) elf_xen_parse_note: LOADER = "generic"
(XEN) elf_xen_parse_note: unknown xen elf note (0xd)
(XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1
(XEN) elf_xen_parse_note: HV_START_LOW = 0xffff800000000000
(XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0
(XEN) elf_xen_addr_calc_check: addresses:
(XEN) virt_base = 0xffffffff80000000
(XEN) elf_paddr_offset = 0x0
(XEN) virt_offset = 0xffffffff80000000
(XEN) virt_kstart = 0xffffffff81000000
(XEN) virt_kend = 0xffffffff81c7f000
(XEN) virt_entry = 0xffffffff819f6200
(XEN) p2m_base = 0xffffffffffffffff
(XEN) Xen kernel: 64-bit, lsb, compat32
(XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1c7f000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN) Dom0 alloc.: 0000000438000000->000000043a000000 (253952 pages
to be allocated)
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN) Loaded kernel: ffffffff81000000->ffffffff81c7f000
(XEN) Init. ramdisk: ffffffff81c7f000->ffffffff81c7f000
(XEN) Phys-Mach map: ffffffff81c7f000->ffffffff81e7f000
(XEN) Start info: ffffffff81e7f000->ffffffff81e7f4b4
(XEN) Page tables: ffffffff81e80000->ffffffff81e93000
(XEN) Boot stack: ffffffff81e93000->ffffffff81e94000
(XEN) TOTAL: ffffffff80000000->ffffffff82000000
(XEN) ENTRY ADDRESS: ffffffff819f6200
(XEN) Dom0 has maximum 1 VCPUs
(XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff8190e000
(XEN) elf_load_binary: phdr 1 at 0xffffffff8190e000 -> 0xffffffff819de228
(XEN) elf_load_binary: phdr 2 at 0xffffffff819df000 -> 0xffffffff819df888
(XEN) elf_load_binary: phdr 3 at 0xffffffff819e0000 -> 0xffffffff819f59d8
(XEN) elf_load_binary: phdr 4 at 0xffffffff819f6000 -> 0xffffffff81a7d000
(XEN) Scrubbing Free RAM:
........................................................................................................................................................................................................................................................................................................................................................................................................done.
(XEN) Xen trace buffers: disabled
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 224kB init memory.
mapping kernel into physical memory
Xen: setup ISA identity maps
about to get started...
(XEN) d0:v0: unhandled page fault (ec=0000)
(XEN) Pagetable walk from ffffffff81c8e498:
(XEN) L4[0x1ff] = 0000000439003067 0000000000001003
(XEN) L3[0x1fe] = 0000000439007067 0000000000001007
(XEN) L2[0x00e] = 0000000000000000 ffffffffffffffff
(XEN) domain_crash_sync called from entry.S
(XEN) Domain 0 (vcpu#0) crashed on cpu#0:
(XEN) ----[ Xen-4.1.0-rc3-pre x86_64 debug=y Not tainted ]----
(XEN) CPU: 0
(XEN) RIP: e033:[<ffffffff81037544>]
(XEN) RFLAGS: 0000000000000206 EM: 1 CONTEXT: pv guest
(XEN) rax: ffffffff81c8e000 rbx: 8000000001e93063 rcx: 000000000000000f
(XEN) rdx: 0000000000000000 rsi: 0000000001e93000 rdi: 0000000000000093
(XEN) rbp: ffffffff8190fb78 rsp: ffffffff8190fb30 r8: 000000000000000e
(XEN) r9: 000000000000000f r10: 000000000000000f r11: 0000000001e93000
(XEN) r12: ffffffff81a80000 r13: 0000000000000000 r14: 0000000000000001
(XEN) r15: 0000000001e93000 cr0: 000000008005003b cr4: 00000000000026f0
(XEN) cr3: 0000000439001000 cr2: ffffffff81c8e498
(XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e02b cs: e033
(XEN) Guest stack trace from rsp=ffffffff8190fb30:
(XEN) 000000000000000f 0000000001e93000 0000000000000000 ffffffff81037544
(XEN) 000000010000e030 0000000000010006 ffffffff8190fb78 000000000000e02b
(XEN) ffffffff8190fbc0 ffffffff8190fb88 ffffffff8103755c ffffffff8190fba0
(XEN) ffffffff8103765e 8000000001e93063 ffffffff8190fbc0 ffffffff81037def
(XEN) 000000000000000f ffffffffff400000 ffffffff8190fc10 ffffffff810373cf
(XEN) 0000000001e93000 000000000000000f 000000000000000f 000000000000000e
(XEN) 8000000001e93063 0000000001e93000 8000000000000163 0000000340000000
(XEN) ffffffff8190fc48 ffffffff81a0b3af 0000000000000000 ffffffff8190fcd8
(XEN) ffffffff81079590 00000000000009ff 0000000001e93000 ffffffff8190fc88
(XEN) ffffffff81a0b595 8000000000000163 0000000001e93000 8000000000000163
(XEN) ffffffff8190fd28 0000000100000000 0000000340000000 ffffffff8190fc98
(XEN) ffffffff81a0b635 ffffffff8190fcc8 ffffffff815f9e68 0000000000000000
(XEN) 0000000340000000 8000000000000163 ffff880001002020 ffffffff8190fd58
(XEN) ffffffff81a32833 ffffffff8190fdb8 ffffffff8161c9f1 0000000000000000
(XEN) 0000000000000000 0000000340000000 ffff880001002000 0000000000000000
(XEN) 0000000000000004 0000000000000000 000000000000000f ffffffff8182a535
(XEN) 0000000340000000 0000000000000001 ffffffff81001880 ffff880100000000
(XEN) ffff880340000000 ffffffff8190fdb8 ffffffff81a329df ffffffff8190fd88
(XEN) 0000000000000000 ffff880340000000 ffff880001007078 ffffffff8190fdb8
(XEN) ffffffff8190fe20 0000000000000001 0000000000000000 ffffffff8186aff9
(XEN) Domain 0 crashed: rebooting machine in 5 seconds.
^ permalink raw reply
* [PATCHv5] OMAP3: Devkit8000: Change lcd power pin
From: Tony Lindgren @ 2011-02-02 0:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=mbJrNSfRqRzqAvKmhU-LgRiYq0KDC2zekWdqm@mail.gmail.com>
* Thomas Weber <thomas.weber.linux@googlemail.com> [110201 13:22]:
> On Thu, Jan 20, 2011 at 4:41 PM, Thomas Weber <weber@corscience.de> wrote:
> > This patch fixes a wrongly used lcd enable pin.
...
> Hello Tony,
> can you apply this patch?
Thanks adding to devel-fixes for the -rc cycle.
Tony
^ permalink raw reply
* Re: [PATCHv5] OMAP3: Devkit8000: Change lcd power pin
From: Tony Lindgren @ 2011-02-02 0:04 UTC (permalink / raw)
To: Thomas Weber
Cc: linux-omap, Russell King, open list:ARM PORT, open list,
Daniel Morsing, charu, sshtylyov, manjugk
In-Reply-To: <AANLkTi=mbJrNSfRqRzqAvKmhU-LgRiYq0KDC2zekWdqm@mail.gmail.com>
* Thomas Weber <thomas.weber.linux@googlemail.com> [110201 13:22]:
> On Thu, Jan 20, 2011 at 4:41 PM, Thomas Weber <weber@corscience.de> wrote:
> > This patch fixes a wrongly used lcd enable pin.
...
> Hello Tony,
> can you apply this patch?
Thanks adding to devel-fixes for the -rc cycle.
Tony
^ permalink raw reply
* [U-Boot] [PATCH] Fix to make U-Boot work with more USB sticks
From: Aaron Williams @ 2011-02-02 0:03 UTC (permalink / raw)
To: u-boot
In-Reply-To: <AANLkTi=QhMB+egvQu6daZnPkcctBZMv4FX7ihtAZwd+h@mail.gmail.com>
I too am interested in this. I am running EHCI and have had problems with a
number of USB storage devices, one of which (the SanDisk Cruzer) causes a
crash due to it reporting the maximum LUN as 1. I'm also seeing some
interesting performance issues with ext2 being extremely slow compared to FAT.
Additionally, I have been trying various USB hubs with EHCI and have found
that a large percentage fail to work. Hopefully I'll look into it more soon
when I get ahold of our USB analyzer again.
-Aaron
On Tuesday, February 01, 2011 11:34:00 am Remy Bohmer wrote:
> Hi,
>
> 2011/2/1 Simon Glass <sjg@chromium.org>:
> > Hi Remy,
> > Still waiting on some boards to try, unfortunately. I expect it will
> > happen in the next 2 weeks though (ARM9 and OMAP4 platforms). Once I get
> > to the bottom of it I will split the patches as requested. I have not
> > seen reports from other users of U-Boot. Also working on USB host
> > Ethernet.
> > Regards,
> > Simon
>
> FWIW: I tested it on Atmel at91 and it does not seem to break OHCI, it
> does not seem to fix some troubles USB sticks I have here either...
>
> Kind regards,
>
> Remy
^ permalink raw reply
* [PATCH] EDB93xx: Add support for CS4271 CODEC on EDB93xx boards
From: H Hartley Sweeten @ 2011-02-02 0:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1296603653.1504.9.camel@r60e>
On Tuesday, February 01, 2011 4:41 PM, Alexander Sverdlin wrote:
> From: Alexander Sverdlin <subaparts@yandex.ru>
>
> Add support for CS4271 SPI-connected CODEC on EDB93xx boards.
> Major rework based on code provided by H Hartley Sweeten <hsweeten@visionengravers.com>.
> Tested on EDB9302, others (EDB9301, EDB9302A, EDB9307A, EDB0315A) should work.
>
> Signed-off-by: Alexander Sverdlin <subaparts@yandex.ru>
> ---
> arch/arm/mach-ep93xx/edb93xx.c | 117 ++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 117 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-ep93xx/edb93xx.c b/arch/arm/mach-ep93xx/edb93xx.c
> index 4b04316..f20be96 100644
> --- a/arch/arm/mach-ep93xx/edb93xx.c
> +++ b/arch/arm/mach-ep93xx/edb93xx.c
> @@ -30,12 +30,22 @@
> #include <linux/gpio.h>
> #include <linux/i2c.h>
> #include <linux/i2c-gpio.h>
> +#include <linux/spi/spi.h>
> +#include <linux/delay.h>
> +#include <mach/ep93xx_spi.h>
>
> #include <mach/hardware.h>
>
> #include <asm/mach-types.h>
> #include <asm/mach/arch.h>
>
> +#include <sound/cs4271.h>
> +
> +#define edb93xx_has_audio() (machine_is_edb9301() || \
> + machine_is_edb9302() || \
> + machine_is_edb9302a() || \
> + machine_is_edb9307a() || \
> + machine_is_edb9315a())
>
> static void __init edb93xx_register_flash(void)
> {
> @@ -93,6 +103,111 @@ static void __init edb93xx_register_i2c(void)
>
>
> /*************************************************************************
> + * EDB93xx SPI peripheral handling
> + *************************************************************************/
> +static int edb93xx_cs4271_hw_setup(struct spi_device *spi)
> +{
> + int gpio_nreset;
> + int err;
> +
> + if (machine_is_edb9301() || machine_is_edb9302()) {
> + gpio_nreset = EP93XX_GPIO_LINE_EGPIO1;
Are you planning on removing gpio_nreset and gpio_disable from struct cs4271_platform_data?
If not, you should just setup the gpio mapping in edb93xx_register_spi before you actually
register the spi_board_info. Then this function and the following two can just do something
like the following and not worry about the if ... else if ... etc.
struct cs4271_platform_data *cs4271 = spi->dev.platform_data;
int err;
err = gpio_request(cs4271->gpio_disable, spi->modalias);
...
> + } else if (machine_is_edb9302a() || machine_is_edb9307a()) {
> + ep93xx_devcfg_set_bits(EP93XX_SYSCON_DEVCFG_HONIDE);
You shouldn't need this. The ep93xx gpio core will now defaults all the ports to gpio
mode. See commit fd015480c29deb52ae3bfaf41e888c450765edd8.
> + gpio_nreset = EP93XX_GPIO_LINE_DD2;
Please use EP93XX_GPIO_LINE_H(2) instead. None of the datasheets reference the "DD2"
gpio.
> + } else if (machine_is_edb9315a()) {
> + gpio_nreset = EP93XX_GPIO_LINE_EGPIO14;
> + } else {
> + return -EINVAL;
> + }
> +
> + err = gpio_request(gpio_nreset, spi->modalias);
> + if (err)
> + return err;
> + err = gpio_request(EP93XX_GPIO_LINE_EGPIO6, spi->modalias);
> + if (err)
> + return err;
> +
> + gpio_direction_output(EP93XX_GPIO_LINE_EGPIO6, 1);
> +
> + /* Reset codec */
> + gpio_direction_output(gpio_nreset, 0);
> + udelay(1);
> + gpio_set_value(gpio_nreset, 1);
> + /* Give the codec time to wake up */
> + udelay(1);
> +
> + return 0;
> +}
> +
> +static void edb93xx_cs4271_hw_cleanup(struct spi_device *spi)
> +{
> + int gpio_nreset;
> +
> + if (machine_is_edb9301() || machine_is_edb9302())
> + gpio_nreset = EP93XX_GPIO_LINE_EGPIO1;
> + else if (machine_is_edb9302a() || machine_is_edb9307a())
> + gpio_nreset = EP93XX_GPIO_LINE_DD2;
> + else if (machine_is_edb9315a())
> + gpio_nreset = EP93XX_GPIO_LINE_EGPIO14;
> + else
> + return;
> +
> + gpio_set_value(gpio_nreset, 0);
> + gpio_free(gpio_nreset);
> +
> + gpio_set_value(EP93XX_GPIO_LINE_EGPIO6, 1);
> + gpio_free(EP93XX_GPIO_LINE_EGPIO6);
> +}
> +
> +static void edb93xx_cs4271_hw_cs_control(struct spi_device *spi, int value)
> +{
> + gpio_set_value(EP93XX_GPIO_LINE_EGPIO6, value);
> +}
> +
> +static struct ep93xx_spi_chip_ops edb93xx_cs4271_hw = {
> + .setup = edb93xx_cs4271_hw_setup,
> + .cleanup = edb93xx_cs4271_hw_cleanup,
> + .cs_control = edb93xx_cs4271_hw_cs_control,
> +};
> +
> +static struct spi_board_info edb93xx_spi_board_info[] __initdata = {
> + {
> + .modalias = "cs4271",
> + .controller_data = &edb93xx_cs4271_hw,
> + .max_speed_hz = 6000000,
> + .bus_num = 0,
> + .chip_select = 0,
> + .mode = SPI_MODE_3,
> + },
> +};
> +
> +static struct ep93xx_spi_info edb93xx_spi_info = {
> + .num_chipselect = ARRAY_SIZE(edb93xx_spi_board_info),
> +};
> +
> +static void __init edb93xx_register_spi(void)
> +{
> + if (edb93xx_has_audio()) {
> + ep93xx_register_spi(&edb93xx_spi_info,
> + edb93xx_spi_board_info,
> + ARRAY_SIZE(edb93xx_spi_board_info));
> + }
> +}
> +
> +
> +/*************************************************************************
> + * EDB93xx I2S
> + *************************************************************************/
> +static void __init edb93xx_register_i2s(void)
> +{
> + if (edb93xx_has_audio()) {
> + ep93xx_register_i2s();
> + }
> +}
> +
> +
> +/*************************************************************************
> * EDB93xx pwm
> *************************************************************************/
> static void __init edb93xx_register_pwm(void)
> @@ -117,6 +232,8 @@ static void __init edb93xx_init_machine(void)
> edb93xx_register_flash();
> ep93xx_register_eth(&edb93xx_eth_data, 1);
> edb93xx_register_i2c();
> + edb93xx_register_spi();
> + edb93xx_register_i2s();
> edb93xx_register_pwm();
> }
>
Other than using struct cs4271_platform_data to hold the gpio information, this
looks better. Now other spi devices can live on bus.
Hartley
^ permalink raw reply
* RE: [PATCH] EDB93xx: Add support for CS4271 CODEC on EDB93xx boards
From: H Hartley Sweeten @ 2011-02-02 0:02 UTC (permalink / raw)
To: Alexander Sverdlin, linux-arm-kernel@lists.infradead.org,
alsa-devel@alsa-project.org
Cc: Lennert Buytenhek
In-Reply-To: <1296603653.1504.9.camel@r60e>
On Tuesday, February 01, 2011 4:41 PM, Alexander Sverdlin wrote:
> From: Alexander Sverdlin <subaparts@yandex.ru>
>
> Add support for CS4271 SPI-connected CODEC on EDB93xx boards.
> Major rework based on code provided by H Hartley Sweeten <hsweeten@visionengravers.com>.
> Tested on EDB9302, others (EDB9301, EDB9302A, EDB9307A, EDB0315A) should work.
>
> Signed-off-by: Alexander Sverdlin <subaparts@yandex.ru>
> ---
> arch/arm/mach-ep93xx/edb93xx.c | 117 ++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 117 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-ep93xx/edb93xx.c b/arch/arm/mach-ep93xx/edb93xx.c
> index 4b04316..f20be96 100644
> --- a/arch/arm/mach-ep93xx/edb93xx.c
> +++ b/arch/arm/mach-ep93xx/edb93xx.c
> @@ -30,12 +30,22 @@
> #include <linux/gpio.h>
> #include <linux/i2c.h>
> #include <linux/i2c-gpio.h>
> +#include <linux/spi/spi.h>
> +#include <linux/delay.h>
> +#include <mach/ep93xx_spi.h>
>
> #include <mach/hardware.h>
>
> #include <asm/mach-types.h>
> #include <asm/mach/arch.h>
>
> +#include <sound/cs4271.h>
> +
> +#define edb93xx_has_audio() (machine_is_edb9301() || \
> + machine_is_edb9302() || \
> + machine_is_edb9302a() || \
> + machine_is_edb9307a() || \
> + machine_is_edb9315a())
>
> static void __init edb93xx_register_flash(void)
> {
> @@ -93,6 +103,111 @@ static void __init edb93xx_register_i2c(void)
>
>
> /*************************************************************************
> + * EDB93xx SPI peripheral handling
> + *************************************************************************/
> +static int edb93xx_cs4271_hw_setup(struct spi_device *spi)
> +{
> + int gpio_nreset;
> + int err;
> +
> + if (machine_is_edb9301() || machine_is_edb9302()) {
> + gpio_nreset = EP93XX_GPIO_LINE_EGPIO1;
Are you planning on removing gpio_nreset and gpio_disable from struct cs4271_platform_data?
If not, you should just setup the gpio mapping in edb93xx_register_spi before you actually
register the spi_board_info. Then this function and the following two can just do something
like the following and not worry about the if ... else if ... etc.
struct cs4271_platform_data *cs4271 = spi->dev.platform_data;
int err;
err = gpio_request(cs4271->gpio_disable, spi->modalias);
...
> + } else if (machine_is_edb9302a() || machine_is_edb9307a()) {
> + ep93xx_devcfg_set_bits(EP93XX_SYSCON_DEVCFG_HONIDE);
You shouldn't need this. The ep93xx gpio core will now defaults all the ports to gpio
mode. See commit fd015480c29deb52ae3bfaf41e888c450765edd8.
> + gpio_nreset = EP93XX_GPIO_LINE_DD2;
Please use EP93XX_GPIO_LINE_H(2) instead. None of the datasheets reference the "DD2"
gpio.
> + } else if (machine_is_edb9315a()) {
> + gpio_nreset = EP93XX_GPIO_LINE_EGPIO14;
> + } else {
> + return -EINVAL;
> + }
> +
> + err = gpio_request(gpio_nreset, spi->modalias);
> + if (err)
> + return err;
> + err = gpio_request(EP93XX_GPIO_LINE_EGPIO6, spi->modalias);
> + if (err)
> + return err;
> +
> + gpio_direction_output(EP93XX_GPIO_LINE_EGPIO6, 1);
> +
> + /* Reset codec */
> + gpio_direction_output(gpio_nreset, 0);
> + udelay(1);
> + gpio_set_value(gpio_nreset, 1);
> + /* Give the codec time to wake up */
> + udelay(1);
> +
> + return 0;
> +}
> +
> +static void edb93xx_cs4271_hw_cleanup(struct spi_device *spi)
> +{
> + int gpio_nreset;
> +
> + if (machine_is_edb9301() || machine_is_edb9302())
> + gpio_nreset = EP93XX_GPIO_LINE_EGPIO1;
> + else if (machine_is_edb9302a() || machine_is_edb9307a())
> + gpio_nreset = EP93XX_GPIO_LINE_DD2;
> + else if (machine_is_edb9315a())
> + gpio_nreset = EP93XX_GPIO_LINE_EGPIO14;
> + else
> + return;
> +
> + gpio_set_value(gpio_nreset, 0);
> + gpio_free(gpio_nreset);
> +
> + gpio_set_value(EP93XX_GPIO_LINE_EGPIO6, 1);
> + gpio_free(EP93XX_GPIO_LINE_EGPIO6);
> +}
> +
> +static void edb93xx_cs4271_hw_cs_control(struct spi_device *spi, int value)
> +{
> + gpio_set_value(EP93XX_GPIO_LINE_EGPIO6, value);
> +}
> +
> +static struct ep93xx_spi_chip_ops edb93xx_cs4271_hw = {
> + .setup = edb93xx_cs4271_hw_setup,
> + .cleanup = edb93xx_cs4271_hw_cleanup,
> + .cs_control = edb93xx_cs4271_hw_cs_control,
> +};
> +
> +static struct spi_board_info edb93xx_spi_board_info[] __initdata = {
> + {
> + .modalias = "cs4271",
> + .controller_data = &edb93xx_cs4271_hw,
> + .max_speed_hz = 6000000,
> + .bus_num = 0,
> + .chip_select = 0,
> + .mode = SPI_MODE_3,
> + },
> +};
> +
> +static struct ep93xx_spi_info edb93xx_spi_info = {
> + .num_chipselect = ARRAY_SIZE(edb93xx_spi_board_info),
> +};
> +
> +static void __init edb93xx_register_spi(void)
> +{
> + if (edb93xx_has_audio()) {
> + ep93xx_register_spi(&edb93xx_spi_info,
> + edb93xx_spi_board_info,
> + ARRAY_SIZE(edb93xx_spi_board_info));
> + }
> +}
> +
> +
> +/*************************************************************************
> + * EDB93xx I2S
> + *************************************************************************/
> +static void __init edb93xx_register_i2s(void)
> +{
> + if (edb93xx_has_audio()) {
> + ep93xx_register_i2s();
> + }
> +}
> +
> +
> +/*************************************************************************
> * EDB93xx pwm
> *************************************************************************/
> static void __init edb93xx_register_pwm(void)
> @@ -117,6 +232,8 @@ static void __init edb93xx_init_machine(void)
> edb93xx_register_flash();
> ep93xx_register_eth(&edb93xx_eth_data, 1);
> edb93xx_register_i2c();
> + edb93xx_register_spi();
> + edb93xx_register_i2s();
> edb93xx_register_pwm();
> }
>
Other than using struct cs4271_platform_data to hold the gpio information, this
looks better. Now other spi devices can live on bus.
Hartley
^ permalink raw reply
* Re: [PATCH v2] OMAP: fix fncpy API call
From: Tony Lindgren @ 2011-02-02 0:01 UTC (permalink / raw)
To: Dave Martin; +Cc: jean.pihet, linux-omap, Jean Pihet
In-Reply-To: <AANLkTinU5Msop=Lg7iuSfNZXa+7NQCwcrN2hB1a1T9Ds@mail.gmail.com>
* Dave Martin <dave.martin@linaro.org> [110201 08:34]:
> On Tue, Jan 25, 2011 at 5:48 PM, <jean.pihet@newoldbits.com> wrote:
> > From: Jean Pihet <j-pihet@ti.com>
> >
> > Fix a potential problem with function types when calling the
> > fncpy API to copy the PM code functions to SRAM.
> >
> > Signed-off-by: Jean Pihet <j-pihet@ti.com>
> > ---
> > arch/arm/plat-omap/include/plat/sram.h | 4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/plat-omap/include/plat/sram.h b/arch/arm/plat-omap/include/plat/sram.h
> > index d673f2c..f500fc3 100644
> > --- a/arch/arm/plat-omap/include/plat/sram.h
> > +++ b/arch/arm/plat-omap/include/plat/sram.h
> > @@ -18,10 +18,10 @@ extern void *omap_sram_push_address(unsigned long size);
> >
> > /* Macro to push a function to the internal SRAM, using the fncpy API */
> > #define omap_sram_push(funcp, size) ({ \
> > - typeof(&funcp) _res = NULL; \
> > + typeof(&(funcp)) _res = NULL; \
> > void *_sram_address = omap_sram_push_address(size); \
> > if (_sram_address) \
> > - _res = fncpy(_sram_address, &funcp, size); \
> > + _res = fncpy(_sram_address, &(funcp), size); \
> > _res; \
> > })
>
> I believe this is sound, though I'm not yet in a position to test it fully.
>
> When I have the OMAP kernel building with Thumb-2 again I will follow up.
>
> Cheers
> ---Dave
>
>
> Reviewed-by: Dave Martin <dave.martin@linaro.org>
Looks good to me too:
Acked-by: Tony Lindgren <tony@atomide.com>
I'll add this to omap-testing branch, but as Russell has this queued,
you'll have to send this to him on linux-arm-kernel list.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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
* [U-Boot] [GIT PULL] Pull request: u-boot-imx
From: Albert ARIBAUD @ 2011-02-01 23:58 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4D484D2F.4070305@denx.de>
Hi Stefano,
Le 01/02/2011 19:13, Stefano Babic a ?crit :
> Hi Albert,
>
> here my pull request for u-boot-imx. Since my last pull-request, I
> rebased my tree to substitute:
>
> imximage: Add MX53 boot image support
>
> I fixed the wrong mode,too, and I cherry-picked from u-boot-arm:
>
> ARM: fix broken build of ARM
>
> that you have already merged, to avoid leaving u-boot-imx broken. I hope
> this is not a problem for you.
Pulled into u-boot-arm/master, thanks -- had to force update, though.
Amicalement,
--
Albert.
^ permalink raw reply
* Re: [PATCH] ASoC: EDB93xx machine sound driver with CS4271
From: Alexander Sverdlin @ 2011-02-01 23:58 UTC (permalink / raw)
To: todorcolov; +Cc: alsa-devel
Dear Todor,
> Zdrastvuj Aleks,
> I'd like to test the sound module. Which is the latest patch versions
> and
> coresponding kernel version? In which official kernel release do you
> plan to
> merge it?
As I can conclude from list, you should see it in 2.6.39 and possibly
-next already. 75% of the driver has been merged already. All you have
to do to start testing is to add patch that I've just sent to the list
([PATCH] EDB93xx: Add support for CS4271 CODEC on EDB93xx boards).
Best regards,
Alexander.
^ permalink raw reply
* Mutual Aid Stash of Fortune
From: George @ 2011-02-01 23:56 UTC (permalink / raw)
Mutual Aid Stash of Fortune
Hi
I would hold back certain information for security reasons for now until
you have found time to visit the BBC website stated below to enable you
have an insight into what I intend sharing with you.
http://news.bbc.co.uk/2/hi/middle_east/2988455.stm
Get back to me having visited the above website with this email:
ivannickerson.claims-/E1597aS9LTXPF5Rlphj1Q@public.gmane.org
Best Regards
A former member of the 3rd Infantry Division
^ permalink raw reply
* another test message (checking List-ID: header)
From: David Rientjes @ 2011-02-01 23:55 UTC (permalink / raw)
To: linux-mm
Test message for Gmail diagnostics, please ignore.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 1/4] omap1: remove duplicated #include
From: Tony Lindgren @ 2011-02-01 23:53 UTC (permalink / raw)
To: Huang Weiyi; +Cc: linux-omap
In-Reply-To: <1296223478-728-1-git-send-email-weiyi.huang@gmail.com>
* Huang Weiyi <weiyi.huang@gmail.com> [110128 06:03]:
> Remove duplicated #include('s) in
> arch/arm/mach-omap1/time.c
>
> Signed-off-by: Huang Weiyi <weiyi.huang@gmail.com>
> ---
> arch/arm/mach-omap1/time.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap1/time.c b/arch/arm/mach-omap1/time.c
> index f83fc33..6885d2f 100644
> --- a/arch/arm/mach-omap1/time.c
> +++ b/arch/arm/mach-omap1/time.c
> @@ -44,7 +44,6 @@
> #include <linux/clocksource.h>
> #include <linux/clockchips.h>
> #include <linux/io.h>
> -#include <linux/sched.h>
>
> #include <asm/system.h>
> #include <mach/hardware.h>
Thanks queuing this as a fix for the -rc cycle.
Tony
^ permalink raw reply
* Re: [PATCH] arm: mach-omap2: board-rm680: fix rm680_vemmc regulator constraints
From: Tony Lindgren @ 2011-02-01 23:52 UTC (permalink / raw)
To: Jarkko Nikula; +Cc: Aaro Koskinen, linux-omap, linux-arm-kernel
In-Reply-To: <20110201202725.804aa011.jhnikula@gmail.com>
* Jarkko Nikula <jhnikula@gmail.com> [110201 10:26]:
> On Tue, 1 Feb 2011 17:36:28 +0200
> Aaro Koskinen <aaro.koskinen@nokia.com> wrote:
>
> > With the commit 757902513019e6ee469791ff76f954b19ca8d036 fixed voltage
> > regulator setup will fail if there are voltage constraints defined. This
> > made MMC unusable on this board. Fix by just deleting those redundant
> > constraints.
> >
> True. Before there were a test min_uV == max_uV && ops->set_voltage and
> now min_uV == max_uV followed by test for ops->set_voltage that returns
> EINVAL if not set (NULL for fixed voltage regulator obviously).
>
> Reviewed-by: Jarkko Nikula <jhnikula@gmail.com>
Thanks adding into devel-fixes.
Tony
^ permalink raw reply
* [PATCH] arm: mach-omap2: board-rm680: fix rm680_vemmc regulator constraints
From: Tony Lindgren @ 2011-02-01 23:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110201202725.804aa011.jhnikula@gmail.com>
* Jarkko Nikula <jhnikula@gmail.com> [110201 10:26]:
> On Tue, 1 Feb 2011 17:36:28 +0200
> Aaro Koskinen <aaro.koskinen@nokia.com> wrote:
>
> > With the commit 757902513019e6ee469791ff76f954b19ca8d036 fixed voltage
> > regulator setup will fail if there are voltage constraints defined. This
> > made MMC unusable on this board. Fix by just deleting those redundant
> > constraints.
> >
> True. Before there were a test min_uV == max_uV && ops->set_voltage and
> now min_uV == max_uV followed by test for ops->set_voltage that returns
> EINVAL if not set (NULL for fixed voltage regulator obviously).
>
> Reviewed-by: Jarkko Nikula <jhnikula@gmail.com>
Thanks adding into devel-fixes.
Tony
^ permalink raw reply
* Re: [PATCH] arm: mach-omap2: mux: free allocated memory on error exit
From: Tony Lindgren @ 2011-02-01 23:52 UTC (permalink / raw)
To: Aaro Koskinen; +Cc: linux-arm-kernel, linux-omap
In-Reply-To: <1296226255-5694-1-git-send-email-aaro.koskinen@nokia.com>
* Aaro Koskinen <aaro.koskinen@nokia.com> [110128 06:47]:
> Free allocated memory on error exit.
>
> Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com>
> ---
> arch/arm/mach-omap2/mux.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
> index df8d2f2..18aea0c 100644
> --- a/arch/arm/mach-omap2/mux.c
> +++ b/arch/arm/mach-omap2/mux.c
> @@ -1000,6 +1000,7 @@ int __init omap_mux_init(const char *name, u32 flags,
> if (!partition->base) {
> pr_err("%s: Could not ioremap mux partition at 0x%08x\n",
> __func__, partition->phys);
> + kfree(partition);
> return -ENODEV;
> }
Thanks, adding into devel-fixes for the -rc cycle.
Tony
^ permalink raw reply
* [PATCH] arm: mach-omap2: mux: free allocated memory on error exit
From: Tony Lindgren @ 2011-02-01 23:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1296226255-5694-1-git-send-email-aaro.koskinen@nokia.com>
* Aaro Koskinen <aaro.koskinen@nokia.com> [110128 06:47]:
> Free allocated memory on error exit.
>
> Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com>
> ---
> arch/arm/mach-omap2/mux.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
> index df8d2f2..18aea0c 100644
> --- a/arch/arm/mach-omap2/mux.c
> +++ b/arch/arm/mach-omap2/mux.c
> @@ -1000,6 +1000,7 @@ int __init omap_mux_init(const char *name, u32 flags,
> if (!partition->base) {
> pr_err("%s: Could not ioremap mux partition at 0x%08x\n",
> __func__, partition->phys);
> + kfree(partition);
> return -ENODEV;
> }
Thanks, adding into devel-fixes for the -rc cycle.
Tony
^ permalink raw reply
* [PATCH] MAINTAINERS: remove stale reference to Chris Wright's LSM tree
From: Lucian Adrian Grijincu @ 2011-02-01 23:51 UTC (permalink / raw)
To: linux-kernel, Chris Wright; +Cc: Lucian Adrian Grijincu
A quick glance at [1] will show that the tree hasn't been updated
since June 2008 => No need to have a reference to it.
[1] http://git.kernel.org/?p=linux/kernel/git/chrisw/lsm-2.6.git;a=summary
Signed-off-by: Lucian Adrian Grijincu <lucian.grijincu@gmail.com>
---
MAINTAINERS | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 445537d..0a4b0ff 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3866,7 +3866,6 @@ F: drivers/*/*/*pasemi*
LINUX SECURITY MODULE (LSM) FRAMEWORK
M: Chris Wright <chrisw@sous-sol.org>
L: linux-security-module@vger.kernel.org
-T: git git://git.kernel.org/pub/scm/linux/kernel/git/chrisw/lsm-2.6.git
S: Supported
LLC (802.2)
--
1.7.4.rc1.7.g2cf08.dirty
^ permalink raw reply related
* [folded] memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix.patch removed from -mm tree
From: akpm @ 2011-02-01 23:48 UTC (permalink / raw)
To: hannes, balbir, kamezawa.hiroyu, minchan.kim, nishimura,
mm-commits
The patch titled
memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix
has been removed from the -mm tree. Its filename was
memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix.patch
This patch was dropped because it was folded into memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix
From: Johannes Weiner <hannes@cmpxchg.org>
res_counter: document res_counter_check_margin()
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Minchan Kim <minchan.kim@gmail.com>
Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
Cc: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/res_counter.h | 8 ++++++++
1 file changed, 8 insertions(+)
diff -puN include/linux/res_counter.h~memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix include/linux/res_counter.h
--- a/include/linux/res_counter.h~memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix
+++ a/include/linux/res_counter.h
@@ -182,6 +182,14 @@ static inline bool res_counter_check_und
return ret;
}
+/**
+ * res_counter_check_margin - check if the counter allows charging
+ * @cnt: the resource counter to check
+ * @bytes: the number of bytes to check the remaining space against
+ *
+ * Returns a boolean value on whether the counter can be charged
+ * @bytes or whether this would exceed the limit.
+ */
static inline bool res_counter_check_margin(struct res_counter *cnt,
unsigned long bytes)
{
_
Patches currently in -mm which might be from hannes@cmpxchg.org are
memcg-prevent-endless-loop-when-charging-huge-pages.patch
memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group.patch
memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix-fix.patch
memcg-never-oom-when-charging-huge-pages.patch
memcg-fix-event-counting-breakage-by-recent-thp-update.patch
epoll-fix-compiler-warning-and-optimize-the-non-blocking-path-fix.patch
memcg-res_counter_read_u64-fix-potential-races-on-32-bit-machines.patch
memcg-fix-ugly-initialization-of-return-value-is-in-caller.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn-fix.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn-fix-fix.patch
^ permalink raw reply
* [folded] memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix-fix.patch removed from -mm tree
From: akpm @ 2011-02-01 23:48 UTC (permalink / raw)
To: hannes, balbir, kamezawa.hiroyu, minchan.kim, nishimura,
mm-commits
The patch titled
memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix-fix
has been removed from the -mm tree. Its filename was
memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix-fix.patch
This patch was dropped because it was folded into memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix-fix
From: Johannes Weiner <hannes@cmpxchg.org>
*oink*
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Minchan Kim <minchan.kim@gmail.com>
Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
Cc: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/memcontrol.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff -puN mm/memcontrol.c~memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix-fix mm/memcontrol.c
--- a/mm/memcontrol.c~memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix-fix
+++ a/mm/memcontrol.c
@@ -1111,6 +1111,14 @@ static bool mem_cgroup_check_under_limit
return false;
}
+/**
+ * mem_cgroup_check_margin - check if the memory cgroup allows charging
+ * @mem: memory cgroup to check
+ * @bytes: the number of bytes the caller intends to charge
+ *
+ * Returns a boolean value on whether @mem can be charged @bytes or
+ * whether this would exceed the limit.
+ */
static bool mem_cgroup_check_margin(struct mem_cgroup *mem, unsigned long bytes)
{
if (!res_counter_check_margin(&mem->res, bytes))
_
Patches currently in -mm which might be from hannes@cmpxchg.org are
memcg-prevent-endless-loop-when-charging-huge-pages.patch
memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group.patch
memcg-never-oom-when-charging-huge-pages.patch
memcg-fix-event-counting-breakage-by-recent-thp-update.patch
epoll-fix-compiler-warning-and-optimize-the-non-blocking-path-fix.patch
memcg-res_counter_read_u64-fix-potential-races-on-32-bit-machines.patch
memcg-fix-ugly-initialization-of-return-value-is-in-caller.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn-fix.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn-fix-fix.patch
^ permalink raw reply
* how to get PHY error codes from AR9382 / HB116
From: George Nychis @ 2011-02-01 23:48 UTC (permalink / raw)
To: linux-wireless, Eric Rozner
Hi all,
I have an Atheros AR9382 chipset, on the 2x2 HB116.
I was wondering if anyone knows how to enable PHY error codes on this
card/chipset being passed up. Including synchronization errors, like
in the PLCP.
In: drivers/net/wireless/ath/ath9k/hw.c, and function: void
ath9k_hw_setrxfilter(struct ath_hw *ah, u32 bits)
... I did a REG_WRITE(ah, AR_PHY_ERR, 0xffffffff); to enable all phy
error packets upwards in terms of the RX filter.
I am also setting the following in ath9k_hw_ani_init
(drivers/net/wireless/ath/ath9k/ani.c)
REG_WRITE(ah, AR_PHY_ERR_1, ah->ani[0].ofdmPhyErrBase);
REG_WRITE(ah, AR_PHY_ERR_2, ah->ani[0].cckPhyErrBase);
I am also commented this out in drivers/net/wireless/ath/ath9k/recv.c:
rfilt |= ATH9K_RX_FILTER_PHYERR;
I've also tried forcing the card in to promiscuous mode.
However, when I get errored packets up from the card, they all have
the same error type which is 0x00, which makes me believe that the
actual error bits are not being set, or something along these lines.
Does anyone know what I might be missing? I'd greatly appreciate any help.
- George
^ permalink raw reply
* [folded] memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix.patch removed from -mm tree
From: akpm @ 2011-02-01 23:47 UTC (permalink / raw)
To: hannes, balbir, kamezawa.hiroyu, minchan.kim, nishimura,
mm-commits
The patch titled
memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix
has been removed from the -mm tree. Its filename was
memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix.patch
This patch was dropped because it was folded into memcg-prevent-endless-loop-when-charging-huge-pages.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix
From: Johannes Weiner <hannes@cmpxchg.org>
res_counter: document res_counter_check_margin()
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Minchan Kim <minchan.kim@gmail.com>
Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
Cc: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/res_counter.h | 8 ++++++++
1 file changed, 8 insertions(+)
diff -puN include/linux/res_counter.h~memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix include/linux/res_counter.h
--- a/include/linux/res_counter.h~memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix
+++ a/include/linux/res_counter.h
@@ -182,6 +182,14 @@ static inline bool res_counter_check_und
return ret;
}
+/**
+ * res_counter_check_margin - check if the counter allows charging
+ * @cnt: the resource counter to check
+ * @bytes: the number of bytes to check the remaining space against
+ *
+ * Returns a boolean value on whether the counter can be charged
+ * @bytes or whether this would exceed the limit.
+ */
static inline bool res_counter_check_margin(struct res_counter *cnt,
unsigned long bytes)
{
_
Patches currently in -mm which might be from hannes@cmpxchg.org are
memcg-prevent-endless-loop-when-charging-huge-pages.patch
memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix-fix.patch
memcg-never-oom-when-charging-huge-pages.patch
memcg-fix-event-counting-breakage-by-recent-thp-update.patch
epoll-fix-compiler-warning-and-optimize-the-non-blocking-path-fix.patch
memcg-res_counter_read_u64-fix-potential-races-on-32-bit-machines.patch
memcg-fix-ugly-initialization-of-return-value-is-in-caller.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn-fix.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn-fix-fix.patch
^ permalink raw reply
* [folded] memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group.patch removed from -mm tree
From: akpm @ 2011-02-01 23:47 UTC (permalink / raw)
To: hannes, balbir, kamezawa.hiroyu, minchan.kim, nishimura,
mm-commits
The patch titled
memcg: prevent endless loop when charging huge pages to near-limit group
has been removed from the -mm tree. Its filename was
memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group.patch
This patch was dropped because it was folded into memcg-prevent-endless-loop-when-charging-huge-pages.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: memcg: prevent endless loop when charging huge pages to near-limit group
From: Johannes Weiner <hannes@cmpxchg.org>
If reclaim after a failed charging was unsuccessful, the limits are
checked again, just in case they settled by means of other tasks.
This is all fine as long as every charge is of size PAGE_SIZE, because in
that case, being below the limit means having at least PAGE_SIZE bytes
available.
But with transparent huge pages, we may end up in an endless loop where
charging and reclaim fail, but we keep going because the limits are not
yet exceeded, although not allowing for a huge page.
Fix this up by explicitely checking for enough room, not just whether we
are within limits.
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Minchan Kim <minchan.kim@gmail.com>
Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
Cc: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/res_counter.h | 12 ++++++++++++
mm/memcontrol.c | 27 ++++++++++++++++++++-------
2 files changed, 32 insertions(+), 7 deletions(-)
diff -puN include/linux/res_counter.h~memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group include/linux/res_counter.h
--- a/include/linux/res_counter.h~memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group
+++ a/include/linux/res_counter.h
@@ -182,6 +182,18 @@ static inline bool res_counter_check_und
return ret;
}
+static inline bool res_counter_check_margin(struct res_counter *cnt,
+ unsigned long bytes)
+{
+ bool ret;
+ unsigned long flags;
+
+ spin_lock_irqsave(&cnt->lock, flags);
+ ret = cnt->limit - cnt->usage >= bytes;
+ spin_unlock_irqrestore(&cnt->lock, flags);
+ return ret;
+}
+
static inline bool res_counter_check_under_soft_limit(struct res_counter *cnt)
{
bool ret;
diff -puN mm/memcontrol.c~memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group mm/memcontrol.c
--- a/mm/memcontrol.c~memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group
+++ a/mm/memcontrol.c
@@ -1111,6 +1111,15 @@ static bool mem_cgroup_check_under_limit
return false;
}
+static bool mem_cgroup_check_margin(struct mem_cgroup *mem, unsigned long bytes)
+{
+ if (!res_counter_check_margin(&mem->res, bytes))
+ return false;
+ if (do_swap_account && !res_counter_check_margin(&mem->memsw, bytes))
+ return false;
+ return true;
+}
+
static unsigned int get_swappiness(struct mem_cgroup *memcg)
{
struct cgroup *cgrp = memcg->css.cgroup;
@@ -1852,15 +1861,19 @@ static int __mem_cgroup_do_charge(struct
return CHARGE_WOULDBLOCK;
ret = mem_cgroup_hierarchical_reclaim(mem_over_limit, NULL,
- gfp_mask, flags);
+ gfp_mask, flags);
+ if (mem_cgroup_check_margin(mem_over_limit, csize))
+ return CHARGE_RETRY;
/*
- * try_to_free_mem_cgroup_pages() might not give us a full
- * picture of reclaim. Some pages are reclaimed and might be
- * moved to swap cache or just unmapped from the cgroup.
- * Check the limit again to see if the reclaim reduced the
- * current usage of the cgroup before giving up
+ * Even though the limit is exceeded at this point, reclaim
+ * may have been able to free some pages. Retry the charge
+ * before killing the task.
+ *
+ * Only for regular pages, though: huge pages are rather
+ * unlikely to succeed so close to the limit, and we fall back
+ * to regular pages anyway in case of failure.
*/
- if (ret || mem_cgroup_check_under_limit(mem_over_limit))
+ if (csize == PAGE_SIZE && ret)
return CHARGE_RETRY;
/*
_
Patches currently in -mm which might be from hannes@cmpxchg.org are
memcg-prevent-endless-loop-when-charging-huge-pages.patch
memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix.patch
memcg-prevent-endless-loop-when-charging-huge-pages-to-near-limit-group-fix-fix.patch
memcg-never-oom-when-charging-huge-pages.patch
memcg-fix-event-counting-breakage-by-recent-thp-update.patch
epoll-fix-compiler-warning-and-optimize-the-non-blocking-path-fix.patch
memcg-res_counter_read_u64-fix-potential-races-on-32-bit-machines.patch
memcg-fix-ugly-initialization-of-return-value-is-in-caller.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn-fix.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn-fix-fix.patch
^ permalink raw reply
* [folded] thp-fix-unsuitable-behavior-for-hwpoisoned-tail-page-fix.patch removed from -mm tree
From: akpm @ 2011-02-01 23:46 UTC (permalink / raw)
To: akpm, aarcange, andi, jin.dongming, seto.hidetoshi, mm-commits
The patch titled
thp-fix-unsuitable-behavior-for-hwpoisoned-tail-page-fix
has been removed from the -mm tree. Its filename was
thp-fix-unsuitable-behavior-for-hwpoisoned-tail-page-fix.patch
This patch was dropped because it was folded into thp-fix-unsuitable-behavior-for-hwpoisoned-tail-page.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: thp-fix-unsuitable-behavior-for-hwpoisoned-tail-page-fix
From: Andrew Morton <akpm@linux-foundation.org>
fix unrelated typo in shake_page() comment
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Cc: Jin Dongming <jin.dongming@np.css.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/memory-failure.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -puN mm/memory-failure.c~thp-fix-unsuitable-behavior-for-hwpoisoned-tail-page-fix mm/memory-failure.c
--- a/mm/memory-failure.c~thp-fix-unsuitable-behavior-for-hwpoisoned-tail-page-fix
+++ a/mm/memory-failure.c
@@ -233,8 +233,8 @@ void shake_page(struct page *p, int acce
}
/*
- * Only all shrink_slab here (which would also
- * shrink other caches) if access is not potentially fatal.
+ * Only call shrink_slab here (which would also shrink other caches) if
+ * access is not potentially fatal.
*/
if (access) {
int nr;
_
Patches currently in -mm which might be from akpm@linux-foundation.org are
epoll-epoll_wait-should-not-use-timespec_add_ns.patch
maintainers-fixup-simtec-support-email-entries.patch
thp-fix-splitting-of-hwpoisoned-hugepages.patch
thp-fix-the-wrong-reported-address-of-hwpoisoned-hugepages.patch
thp-fix-unsuitable-behavior-for-hwpoisoned-tail-page.patch
linux-next.patch
next-remove-localversion.patch
i-need-old-gcc.patch
arch-alpha-kernel-systblss-remove-debug-check.patch
mm-vmap-area-cache.patch
drivers-gpu-drm-radeon-atomc-fix-warning.patch
leds-convert-bd2802-driver-to-dev_pm_ops-fix.patch
leds-route-kbd-leds-through-the-generic-leds-layer.patch
backlight-add-backlight-type-fix.patch
backlight-add-backlight-type-fix-fix.patch
fs-ocfs2-dlm-dlmdomainc-avoid-a-gfp_atomic-allocation.patch
drivers-message-fusion-mptsasc-fix-warning.patch
drbd-fix-warning.patch
mm.patch
frv-duplicate-output_buffer-of-e03-checkpatch-fixes.patch
hpet-factor-timer-allocate-from-open.patch
arch-alpha-include-asm-ioh-s-extern-inline-static-inline.patch
epoll-fix-compiler-warning-and-optimize-the-non-blocking-path.patch
lib-hexdumpc-make-hex2bin-return-the-updated-src-address.patch
fs-binfmt_miscc-use-kernels-hex_to_bin-method-fix.patch
fs-binfmt_miscc-use-kernels-hex_to_bin-method-fix-fix.patch
exec_domain-establish-a-linux32-domain-on-config_compat-systems.patch
scatterlist-new-helper-functions.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn-fix.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn-fix-fix.patch
journal_add_journal_head-debug.patch
slab-leaks3-default-y.patch
put_bh-debug.patch
memblock-add-input-size-checking-to-memblock_find_region.patch
memblock-add-input-size-checking-to-memblock_find_region-fix.patch
^ permalink raw reply
* [folded] thp-fix-the-wrong-reported-address-of-hwpoisoned-hugepages-fix.patch removed from -mm tree
From: akpm @ 2011-02-01 23:46 UTC (permalink / raw)
To: akpm, aarcange, andi, jin.dongming, seto.hidetoshi, mm-commits
The patch titled
thp-fix-the-wrong-reported-address-of-hwpoisoned-hugepages-fix
has been removed from the -mm tree. Its filename was
thp-fix-the-wrong-reported-address-of-hwpoisoned-hugepages-fix.patch
This patch was dropped because it was folded into thp-fix-the-wrong-reported-address-of-hwpoisoned-hugepages.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: thp-fix-the-wrong-reported-address-of-hwpoisoned-hugepages-fix
From: Andrew Morton <akpm@linux-foundation.org>
fix spello in comment
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Cc: Jin Dongming <jin.dongming@np.css.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/huge_memory.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN mm/huge_memory.c~thp-fix-the-wrong-reported-address-of-hwpoisoned-hugepages-fix mm/huge_memory.c
--- a/mm/huge_memory.c~thp-fix-the-wrong-reported-address-of-hwpoisoned-hugepages-fix
+++ a/mm/huge_memory.c
@@ -1163,7 +1163,7 @@ static void __split_huge_page_refcount(s
smp_mb();
/*
- * remain hwpoison flag of the poisoned tail page:
+ * retain hwpoison flag of the poisoned tail page:
* fix for the unsuitable process killed on Guest Machine(KVM)
* by the memory-failure.
*/
_
Patches currently in -mm which might be from akpm@linux-foundation.org are
epoll-epoll_wait-should-not-use-timespec_add_ns.patch
maintainers-fixup-simtec-support-email-entries.patch
thp-fix-splitting-of-hwpoisoned-hugepages.patch
thp-fix-the-wrong-reported-address-of-hwpoisoned-hugepages.patch
thp-fix-unsuitable-behavior-for-hwpoisoned-tail-page-fix.patch
linux-next.patch
next-remove-localversion.patch
i-need-old-gcc.patch
arch-alpha-kernel-systblss-remove-debug-check.patch
mm-vmap-area-cache.patch
drivers-gpu-drm-radeon-atomc-fix-warning.patch
leds-convert-bd2802-driver-to-dev_pm_ops-fix.patch
leds-route-kbd-leds-through-the-generic-leds-layer.patch
backlight-add-backlight-type-fix.patch
backlight-add-backlight-type-fix-fix.patch
fs-ocfs2-dlm-dlmdomainc-avoid-a-gfp_atomic-allocation.patch
drivers-message-fusion-mptsasc-fix-warning.patch
drbd-fix-warning.patch
mm.patch
frv-duplicate-output_buffer-of-e03-checkpatch-fixes.patch
hpet-factor-timer-allocate-from-open.patch
arch-alpha-include-asm-ioh-s-extern-inline-static-inline.patch
epoll-fix-compiler-warning-and-optimize-the-non-blocking-path.patch
lib-hexdumpc-make-hex2bin-return-the-updated-src-address.patch
fs-binfmt_miscc-use-kernels-hex_to_bin-method-fix.patch
fs-binfmt_miscc-use-kernels-hex_to_bin-method-fix-fix.patch
exec_domain-establish-a-linux32-domain-on-config_compat-systems.patch
scatterlist-new-helper-functions.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn-fix.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn-fix-fix.patch
journal_add_journal_head-debug.patch
slab-leaks3-default-y.patch
put_bh-debug.patch
memblock-add-input-size-checking-to-memblock_find_region.patch
memblock-add-input-size-checking-to-memblock_find_region-fix.patch
^ permalink raw reply
* [folded] thp-fix-splitting-of-hwpoisoned-hugepages-checkpatch-fixes.patch removed from -mm tree
From: akpm @ 2011-02-01 23:45 UTC (permalink / raw)
To: akpm, aarcange, andi, jin.dongming, seto.hidetoshi, mm-commits
The patch titled
thp-fix-splitting-of-hwpoisoned-hugepages-checkpatch-fixes
has been removed from the -mm tree. Its filename was
thp-fix-splitting-of-hwpoisoned-hugepages-checkpatch-fixes.patch
This patch was dropped because it was folded into thp-fix-splitting-of-hwpoisoned-hugepages.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: thp-fix-splitting-of-hwpoisoned-hugepages-checkpatch-fixes
From: Andrew Morton <akpm@linux-foundation.org>
WARNING: line over 80 characters
#49: FILE: mm/memory-failure.c:900:
+ * PageAnon is just for avoid tripping a split_huge_page internal
WARNING: line over 80 characters
#54: FILE: mm/memory-failure.c:905:
+ * in the first place, having a refcount on the tail isn't enough
WARNING: line over 80 characters
#60: FILE: mm/memory-failure.c:911:
+ * FIXME: if splitting THP is failed, it is better
WARNING: line over 80 characters
#62: FILE: mm/memory-failure.c:913:
+ * causing panic by unmapping. System might survive
total: 0 errors, 4 warnings, 42 lines checked
./patches/thp-fix-splitting-of-hwpoisoned-hugepages.patch has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
Please run checkpatch prior to sending patches
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Cc: Jin Dongming <jin.dongming@np.css.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/memory-failure.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff -puN mm/memory-failure.c~thp-fix-splitting-of-hwpoisoned-hugepages-checkpatch-fixes mm/memory-failure.c
--- a/mm/memory-failure.c~thp-fix-splitting-of-hwpoisoned-hugepages-checkpatch-fixes
+++ a/mm/memory-failure.c
@@ -897,21 +897,21 @@ static int hwpoison_user_mappings(struct
if (PageTransHuge(hpage)) {
/*
* Verify that this isn't a hugetlbfs head page, the check for
- * PageAnon is just for avoid tripping a split_huge_page internal
- * debug check, as split_huge_page refuses to deal with anything
- * that isn't an anon page. PageAnon can't go away from under us
- * because we hold a refcount on the hpage, without a refcount
- * on the hpage. split_huge_page can't be safely called
- * in the first place, having a refcount on the tail isn't enough
- * to be safe.
+ * PageAnon is just for avoid tripping a split_huge_page
+ * internal debug check, as split_huge_page refuses to deal with
+ * anything that isn't an anon page. PageAnon can't go away fro
+ * under us because we hold a refcount on the hpage, without a
+ * refcount on the hpage. split_huge_page can't be safely called
+ * in the first place, having a refcount on the tail isn't
+ * enough * to be safe.
*/
if (!PageHuge(hpage) && PageAnon(hpage)) {
if (unlikely(split_huge_page(hpage))) {
/*
- * FIXME: if splitting THP is failed, it is better
- * to stop the following operation rather than
- * causing panic by unmapping. System might survive
- * if the page is freed later.
+ * FIXME: if splitting THP is failed, it is
+ * better to stop the following operation rather
+ * than causing panic by unmapping. System might
+ * survive if the page is freed later.
*/
printk(KERN_INFO
"MCE %#lx: failed to split THP\n", pfn);
_
Patches currently in -mm which might be from akpm@linux-foundation.org are
epoll-epoll_wait-should-not-use-timespec_add_ns.patch
maintainers-fixup-simtec-support-email-entries.patch
thp-fix-splitting-of-hwpoisoned-hugepages.patch
thp-fix-the-wrong-reported-address-of-hwpoisoned-hugepages-fix.patch
thp-fix-unsuitable-behavior-for-hwpoisoned-tail-page-fix.patch
linux-next.patch
next-remove-localversion.patch
i-need-old-gcc.patch
arch-alpha-kernel-systblss-remove-debug-check.patch
mm-vmap-area-cache.patch
drivers-gpu-drm-radeon-atomc-fix-warning.patch
leds-convert-bd2802-driver-to-dev_pm_ops-fix.patch
leds-route-kbd-leds-through-the-generic-leds-layer.patch
backlight-add-backlight-type-fix.patch
backlight-add-backlight-type-fix-fix.patch
fs-ocfs2-dlm-dlmdomainc-avoid-a-gfp_atomic-allocation.patch
drivers-message-fusion-mptsasc-fix-warning.patch
drbd-fix-warning.patch
mm.patch
frv-duplicate-output_buffer-of-e03-checkpatch-fixes.patch
hpet-factor-timer-allocate-from-open.patch
arch-alpha-include-asm-ioh-s-extern-inline-static-inline.patch
epoll-fix-compiler-warning-and-optimize-the-non-blocking-path.patch
lib-hexdumpc-make-hex2bin-return-the-updated-src-address.patch
fs-binfmt_miscc-use-kernels-hex_to_bin-method-fix.patch
fs-binfmt_miscc-use-kernels-hex_to_bin-method-fix-fix.patch
exec_domain-establish-a-linux32-domain-on-config_compat-systems.patch
scatterlist-new-helper-functions.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn-fix.patch
crash_dump-export-is_kdump_kernel-to-modules-consolidate-elfcorehdr_addr-setup_elfcorehdr-and-saved_max_pfn-fix-fix.patch
journal_add_journal_head-debug.patch
slab-leaks3-default-y.patch
put_bh-debug.patch
memblock-add-input-size-checking-to-memblock_find_region.patch
memblock-add-input-size-checking-to-memblock_find_region-fix.patch
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.