* Dom0 kernel panic when porting xen to new arm soc
@ 2015-06-18 14:09 Peng Fan
2015-06-18 14:24 ` Julien Grall
2015-06-18 14:54 ` Ian Campbell
0 siblings, 2 replies; 15+ messages in thread
From: Peng Fan @ 2015-06-18 14:09 UTC (permalink / raw)
To: xen-devel, van.freenix
Hi,
I am porting xen to an Cortex-A7 soc and met Dom0 kernel panic. I have
no clear idea about why Dom0 kernel panic.
Detail log see below:
U-Boot 2015.04-rc4-00145-gf12a16e (Jun 18 2015 - 10:38:06)
CPU: Freescale i.MX7D rev1.0 at 792 MHz
CPU: Thermal invalid data, fuse: 0x1b800
CPU: Temperature: Can't find sensor device
Reset cause: POR
Board: MX7D 12x12 LPDDR3 ARM2
I2C: ready
DRAM: 2 GiB
PMIC: PFUZE300 DEV_ID=0x30 REV_ID=0x10
MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
Display: MCIMX28LCD (800x480)
Video: 800x480x24
In: serial
Out: serial
Err: serial
switch to partitions #0, OK
mmc0 is current device
Net: FEC0
Error: FEC0 address not set.
Normal Boot
Hit any key to stop autoboot: 0
=> setenv xen_addr_r 0x80000000
=> setenv bootargs "console=dtuart
dtuart=/soc/aips-bus@30800000/serial@30860000 dom0_mem=128M"
=> fatload mmc 0:1 0x80000000 xen.image
reading xen.image
754544 bytes read in 129 ms (5.6 MiB/s)
=> fatload mmc 0:1 0x83000000 imx7d-12x12-arm2.dtb
reading imx7d-12x12-arm2.dtb
37498 bytes read in 21 ms (1.7 MiB/s)
=> fatload mmc 0:1 0x84000000 zImage
reading zImage
9307256 bytes read in 420 ms (21.1 MiB/s)
=> setenv kernel_addr_r 0x84000000
=> setenv fdt_high 0xffffffff
=> setenv fdt_addr 0x83000000
=> fdt addr ${fdt_addr} 0x40000
=> fdt resize
=> fdt chosen
=> fdt set /chosen \#address-cells <1>
=> fdt set /chosen \#size-cells <1>
=> fdt mknod /chosen module@0
=> fdt set /chosen/module@0 compatible "xen,linux-zimage"
"xen,multiboot-module"
=> fdt set /chosen/module@0 reg <${kernel_addr_r} 0x${filesize}>
=> fdt set /chosen/module@0 bootargs "console=hvc0 ro
root=/dev/mmcblk0p2 clk_ignore_unused uart_from_osc"
=> bootz ${xen_addr_r} - ${fdt_addr}
Kernel image @ 0x80000000 [ 0x000000 - 0x101700 ]
## Flattened Device Tree blob at 83000000
Booting using the fdt blob at 0x83000000
reserving fdt memory region: addr=83000000 size=a000
Using Device Tree in place at 83000000, end 8300cfff
Starting kernel ...
Xen 4.6-unstable
(XEN) Xen version 4.6-unstable (Freenix@(none))
(arm-poky-linux-gnueabi-gcc (GCC) 4.8.2) debug=y Thu Jun 18 12:32:18 CST
2015
(XEN) Latest ChangeSet: Mon Jun 15 18:25:34 2015 +0800 git:c01e139-dirty
(XEN) Processor: 410fc075: "ARM Limited", variant: 0x0, part 0xc07, rev 0x5
(XEN) 32-bit Execution:
(XEN) Processor Features: 00001131:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle
(XEN) Extensions: GenericTimer Security
(XEN) Debug Features: 02010555
(XEN) Auxiliary Features: 00000000
(XEN) Memory Model Features: 10101105 40000000 01240000 02102211
(XEN) ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000
(XEN) Set Secondary entry to 00000000ffe0004c (0020004c)
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 8000 KHz
(XEN) GICv2 initialization:
(XEN) gic_dist_addr=0000000031001000
(XEN) gic_cpu_addr=0000000031002000
(XEN) gic_hyp_addr=0000000031004000
(XEN) gic_vcpu_addr=0000000031006000
(XEN) gic_maintenance_irq=25
(XEN) GICv2: 160 lines, 2 cpus, secure (IID 0100143b).
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) imx-uart.c:117: imx_uart_init_postirq
(XEN) Allocated console ring of 16 KiB.
(XEN) VFP implementer 0x41 architecture 2 part 0x30 variant 0x7 rev 0x5
(XEN) Brought up 1 CPUs
(XEN) P2M: 40-bit IPA
(XEN) P2M: 3 levels with order-1 root, VTCR 0x80003558
(XEN) I/O virtualisation disabled
(XEN) *** LOADING DOMAIN 0 ***
(XEN) domain_build.c:1383: idle loop
(XEN) Loading kernel from boot module @ 0000000084000000
(XEN) Allocating 1:1 mappings totalling 128MB for dom0:
(XEN) BANK[0] 0x00000088000000-0x00000090000000 (128MB)
(XEN) Loading zImage from 0000000084000000 to
000000008f600000-000000008fee0478
(XEN) Allocating PPI 16 for event channel interrupt
(XEN) Loading dom0 DTB to 0x000000008f400000-0x000000008f409239
(XEN) regs -> pc = 0x8f600000
(XEN) it is 32 bit machine
(XEN) Scrubbing Free RAM on 1 nodes using 1 CPUs
(XEN) ................done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 284kB init memory.
Booting Linux on physical CPU 0x0
Linux version 3.14.28-01780-g281e5c1-dirty (Freenix@linux-vaa1) (gcc
version 4.8.2 (GCC) ) #269 SMP PREEMPT Thu Jun 18 17:30:11 CST 2015
CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine model: Freescale i.MX7 LPDDR3 12x12 ARM2 Board
cma: CMA: failed to reserve 320 MiB
Memory policy: Data cache writealloc
psci: probing function IDs from device-tree
PERCPU: Embedded 8 pages/cpu @87ee1000 s9600 r8192 d14976 u32768
Built 1 zonelists in Zone order, mobility grouping off. Total pages: 32512
Kernel command line: console=hvc0 ro root=/dev/mmcblk0p2
clk_ignore_unused uart_from_osc
PID hash table entries: 512 (order: -1, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 109376K/131072K available (7475K kernel code, 444K rwdata, 8628K
rodata, 3401K init, 442K bss, 21696K reserved, 0K highmem)
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
vmalloc : 0x88800000 - 0xff000000 (1896 MB)
lowmem : 0x80000000 - 0x88000000 ( 128 MB)
pkmap : 0x7fe00000 - 0x80000000 ( 2 MB)
modules : 0x7f000000 - 0x7fe00000 ( 14 MB)
.text : 0x80008000 - 0x80fc1ec0 (16104 kB)
.init : 0x80fc2000 - 0x81314580 (3402 kB)
.data : 0x81316000 - 0x813852c0 ( 445 kB)
.bss : 0x813852cc - 0x813f3cdc ( 443 kB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Preemptible hierarchical RCU implementation.
RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=1.
RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
NR_IRQS:16 nr_irqs:16 16
Switching to timer-based delay loop
sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every
1431655765682ns
Architected cp15 timer(s) running at 8.00MHz (virt).
sched_clock: 56 bits at 8MHz, resolution 125ns, wraps every 2147483648000ns
Ignoring duplicate/late registration of read_current_timer delay
Console: colour dummy device 80x30
Calibrating delay loop (skipped), value calculated using timer
frequency.. 6.00 BogoMIPS (lpj=30000)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
CPU: Testing write buffer coherency: ok
/cpus/cpu@0 missing clock-frequency property
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
Xen 4.6 support found, events_irq=16 gnttab_frame=0x00900000
xen:grant_table: Grant tables using version 1 layout
Grant table initialized
xen:events: Using FIFO-based ABI
Xen: initializing cpu0
Setting up static identity map for 0x8871c200 - 0x8871c258
Brought up 1 CPUs
SMP: Total of 1 processors activated.
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev 5
pinctrl core: initialized pinctrl subsystem
regulator-dummy: no parameters
NET: Registered protocol family 16
DMA: failed to allocate 256 KiB pool for atomic coherent allocation
xen:swiotlb_xen: Warning: only able to allocate 32 MB for software IO TLB
software IO TLB [mem 0x8a000000-0x8c000000] (32MB) mapped at
[82000000-83ffffff]
Use WDOG1 as reset source
syscon 30340000.iomuxc-gpr: regmap [mem 0x30340000-0x3034ffff] registered
syscon 30360000.anatop: regmap [mem 0x30360000-0x3036ffff] registered
vdd1p0d: 800 <--> 1200 mV at 1000 mV
syscon 30390000.src: regmap [mem 0x30390000-0x3039ffff] registered
failed to find ocotp node
failed to find ocotp node
hw-breakpoint: Failed to enable monitor mode on CPU 0.
imx7d-pinctrl 302c0000.iomuxc-lpsr: initialized IMX pinctrl driver
imx7d-pinctrl 30330000.iomuxc: initialized IMX pinctrl driver
bio: create slab <bio-0> at 0
xen:balloon: Initialising balloon driver
xen_balloon: Initialising balloon driver
VCC_SD1: 3000 mV
VCC_SD2: 3000 mV
CODEC_5V: 5000 mV
AUD_1V8: 1800 mV
usb_otg1_vbus: 5000 mV
usb_otg2_vbus: 5000 mV
can1-3v3: 3300 mV
can2-3v3: 3300 mV
i2c-core: driver [max17135] using legacy suspend method
i2c-core: driver [max17135] using legacy resume method
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
usbphy_nop1.5 supply vcc not found, using dummy regulator
usbphy_nop2.6 supply vcc not found, using dummy regulator
usbphy_nop3.7 supply vcc not found, using dummy regulator
i2c i2c-0: IMX I2C adapter registered
2-0048 supply SENSOR not found, using dummy regulator
i2c i2c-2: Max17135 PMIC not found!
i2c i2c-2: IMX I2C adapter registered
Linux video capture interface: v2.00
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti
<giometti@linux.it>
PTP clock support registered
MIPI CSI2 driver module loaded
Advanced Linux Sound Architecture Driver Initialized.
Bluetooth: Core ver 2.18
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP socket layer initialized
Bluetooth: SCO socket layer initialized
Switched to clocksource arch_sys_counter
cfg80211: Calling CRDA to update world regulatory domain
NET: Registered protocol family 2
TCP established hash table entries: 1024 (order: 0, 4096 bytes)
TCP bind hash table entries: 1024 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
TCP: reno registered
UDP hash table entries: 256 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Bus freq driver module loaded
futex hash table entries: 256 (order: 2, 16384 bytes)
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
NFS: Registering the id_resolver key type
Key type id_resolver registered
Key type id_legacy registered
jffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
fuse init (API version 7.22)
msgmni has been set to 213
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
backlight.8 supply power not found, using dummy regulator
MIPI DSI driver module loaded
imx-sdma 30bd0000.sdma: no iram assigned, using external mem
imx-sdma 30bd0000.sdma: initialisation failed with -12
imx-sdma: probe of 30bd0000.sdma failed with error -12
xen:xen_evtchn: Event-channel device installed
pfuze100-regulator 0-0008: Full layer: 1, Metal layer: 0
pfuze100-regulator 0-0008: FAB: 0, FIN: 0
pfuze100-regulator 0-0008: pfuze3000 found.
SW1A: 700 <--> 1475 mV at 1100 mV
SW1B: 700 <--> 1475 mV at 1000 mV
SW2: 1500 <--> 1850 mV at 1800 mV
SW3: 900 <--> 1650 mV at 1200 mV
SWBST: 5000 <--> 5150 mV at 5000 mV
VSNVS: 1000 <--> 3000 mV at 3000 mV
VREFDDR: 750 mV
VLDO1: 1800 <--> 3300 mV at 1800 mV
VLDO2: 800 <--> 1550 mV at 1500 mV
VCCSD: 2850 <--> 3300 mV at 3300 mV
V33: 2850 <--> 3300 mV at 3300 mV
VLDO3: 1800 <--> 3300 mV at 3300 mV
VLDO4: 1800 <--> 3300 mV at 2800 mV
console [hvc0] enabled
Serial: IMX driver
30880000.serial: ttymxc2 at MMIO 0x30880000 (irq = 60, base_baud =
5000000) is a IMX
serial: Freescale lpuart driver
imx sema4 driver is registered.
[drm] Initialized drm 1.1.0 20060810
[drm] Initialized vivante 1.0.0 20120216 on minor 0
brd: module loaded
loop: module loaded
2-001a supply DCVDD not found, using dummy regulator
2-001a supply AVDD1 not found, using dummy regulator
wm8994 2-001a: WM8958 revision B CUST_ID 00
wm8994 2-001a: No interrupt specified, no interrupts
spi_imx 30840000.ecspi: cannot get the TX DMA channel!
spi_imx 30840000.ecspi: dma setup error,use pio instead
m25p80 spi2.0: found mr25h256, expected m25p32
m25p80 spi2.0: mr25h256 (32 Kbytes)
spi_imx 30840000.ecspi: probed
CAN device driver interface
30be0000.ethernet supply phy not found, using dummy regulator
pps pps0: new PPS source ptp0
fec: probe of 30be0000.ethernet failed with error -12
xen_netfront: Initialising Xen virtual ethernet driver
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-mxc: Freescale On-Chip EHCI Host driver
usbcore: registered new interface driver usb-storage
30b10200.usbmisc supply vbus-wakeup not found, using dummy regulator
30b20200.usbmisc supply vbus-wakeup not found, using dummy regulator
30b30200.usbmisc supply vbus-wakeup not found, using dummy regulator
ci_hdrc ci_hdrc.0: doesn't support gadget
ci_hdrc ci_hdrc.1: doesn't support gadget
mousedev: PS/2 mouse device common for all mice
input: 30370000.snvs-pwrkey as
/devices/soc.2/30000000.aips-bus/30370000.snvs-pwrkey/input/input0
snvs_pwrkey 30370000.snvs-pwrkey: i.MX snvs powerkey probed
i2c-core: driver [isl29023] using legacy suspend method
i2c-core: driver [isl29023] using legacy resume method
snvs_rtc 30370034.snvs-rtc-lp: rtc core: registered 30370034.snvs-rtc-l
as rtc0
i2c /dev entries driver
IR NEC protocol handler initialized
IR RC5(x) protocol handler initialized
IR RC6 protocol handler initialized
IR JVC protocol handler initialized
IR Sony protocol handler initialized
IR RC5 (streamzap) protocol handler initialized
IR SANYO protocol handler initialized
IR MCE Keyboard/mouse protocol handler initialized
pxp-v4l2 pxp_v4l2_out.10: initialized
i2c-core: driver [mag3110] using legacy suspend method
i2c-core: driver [mag3110] using legacy resume method
Bluetooth: HCI UART driver ver 2.2
Bluetooth: HCI H4 protocol initialized
Bluetooth: HCI BCSP protocol initialized
Bluetooth: HCIATH3K protocol initialized
usbcore: registered new interface driver bcm203x
usbcore: registered new interface driver btusb
Bluetooth: Generic Bluetooth SDIO driver ver 0.1
usbcore: registered new interface driver ath3k
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
mmc0: no vqmmc regulator found
mmc0: SDHCI controller on 30b40000.usdhc [30b40000.usdhc] using ADMA
mmc1: no vqmmc regulator found
mmc1: SDHCI controller on 30b50000.usdhc [30b50000.usdhc] using ADMA
mmc2: no vqmmc regulator found
mmc2: no vmmc regulator found
mmc0: new high speed SDHC card at address f1f9
mmcblk0: mmc0:f1f9 SE08G 7.28 GiB
mmcblk0: p1 p2
mmc2: SDHCI controller on 30b60000.usdhc [30b60000.usdhc] using ADMA
Job Ring Device allocation for transform failed
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
NET: Registered protocol family 26
TCP: cubic registered
NET: Registered protocol family 10
sit: IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
can: controller area network core (rev 20120528 abi 9)
NET: Registered protocol family 29
can: raw protocol (rev 20120528)
can: broadcast manager protocol (rev 20120528 t)
can: netlink gateway (rev 20130117) max_hops=1
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM ver 1.11
Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Bluetooth: BNEP filters: protocol multicast
Bluetooth: BNEP socket layer initialized
Bluetooth: HIDP (Human Interface Emulation) ver 1.2
Bluetooth: HIDP socket layer initialized
8021q: 802.1Q VLAN Support v1.8
Key type dns_resolver registered
mmc2: BKOPS_EN bit is not set
imx_epdc_v2_fb: probe of 306f0000.epdc failed with error -12
VLDO2: disabling
SWBST: disabling
can2-3v3: disabling
can1-3v3: disabling
usb_otg2_vbus: disabling
usb_otg1_vbus: disabling
VCC_SD2: disabling
regulator-dummy: disabling
imx mcc test is registered.
input: gpio-keys.9 as /devices/gpio-keys.9/input/input1
snvs_rtc 30370034.snvs-rtc-lp: setting system clock to 1970-01-01
00:00:00 UTC (0)
clk: Not disabling unused clocks
ALSA device list:
No soundcards found.
Freeing unused kernel memory: 3400K (80fc2000 - 81314000)
init started: BusyBox v1.15.0 ()
mmc2: new HS400 DDR MMC card at address 0001
starting pid 87, tty '': '/etc/rc.d/rcS'
mmcblk2: mmc2:0001 R1J55A 7.28 GiB
mmcblk2boot0: mmc2:0001 R1J55A partition 1 2.00 MiB
BusyBox v1.15.0 () built-in shell (ash)
Enter 'help' for a list of built-in commands.mmcblk2boot1: mmc2:0001
R1J55A partition 2 2.00 MiB
mmcblk2rpmb: mmc2:0001 R1J55A partition 3 128 KiB
/bin/sh: can't access tty; job control turned off
/ # mmcblk2: p1 p2
mmcblk2boot1: unknown partition table
mmcblk2boot0: unknown partition table
(XEN) imx-uart.c:72: uart: rxfifo overrun
/ #
/ #
/ #
/ #
/ # Unable to handle kernel NULL pointer dereference at virtual address
00000000
pgd = 84f1c000
[00000000] *pgd=8cf15831, *pte=00000000, *ppte=00000000
Internal error: Oops: 80000007 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 89 Comm: sh Not tainted 3.14.28-01780-g281e5c1-dirty #269
task: 84c07a80 ti: 84f02000 task.ti: 84f02000
PC is at 0x0
LR is at call_timer_fn.isra.33+0x24/0x88
pc : [<00000000>] lr : [<80038b38>] psr: 20000113
sp : 84f03d70 ip : 84f03d98 fp : 00000000
r10: 00000000 r9 : 81388d14 r8 : 00000000
r7 : 84f02030 r6 : 00000101 r5 : 84f02000 r4 : 81388500
r3 : 84f03d70 r2 : 00000101 r1 : 00000000 r0 : 00000000
Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 10c53c7d Table: 8cf1c06a DAC: 00000015
Process sh (pid: 89, stack limit = 0x84f02238)
Stack: (0x84f03d70 to 0x84f04000)
3d60: 00000002 87ee13c0 81388500 84f03d98
3d80: 00200200 00000000 813180c0 80038d28 81388f14 81389114 84f03d98
84f03d98
3da0: 845499cc 00000080 81318084 00000101 84f02000 81318080 81318080
00000001
3dc0: 40000001 80032cc0 845499cc 00000002 845499cc 81312458 00000000
0000000a
3de0: 813882c0 813180c0 ffff8f0a 84f02008 8071e418 00404000 802ab76c
84f02020
3e00: 0000001b 00000000 88802000 00000004 84c088e0 20000013 80740b78
80033084
3e20: 81312e54 8000f54c 8880200c 8131e978 84f03e50 80008598 8032c18c
8071b954
3e40: 60000013 ffffffff 84f03e84 800129c0 84c088e0 20000013 00000000
0000002e
3e60: 84c08800 00000004 00000000 84d46804 00000004 84c088e0 20000013
80740b78
3e80: deadbeef 84f03e98 8032c18c 8071b954 60000013 ffffffff 00000004
8032c18c
3ea0: 84d4cc00 00000004 0000224c 00002250 88863270 88861000 84d46800
803168c4
3ec0: 00000000 842abf00 84d4cc80 84f02000 84d46800 84f02000 84f02000
84d4cd78
3ee0: 76fc0000 00000000 84c07a80 8005475c 84d4cd7c 84d4cd7c 84b67c40
76fc0000
3f00: 00000004 84d4cc00 00000000 842abf00 00000004 84f02000 84f02000
80313990
3f20: 81318280 00000004 80316704 84d50c80 00000012 842abf00 76fc0000
84f03f80
3f40: 00000004 00000004 76fc0000 00000000 00000001 800d5e38 000000c0
84f03f70
3f60: 84f2a000 00000000 00000000 842abf00 842abf00 00000004 76fc0000
800d641c
3f80: 00000000 00000000 000000c0 00000004 76fc0000 76f9d5f8 00000004
8000ede4
3fa0: 84f02000 8000ec60 00000004 76fc0000 00000001 76fc0000 00000004
00000000
3fc0: 00000004 76fc0000 76f9d5f8 00000004 00000004 00000000 76f9d000
00000001
3fe0: 00000004 7ed29688 76eeb98c 76f37e6c 60000010 00000001 6caaaac3
6caaaac3
[<80038b38>] (call_timer_fn.isra.33) from [<80038d28>]
(run_timer_softirq+0x18c/0x208)
[<80038d28>] (run_timer_softirq) from [<80032cc0>]
(__do_softirq+0x10c/0x248)
[<80032cc0>] (__do_softirq) from [<80033084>] (irq_exit+0xb8/0xf4)
[<80033084>] (irq_exit) from [<8000f54c>] (handle_IRQ+0x44/0x90)
[<8000f54c>] (handle_IRQ) from [<80008598>] (gic_handle_irq+0x2c/0x5c)
[<80008598>] (gic_handle_irq) from [<800129c0>] (__irq_svc+0x40/0x70)
Exception stack(0x84f03e50 to 0x84f03e98)
3e40: 84c088e0 20000013 00000000 0000002e
3e60: 84c08800 00000004 00000000 84d46804 00000004 84c088e0 20000013
80740b78
3e80: deadbeef 84f03e98 8032c18c 8071b954 60000013 ffffffff
[<800129c0>] (__irq_svc) from [<8071b954>]
(_raw_spin_unlock_irqrestore+0x20/0x54)
[<8071b954>] (_raw_spin_unlock_irqrestore) from [<8032c18c>]
(hvc_write+0xd0/0x11c)
[<8032c18c>] (hvc_write) from [<803168c4>] (n_tty_write+0x1c0/0x508)
[<803168c4>] (n_tty_write) from [<80313990>] (tty_write+0xfc/0x25c)
[<80313990>] (tty_write) from [<800d5e38>] (vfs_write+0xac/0x188)
[<800d5e38>] (vfs_write) from [<800d641c>] (SyS_write+0x40/0x94)
[<800d641c>] (SyS_write) from [<8000ec60>] (ret_fast_syscall+0x0/0x30)
Code: bad PC value
---[ end trace ee05d7cd4a4b340e ]---
Kernel panic - not syncing: Fatal exception in interrupt
I am not sure whether this realted to timer, the timer dts:
"
timer {
compatible = "arm,armv7-timer";
interrupts = <GIC_PPI 13
(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
<GIC_PPI 14
(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
<GIC_PPI 11
(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
<GIC_PPI 10
(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
interrupt-parent = <&intc>;
clock-frequency = <8000000>;
};
"
The Dom0 kernel is also configured with " CONFIG_ARM_ARCH_TIMER=y", will
this incur errors? Or should Dom0 kernel not use arm arch timer?
Thanks,
Peng.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Dom0 kernel panic when porting xen to new arm soc
2015-06-18 14:09 Dom0 kernel panic when porting xen to new arm soc Peng Fan
@ 2015-06-18 14:24 ` Julien Grall
2015-06-18 14:54 ` Ian Campbell
1 sibling, 0 replies; 15+ messages in thread
From: Julien Grall @ 2015-06-18 14:24 UTC (permalink / raw)
To: Peng Fan, xen-devel
On 18/06/15 15:09, Peng Fan wrote:
> Hi,
Hi,
> /bin/sh: can't access tty; job control turned off
> / # mmcblk2: p1 p2
> mmcblk2boot1: unknown partition table
> mmcblk2boot0: unknown partition table
> (XEN) imx-uart.c:72: uart: rxfifo overrun
It seems that you ported a new UART driver. My feeling is the error in
DOM0 is related to this message.
> The Dom0 kernel is also configured with " CONFIG_ARM_ARCH_TIMER=y", will
> this incur errors? Or should Dom0 kernel not use arm arch timer?
DOM0 should use the generic timer too.
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Dom0 kernel panic when porting xen to new arm soc
2015-06-18 14:09 Dom0 kernel panic when porting xen to new arm soc Peng Fan
2015-06-18 14:24 ` Julien Grall
@ 2015-06-18 14:54 ` Ian Campbell
2015-06-19 13:22 ` Peng Fan
1 sibling, 1 reply; 15+ messages in thread
From: Ian Campbell @ 2015-06-18 14:54 UTC (permalink / raw)
To: Peng Fan; +Cc: xen-devel
On Thu, 2015-06-18 at 22:09 +0800, Peng Fan wrote:
> Hi,
>
> I am porting xen to an Cortex-A7 soc and met Dom0 kernel panic. I have
> no clear idea about why Dom0 kernel panic.
Have you confirmed that this same kernel runs reliably natively on this
platform?
[...]
> / # Unable to handle kernel NULL pointer dereference at virtual address
> 00000000
> pgd = 84f1c000
> [00000000] *pgd=8cf15831, *pte=00000000, *ppte=00000000
> Internal error: Oops: 80000007 [#1] PREEMPT SMP ARM
> Modules linked in:
> CPU: 0 PID: 89 Comm: sh Not tainted 3.14.28-01780-g281e5c1-dirty #269
> task: 84c07a80 ti: 84f02000 task.ti: 84f02000
> PC is at 0x0
> LR is at call_timer_fn.isra.33+0x24/0x88
> pc : [<00000000>] lr : [<80038b38>] psr: 20000113
Your kernel has jumped to address 0x0 for some reason. You should use
gdb or something to examine you vmlinux file and try and figure out what
LR is doing, which may give you a hint as to why it is apparently
jumping to address zero.
> (XEN) Latest ChangeSet: Mon Jun 15 18:25:34 2015 +0800 git:c01e139-dirty
What changes have you made to your version of Xen? c01e139 is not an
upstream commit.
> I am not sure whether this realted to timer, the timer dts:
I think it looks like a software timer thing in the kernel rather than a
h/w timer thing.
> The Dom0 kernel is also configured with " CONFIG_ARM_ARCH_TIMER=y", will
> this incur errors? Or should Dom0 kernel not use arm arch timer?
Guests on Xen (including dom0) _should_ be using the arch timer.
Ian.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Dom0 kernel panic when porting xen to new arm soc
2015-06-18 14:54 ` Ian Campbell
@ 2015-06-19 13:22 ` Peng Fan
2015-06-20 10:19 ` Julien Grall
0 siblings, 1 reply; 15+ messages in thread
From: Peng Fan @ 2015-06-19 13:22 UTC (permalink / raw)
To: Ian Campbell; +Cc: julien.grall, xen-devel
Hi,
On 6/18/2015 10:54 PM, Ian Campbell wrote:
> On Thu, 2015-06-18 at 22:09 +0800, Peng Fan wrote:
>> Hi,
>>
>> I am porting xen to an Cortex-A7 soc and met Dom0 kernel panic. I have
>> no clear idea about why Dom0 kernel panic.
> Have you confirmed that this same kernel runs reliably natively on this
> platform?
Yeah. With XEN related configuration, the kernel can run natively on the
platform.
>
>
> [...]
>> / # Unable to handle kernel NULL pointer dereference at virtual address
>> 00000000
>> pgd = 84f1c000
>> [00000000] *pgd=8cf15831, *pte=00000000, *ppte=00000000
>> Internal error: Oops: 80000007 [#1] PREEMPT SMP ARM
>> Modules linked in:
>> CPU: 0 PID: 89 Comm: sh Not tainted 3.14.28-01780-g281e5c1-dirty #269
>> task: 84c07a80 ti: 84f02000 task.ti: 84f02000
>> PC is at 0x0
>> LR is at call_timer_fn.isra.33+0x24/0x88
>> pc : [<00000000>] lr : [<80038b38>] psr: 20000113
> Your kernel has jumped to address 0x0 for some reason. You should use
> gdb or something to examine you vmlinux file and try and figure out what
> LR is doing, which may give you a hint as to why it is apparently
> jumping to address zero.
I add such piece of code the linux kernel version 3.14.38. The panic
disappears.
diff --git a/kernel/timer.c b/kernel/timer.c
index 38f0d40..4a025cc 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -1175,6 +1175,10 @@ static inline void __run_timers(struct tvec_base
*base)
base->running_timer = timer;
detach_expired_timer(timer, base);
+ if (!fn) {
+ printk("fn is null why????\n"); ---->
This log only shows once. Not sure why fn is null and only once.
+ continue;
+ }
if (irqsafe) {
spin_unlock(&base->lock);
>
>> (XEN) Latest ChangeSet: Mon Jun 15 18:25:34 2015 +0800 git:c01e139-dirty
> What changes have you made to your version of Xen? c01e139 is not an
> upstream commit.
I only add an uart driver and a platform file. The platform part is very
simple:
PLATFORM_START(imx7d, "i.MX 7Dual")
.compatible = imx7d_dt_compat,
.smp_init = imx7d_smp_init, --> Actually I disabled this, since in
dts, only one cpu node enabled.
.cpu_up = cpu_up_send_sgi,
/* Use IRAM base, not sure */
#if 0
.dom0_gnttab_start = 0x00900000,
.dom0_gnttab_size = 0x20000,
#endif
PLATFORM_END
>> I am not sure whether this realted to timer, the timer dts:
> I think it looks like a software timer thing in the kernel rather than a
> h/w timer thing.
>
>> The Dom0 kernel is also configured with " CONFIG_ARM_ARCH_TIMER=y", will
>> this incur errors? Or should Dom0 kernel not use arm arch timer?
> Guests on Xen (including dom0) _should_ be using the arch timer.
>
> Ian.
>
Not sure whether it relates to the uart driver that Julien suspected.
But after apply the above kernel patch, Dom0 Linux can handle shell input.
Just have another question, How can Dom0 handle DMA for arm.
Thanks,
Peng.
^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: Dom0 kernel panic when porting xen to new arm soc
2015-06-19 13:22 ` Peng Fan
@ 2015-06-20 10:19 ` Julien Grall
2015-06-20 14:08 ` Peng Fan
0 siblings, 1 reply; 15+ messages in thread
From: Julien Grall @ 2015-06-20 10:19 UTC (permalink / raw)
To: Peng Fan, Ian Campbell; +Cc: julien.grall, xen-devel
Hi,
On 19/06/2015 14:22, Peng Fan wrote:
> diff --git a/kernel/timer.c b/kernel/timer.c
> index 38f0d40..4a025cc 100644
> --- a/kernel/timer.c
> +++ b/kernel/timer.c
> @@ -1175,6 +1175,10 @@ static inline void __run_timers(struct tvec_base
> *base)
>
> base->running_timer = timer;
> detach_expired_timer(timer, base);
> + if (!fn) {
> + printk("fn is null why????\n"); ---->
> This log only shows once. Not sure why fn is null and only once.
> + continue;
> + }
>
> if (irqsafe) {
> spin_unlock(&base->lock);
By any chance, does your board has a another timer (i.e other than the
generic timer)?
I would also track down to see who is adding this timer.
> But after apply the above kernel patch, Dom0 Linux can handle shell input.
> Just have another question, How can Dom0 handle DMA for arm.
When Xen is allocating the RAM bank for DOM0 we use a direct mapping
(i.e the Physical Address = Intermediate Address for the RAM). So DOM0
can perform DMA as on baremetal.
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Dom0 kernel panic when porting xen to new arm soc
2015-06-20 10:19 ` Julien Grall
@ 2015-06-20 14:08 ` Peng Fan
2015-06-20 14:47 ` Peng Fan
0 siblings, 1 reply; 15+ messages in thread
From: Peng Fan @ 2015-06-20 14:08 UTC (permalink / raw)
To: Julien Grall, Ian Campbell; +Cc: julien.grall, xen-devel
Hi Julien,
On 6/20/2015 6:19 PM, Julien Grall wrote:
> Hi,
>
> On 19/06/2015 14:22, Peng Fan wrote:
>> diff --git a/kernel/timer.c b/kernel/timer.c
>> index 38f0d40..4a025cc 100644
>> --- a/kernel/timer.c
>> +++ b/kernel/timer.c
>> @@ -1175,6 +1175,10 @@ static inline void __run_timers(struct tvec_base
>> *base)
>>
>> base->running_timer = timer;
>> detach_expired_timer(timer, base);
>> + if (!fn) {
>> + printk("fn is null why????\n"); ---->
>> This log only shows once. Not sure why fn is null and only once.
>> + continue;
>> + }
>>
>> if (irqsafe) {
>> spin_unlock(&base->lock);
>
> By any chance, does your board has a another timer (i.e other than the
> generic timer)?
Yeah. There is a another timer whose rating is lower that generic timer.
>
> I would also track down to see who is adding this timer.
>
>> But after apply the above kernel patch, Dom0 Linux can handle shell
>> input.
>> Just have another question, How can Dom0 handle DMA for arm.
>
> When Xen is allocating the RAM bank for DOM0 we use a direct mapping
> (i.e the Physical Address = Intermediate Address for the RAM). So DOM0
> can perform DMA as on baremetal.
Thanks. Current, without using rootfs in sd card, my Dom0 kernel can
boot using ramfs. But if with sdhc which use ADMA, Dom0 kernel will
panic. Below is the log:
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = 80004000
[00000000] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.38-02383-g5ccf32b-dirty #22
task: 84074000 ti: 84078000 task.ti: 84078000
PC is at bitmap_clear+0xc0/0xdc
LR is at bitmap_clear+0x54/0xdc
pc : [<8029deb8>] lr : [<8029de4c>] psr: 20000193
sp : 84079d80 ip : 00000001 fp : 00000000
r10: 00077fff r9 : 00000404 r8 : 00000001
r7 : 00000001 r6 : 00000001 r5 : 00000000 r4 : ffffffff
r3 : 00000001 r2 : 00000001 r1 : 20000193 r0 : 00000015
Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c53c7d Table: 8800406a DAC: 00000015
Process swapper/0 (pid: 1, stack limit = 0x84078238)
Stack: (0x84079d80 to 0x8407a000)
9d80: 80000113 00000000 87efa000 81109918 00001000 800197f8 84128558
00080008
9da0: 84079dec 000000d0 84bfeac0 84126c10 84126c10 ffffffff 00000404
ffffffff
9dc0: 00000000 00000402 00000000 00000000 84126c10 80310ba8 ffffffff
00000000
9de0: 00000000 00000524 84078000 00000000 00000000 ffffffff ffffffff
84bfeac0
9e00: 84bfe800 8000b407 07eb0000 8116e0f8 00000000 804ee81c ffffffff
ffffffff
9e20: 00000000 84126c10 84c92010 84bfeac0 00000000 84126c10 84126c00
84bfeac0
9e40: 84078030 804f08e4 804f03d8 84126c10 fffffdfb 8115401c 8115401c
00000000
9e60: 0000010f 80362330 803622ec 84126c10 811c8098 00000000 8115401c
80360b1c
9e80: 84126c10 8115401c 84126c44 00000000 80de1888 80360d28 00000000
8115401c
9ea0: 80360c9c 8035f10c 8406965c 84123634 8115401c 84c8bf80 8112f3c8
803602bc
9ec0: 80d08314 8115401c 00000006 8115401c 00000006 8116e080 8116e080
8036130c
9ee0: 00000000 80e00f78 00000006 800088dc 8400f900 80c94fe0 840bd480
80735184
9f00: 00000000 8116e080 0000150c 8012d430 00000000 811105b0 60000113
00000001
9f20: 87ffc576 8075ca38 0000010f 8004b0f0 80d66884 00000006 87ffc583
00000006
9f40: 811105a0 80e00f78 00000006 8116e080 8116e080 80da150c 0000010f
80df4154
9f60: 80df4148 80da1c4c 00000006 00000006 80da150c 9355553c 84079f9c
80731338
9f80: 00000000 00000000 80727254 00000000 00000000 00000000 00000000
00000000
9fa0: 00000000 8072725c 00000000 8000ecf8 00000000 00000000 00000000
00000000
9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 9355553c
9355553c
[<8029deb8>] (bitmap_clear) from [<800197f8>]
(__arm_dma_free.isra.18+0xe4/0x228)
[<800197f8>] (__arm_dma_free.isra.18) from [<80310ba8>]
(xen_swiotlb_free_coherent+0xfc/0x140)
[<80310ba8>] (xen_swiotlb_free_coherent) from [<804ee81c>]
(sdhci_add_host+0xb34/0xe64)
[<804ee81c>] (sdhci_add_host) from [<804f08e4>]
(sdhci_esdhc_imx_probe+0x50c/0x808)
[<804f08e4>] (sdhci_esdhc_imx_probe) from [<80362330>]
(platform_drv_probe+0x44/0xa4)
[<80362330>] (platform_drv_probe) from [<80360b1c>]
(driver_probe_device+0x120/0x25c)
[<80360b1c>] (driver_probe_device) from [<80360d28>]
(__driver_attach+0x8c/0x90)
[<80360d28>] (__driver_attach) from [<8035f10c>]
(bus_for_each_dev+0x60/0x94)
[<8035f10c>] (bus_for_each_dev) from [<803602bc>]
(bus_add_driver+0x148/0x1f0)
[<803602bc>] (bus_add_driver) from [<8036130c>] (driver_register+0x78/0xf8)
[<8036130c>] (driver_register) from [<800088dc>]
(do_one_initcall+0xf8/0x144)
[<800088dc>] (do_one_initcall) from [<80da1c4c>]
(kernel_init_freeable+0x138/0x1d8)
[<80da1c4c>] (kernel_init_freeable) from [<8072725c>] (kernel_init+0x8/0xf0)
[<8072725c>] (kernel_init) from [<8000ecf8>] (ret_from_fork+0x14/0x3c)
Code: 10866003 1206601f 10633006 11e02312 (e5953000)
---[ end trace f6f103bb73cc0503 ]---
note: swapper/0[1] exited with preempt_count 1
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
The piece code is at here:
if (host->flags & SDHCI_USE_ADMA) {
/*
* We need to allocate descriptors for all sg entries
* (128) and potentially one alignment transfer for
* each of those entries.
*/
host->adma_desc = dma_alloc_coherent(mmc_dev(host->mmc),
ADMA_SIZE, &host->adma_addr,
GFP_KERNEL);
host->align_buffer = kmalloc(128 * 4, GFP_KERNEL);
printk("%p %p\n", host->adma_desc, host->align_buffer); --->
Here host->adma_desc is NULL
if (!host->adma_desc || !host->align_buffer) {
dma_free_coherent(mmc_dev(host->mmc), ADMA_SIZE,
-->Trigger panic
host->adma_desc, host->adma_addr);
kfree(host->align_buffer);
So dma_alloc_coherent failed, dma_free_coherent-->bitmap_clear trigger
Dom0 panic. 128M memory is for Dom0, dma_alloc_coherent should not fail.
Do you have any suggestions?
>
> Regards,
>
Thanks,
Peng.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Dom0 kernel panic when porting xen to new arm soc
2015-06-20 14:08 ` Peng Fan
@ 2015-06-20 14:47 ` Peng Fan
2015-06-22 10:20 ` Julien Grall
0 siblings, 1 reply; 15+ messages in thread
From: Peng Fan @ 2015-06-20 14:47 UTC (permalink / raw)
To: Julien Grall, Ian Campbell; +Cc: julien.grall, xen-devel
Hi
On 6/20/2015 10:08 PM, Peng Fan wrote:
> Hi Julien,
>
> On 6/20/2015 6:19 PM, Julien Grall wrote:
>> Hi,
>>
>> On 19/06/2015 14:22, Peng Fan wrote:
>>> diff --git a/kernel/timer.c b/kernel/timer.c
>>> index 38f0d40..4a025cc 100644
>>> --- a/kernel/timer.c
>>> +++ b/kernel/timer.c
>>> @@ -1175,6 +1175,10 @@ static inline void __run_timers(struct tvec_base
>>> *base)
>>>
>>> base->running_timer = timer;
>>> detach_expired_timer(timer, base);
>>> + if (!fn) {
>>> + printk("fn is null why????\n"); ---->
>>> This log only shows once. Not sure why fn is null and only once.
>>> + continue;
>>> + }
>>>
>>> if (irqsafe) {
>>> spin_unlock(&base->lock);
>>
>> By any chance, does your board has a another timer (i.e other than the
>> generic timer)?
>
> Yeah. There is a another timer whose rating is lower that generic timer.
>>
>> I would also track down to see who is adding this timer.
>>
>>> But after apply the above kernel patch, Dom0 Linux can handle shell
>>> input.
>>> Just have another question, How can Dom0 handle DMA for arm.
>>
>> When Xen is allocating the RAM bank for DOM0 we use a direct mapping
>> (i.e the Physical Address = Intermediate Address for the RAM). So DOM0
>> can perform DMA as on baremetal.
> Thanks. Current, without using rootfs in sd card, my Dom0 kernel can
> boot using ramfs. But if with sdhc which use ADMA, Dom0 kernel will
> panic. Below is the log:
>
> sdhci: Secure Digital Host Controller Interface driver
> sdhci: Copyright(c) Pierre Ossman
> sdhci-pltfm: SDHCI platform and OF driver helper
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> pgd = 80004000
> [00000000] *pgd=00000000
> Internal error: Oops: 5 [#1] PREEMPT SMP ARM
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.38-02383-g5ccf32b-dirty #22
> task: 84074000 ti: 84078000 task.ti: 84078000
> PC is at bitmap_clear+0xc0/0xdc
> LR is at bitmap_clear+0x54/0xdc
> pc : [<8029deb8>] lr : [<8029de4c>] psr: 20000193
> sp : 84079d80 ip : 00000001 fp : 00000000
> r10: 00077fff r9 : 00000404 r8 : 00000001
> r7 : 00000001 r6 : 00000001 r5 : 00000000 r4 : ffffffff
> r3 : 00000001 r2 : 00000001 r1 : 20000193 r0 : 00000015
> Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
> Control: 10c53c7d Table: 8800406a DAC: 00000015
> Process swapper/0 (pid: 1, stack limit = 0x84078238)
> Stack: (0x84079d80 to 0x8407a000)
> 9d80: 80000113 00000000 87efa000 81109918 00001000 800197f8 84128558
> 00080008
> 9da0: 84079dec 000000d0 84bfeac0 84126c10 84126c10 ffffffff 00000404
> ffffffff
> 9dc0: 00000000 00000402 00000000 00000000 84126c10 80310ba8 ffffffff
> 00000000
> 9de0: 00000000 00000524 84078000 00000000 00000000 ffffffff ffffffff
> 84bfeac0
> 9e00: 84bfe800 8000b407 07eb0000 8116e0f8 00000000 804ee81c ffffffff
> ffffffff
> 9e20: 00000000 84126c10 84c92010 84bfeac0 00000000 84126c10 84126c00
> 84bfeac0
> 9e40: 84078030 804f08e4 804f03d8 84126c10 fffffdfb 8115401c 8115401c
> 00000000
> 9e60: 0000010f 80362330 803622ec 84126c10 811c8098 00000000 8115401c
> 80360b1c
> 9e80: 84126c10 8115401c 84126c44 00000000 80de1888 80360d28 00000000
> 8115401c
> 9ea0: 80360c9c 8035f10c 8406965c 84123634 8115401c 84c8bf80 8112f3c8
> 803602bc
> 9ec0: 80d08314 8115401c 00000006 8115401c 00000006 8116e080 8116e080
> 8036130c
> 9ee0: 00000000 80e00f78 00000006 800088dc 8400f900 80c94fe0 840bd480
> 80735184
> 9f00: 00000000 8116e080 0000150c 8012d430 00000000 811105b0 60000113
> 00000001
> 9f20: 87ffc576 8075ca38 0000010f 8004b0f0 80d66884 00000006 87ffc583
> 00000006
> 9f40: 811105a0 80e00f78 00000006 8116e080 8116e080 80da150c 0000010f
> 80df4154
> 9f60: 80df4148 80da1c4c 00000006 00000006 80da150c 9355553c 84079f9c
> 80731338
> 9f80: 00000000 00000000 80727254 00000000 00000000 00000000 00000000
> 00000000
> 9fa0: 00000000 8072725c 00000000 8000ecf8 00000000 00000000 00000000
> 00000000
> 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 00000000
> 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 9355553c
> 9355553c
> [<8029deb8>] (bitmap_clear) from [<800197f8>]
> (__arm_dma_free.isra.18+0xe4/0x228)
> [<800197f8>] (__arm_dma_free.isra.18) from [<80310ba8>]
> (xen_swiotlb_free_coherent+0xfc/0x140)
> [<80310ba8>] (xen_swiotlb_free_coherent) from [<804ee81c>]
> (sdhci_add_host+0xb34/0xe64)
> [<804ee81c>] (sdhci_add_host) from [<804f08e4>]
> (sdhci_esdhc_imx_probe+0x50c/0x808)
> [<804f08e4>] (sdhci_esdhc_imx_probe) from [<80362330>]
> (platform_drv_probe+0x44/0xa4)
> [<80362330>] (platform_drv_probe) from [<80360b1c>]
> (driver_probe_device+0x120/0x25c)
> [<80360b1c>] (driver_probe_device) from [<80360d28>]
> (__driver_attach+0x8c/0x90)
> [<80360d28>] (__driver_attach) from [<8035f10c>]
> (bus_for_each_dev+0x60/0x94)
> [<8035f10c>] (bus_for_each_dev) from [<803602bc>]
> (bus_add_driver+0x148/0x1f0)
> [<803602bc>] (bus_add_driver) from [<8036130c>] (driver_register+0x78/0xf8)
> [<8036130c>] (driver_register) from [<800088dc>]
> (do_one_initcall+0xf8/0x144)
> [<800088dc>] (do_one_initcall) from [<80da1c4c>]
> (kernel_init_freeable+0x138/0x1d8)
> [<80da1c4c>] (kernel_init_freeable) from [<8072725c>] (kernel_init+0x8/0xf0)
> [<8072725c>] (kernel_init) from [<8000ecf8>] (ret_from_fork+0x14/0x3c)
> Code: 10866003 1206601f 10633006 11e02312 (e5953000)
> ---[ end trace f6f103bb73cc0503 ]---
> note: swapper/0[1] exited with preempt_count 1
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>
> The piece code is at here:
> if (host->flags & SDHCI_USE_ADMA) {
> /*
> * We need to allocate descriptors for all sg entries
> * (128) and potentially one alignment transfer for
> * each of those entries.
> */
> host->adma_desc = dma_alloc_coherent(mmc_dev(host->mmc),
> ADMA_SIZE, &host->adma_addr,
> GFP_KERNEL);
> host->align_buffer = kmalloc(128 * 4, GFP_KERNEL);
> printk("%p %p\n", host->adma_desc, host->align_buffer); --->
> Here host->adma_desc is NULL
> if (!host->adma_desc || !host->align_buffer) {
> dma_free_coherent(mmc_dev(host->mmc), ADMA_SIZE,
> -->Trigger panic
> host->adma_desc, host->adma_addr);
> kfree(host->align_buffer);
>
> So dma_alloc_coherent failed, dma_free_coherent-->bitmap_clear trigger
> Dom0 panic. 128M memory is for Dom0, dma_alloc_coherent should not fail.
> Do you have any suggestions?
>
In my Dom0 kernel configuration:CONFIG_CMA_SIZE_MBYTES=320. But Dom0
kernel memsize is only 128M. From Dom0 kernel boot info, we can see CMA
alloc 3200M failed. Anyway, I think this should not only change
CONFIG_CMD_SIZE_MBYTES that simple, kernel should handle such case, but
not panic. After change CONFIG_CMD_SIZE_MBYTES to 24M, the panic
disappears.
Another problem comes to me, with 128M for Dom0, Dom0 can printk msg to
serial, but with "dom0_mem=1024M", I see nothing from serial for Dom0.
>>
>> Regards,
>>
> Thanks,
> Peng.
>
Thanks,
Peng.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Dom0 kernel panic when porting xen to new arm soc
2015-06-20 14:47 ` Peng Fan
@ 2015-06-22 10:20 ` Julien Grall
2015-06-22 11:17 ` Peng Fan
0 siblings, 1 reply; 15+ messages in thread
From: Julien Grall @ 2015-06-22 10:20 UTC (permalink / raw)
To: Peng Fan, Ian Campbell; +Cc: julien.grall, Stefano Stabellini, xen-devel
On 20/06/15 15:47, Peng Fan wrote:
> On 6/20/2015 10:08 PM, Peng Fan wrote:
>> Hi Julien,
>>
>> On 6/20/2015 6:19 PM, Julien Grall wrote:
>>> Hi,
>>>
>>> On 19/06/2015 14:22, Peng Fan wrote:
>>>> diff --git a/kernel/timer.c b/kernel/timer.c
>>>> index 38f0d40..4a025cc 100644
>>>> --- a/kernel/timer.c
>>>> +++ b/kernel/timer.c
>>>> @@ -1175,6 +1175,10 @@ static inline void __run_timers(struct tvec_base
>>>> *base)
>>>>
>>>> base->running_timer = timer;
>>>> detach_expired_timer(timer, base);
>>>> + if (!fn) {
>>>> + printk("fn is null why????\n"); ---->
>>>> This log only shows once. Not sure why fn is null and only once.
>>>> + continue;
>>>> + }
>>>>
>>>> if (irqsafe) {
>>>> spin_unlock(&base->lock);
>>>
>>> By any chance, does your board has a another timer (i.e other than the
>>> generic timer)?
>>
>> Yeah. There is a another timer whose rating is lower that generic timer.
>>>
>>> I would also track down to see who is adding this timer.
>>>
>>>> But after apply the above kernel patch, Dom0 Linux can handle shell
>>>> input.
>>>> Just have another question, How can Dom0 handle DMA for arm.
>>>
>>> When Xen is allocating the RAM bank for DOM0 we use a direct mapping
>>> (i.e the Physical Address = Intermediate Address for the RAM). So DOM0
>>> can perform DMA as on baremetal.
>> Thanks. Current, without using rootfs in sd card, my Dom0 kernel can
>> boot using ramfs. But if with sdhc which use ADMA, Dom0 kernel will
>> panic. Below is the log:
>>
>> sdhci: Secure Digital Host Controller Interface driver
>> sdhci: Copyright(c) Pierre Ossman
>> sdhci-pltfm: SDHCI platform and OF driver helper
>> Unable to handle kernel NULL pointer dereference at virtual address 00000000
>> pgd = 80004000
>> [00000000] *pgd=00000000
>> Internal error: Oops: 5 [#1] PREEMPT SMP ARM
>> Modules linked in:
>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.38-02383-g5ccf32b-dirty #22
>> task: 84074000 ti: 84078000 task.ti: 84078000
>> PC is at bitmap_clear+0xc0/0xdc
>> LR is at bitmap_clear+0x54/0xdc
>> pc : [<8029deb8>] lr : [<8029de4c>] psr: 20000193
>> sp : 84079d80 ip : 00000001 fp : 00000000
>> r10: 00077fff r9 : 00000404 r8 : 00000001
>> r7 : 00000001 r6 : 00000001 r5 : 00000000 r4 : ffffffff
>> r3 : 00000001 r2 : 00000001 r1 : 20000193 r0 : 00000015
>> Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
>> Control: 10c53c7d Table: 8800406a DAC: 00000015
>> Process swapper/0 (pid: 1, stack limit = 0x84078238)
>> Stack: (0x84079d80 to 0x8407a000)
>> 9d80: 80000113 00000000 87efa000 81109918 00001000 800197f8 84128558
>> 00080008
>> 9da0: 84079dec 000000d0 84bfeac0 84126c10 84126c10 ffffffff 00000404
>> ffffffff
>> 9dc0: 00000000 00000402 00000000 00000000 84126c10 80310ba8 ffffffff
>> 00000000
>> 9de0: 00000000 00000524 84078000 00000000 00000000 ffffffff ffffffff
>> 84bfeac0
>> 9e00: 84bfe800 8000b407 07eb0000 8116e0f8 00000000 804ee81c ffffffff
>> ffffffff
>> 9e20: 00000000 84126c10 84c92010 84bfeac0 00000000 84126c10 84126c00
>> 84bfeac0
>> 9e40: 84078030 804f08e4 804f03d8 84126c10 fffffdfb 8115401c 8115401c
>> 00000000
>> 9e60: 0000010f 80362330 803622ec 84126c10 811c8098 00000000 8115401c
>> 80360b1c
>> 9e80: 84126c10 8115401c 84126c44 00000000 80de1888 80360d28 00000000
>> 8115401c
>> 9ea0: 80360c9c 8035f10c 8406965c 84123634 8115401c 84c8bf80 8112f3c8
>> 803602bc
>> 9ec0: 80d08314 8115401c 00000006 8115401c 00000006 8116e080 8116e080
>> 8036130c
>> 9ee0: 00000000 80e00f78 00000006 800088dc 8400f900 80c94fe0 840bd480
>> 80735184
>> 9f00: 00000000 8116e080 0000150c 8012d430 00000000 811105b0 60000113
>> 00000001
>> 9f20: 87ffc576 8075ca38 0000010f 8004b0f0 80d66884 00000006 87ffc583
>> 00000006
>> 9f40: 811105a0 80e00f78 00000006 8116e080 8116e080 80da150c 0000010f
>> 80df4154
>> 9f60: 80df4148 80da1c4c 00000006 00000006 80da150c 9355553c 84079f9c
>> 80731338
>> 9f80: 00000000 00000000 80727254 00000000 00000000 00000000 00000000
>> 00000000
>> 9fa0: 00000000 8072725c 00000000 8000ecf8 00000000 00000000 00000000
>> 00000000
>> 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> 00000000
>> 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 9355553c
>> 9355553c
>> [<8029deb8>] (bitmap_clear) from [<800197f8>]
>> (__arm_dma_free.isra.18+0xe4/0x228)
>> [<800197f8>] (__arm_dma_free.isra.18) from [<80310ba8>]
>> (xen_swiotlb_free_coherent+0xfc/0x140)
>> [<80310ba8>] (xen_swiotlb_free_coherent) from [<804ee81c>]
>> (sdhci_add_host+0xb34/0xe64)
>> [<804ee81c>] (sdhci_add_host) from [<804f08e4>]
>> (sdhci_esdhc_imx_probe+0x50c/0x808)
>> [<804f08e4>] (sdhci_esdhc_imx_probe) from [<80362330>]
>> (platform_drv_probe+0x44/0xa4)
>> [<80362330>] (platform_drv_probe) from [<80360b1c>]
>> (driver_probe_device+0x120/0x25c)
>> [<80360b1c>] (driver_probe_device) from [<80360d28>]
>> (__driver_attach+0x8c/0x90)
>> [<80360d28>] (__driver_attach) from [<8035f10c>]
>> (bus_for_each_dev+0x60/0x94)
>> [<8035f10c>] (bus_for_each_dev) from [<803602bc>]
>> (bus_add_driver+0x148/0x1f0)
>> [<803602bc>] (bus_add_driver) from [<8036130c>] (driver_register+0x78/0xf8)
>> [<8036130c>] (driver_register) from [<800088dc>]
>> (do_one_initcall+0xf8/0x144)
>> [<800088dc>] (do_one_initcall) from [<80da1c4c>]
>> (kernel_init_freeable+0x138/0x1d8)
>> [<80da1c4c>] (kernel_init_freeable) from [<8072725c>] (kernel_init+0x8/0xf0)
>> [<8072725c>] (kernel_init) from [<8000ecf8>] (ret_from_fork+0x14/0x3c)
>> Code: 10866003 1206601f 10633006 11e02312 (e5953000)
>> ---[ end trace f6f103bb73cc0503 ]---
>> note: swapper/0[1] exited with preempt_count 1
>> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>>
>> The piece code is at here:
>> if (host->flags & SDHCI_USE_ADMA) {
>> /*
>> * We need to allocate descriptors for all sg entries
>> * (128) and potentially one alignment transfer for
>> * each of those entries.
>> */
>> host->adma_desc = dma_alloc_coherent(mmc_dev(host->mmc),
>> ADMA_SIZE, &host->adma_addr,
>> GFP_KERNEL);
>> host->align_buffer = kmalloc(128 * 4, GFP_KERNEL);
>> printk("%p %p\n", host->adma_desc, host->align_buffer); --->
>> Here host->adma_desc is NULL
>> if (!host->adma_desc || !host->align_buffer) {
>> dma_free_coherent(mmc_dev(host->mmc), ADMA_SIZE,
>> -->Trigger panic
>> host->adma_desc, host->adma_addr);
>> kfree(host->align_buffer);
>>
>> So dma_alloc_coherent failed, dma_free_coherent-->bitmap_clear trigger
>> Dom0 panic. 128M memory is for Dom0, dma_alloc_coherent should not fail.
>> Do you have any suggestions?
>>
Adding Stefano as he worked on DMA/swiotlb for ARM.
> Another problem comes to me, with 128M for Dom0, Dom0 can printk msg to
> serial, but with "dom0_mem=1024M", I see nothing from serial for Dom0.
Well, the RAM bank will surely be different between the 2 configurations.
The DOM0 may have crashed before the console has effectively setup for
multiple reason.
Can you try this hacky patch [1], it will print everything using the Xen
console.
[1] http://lists.xen.org/archives/html/xen-devel/2014-10/msg03436.html
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Dom0 kernel panic when porting xen to new arm soc
2015-06-22 10:20 ` Julien Grall
@ 2015-06-22 11:17 ` Peng Fan
2015-06-22 14:02 ` Julien Grall
0 siblings, 1 reply; 15+ messages in thread
From: Peng Fan @ 2015-06-22 11:17 UTC (permalink / raw)
To: Julien Grall, Ian Campbell; +Cc: Stefano Stabellini, xen-devel
On 6/22/2015 6:20 PM, Julien Grall wrote:
> On 20/06/15 15:47, Peng Fan wrote:
>> On 6/20/2015 10:08 PM, Peng Fan wrote:
>>> Hi Julien,
>>>
>>> On 6/20/2015 6:19 PM, Julien Grall wrote:
>>>> Hi,
>>>>
>>>> On 19/06/2015 14:22, Peng Fan wrote:
>>>>> diff --git a/kernel/timer.c b/kernel/timer.c
>>>>> index 38f0d40..4a025cc 100644
>>>>> --- a/kernel/timer.c
>>>>> +++ b/kernel/timer.c
>>>>> @@ -1175,6 +1175,10 @@ static inline void __run_timers(struct tvec_base
>>>>> *base)
>>>>>
>>>>> base->running_timer = timer;
>>>>> detach_expired_timer(timer, base);
>>>>> + if (!fn) {
>>>>> + printk("fn is null why????\n"); ---->
>>>>> This log only shows once. Not sure why fn is null and only once.
>>>>> + continue;
>>>>> + }
>>>>>
>>>>> if (irqsafe) {
>>>>> spin_unlock(&base->lock);
>>>>
>>>> By any chance, does your board has a another timer (i.e other than the
>>>> generic timer)?
>>>
>>> Yeah. There is a another timer whose rating is lower that generic timer.
>>>>
>>>> I would also track down to see who is adding this timer.
>>>>
>>>>> But after apply the above kernel patch, Dom0 Linux can handle shell
>>>>> input.
>>>>> Just have another question, How can Dom0 handle DMA for arm.
>>>>
>>>> When Xen is allocating the RAM bank for DOM0 we use a direct mapping
>>>> (i.e the Physical Address = Intermediate Address for the RAM). So DOM0
>>>> can perform DMA as on baremetal.
>>> Thanks. Current, without using rootfs in sd card, my Dom0 kernel can
>>> boot using ramfs. But if with sdhc which use ADMA, Dom0 kernel will
>>> panic. Below is the log:
>>>
>>> sdhci: Secure Digital Host Controller Interface driver
>>> sdhci: Copyright(c) Pierre Ossman
>>> sdhci-pltfm: SDHCI platform and OF driver helper
>>> Unable to handle kernel NULL pointer dereference at virtual address 00000000
>>> pgd = 80004000
>>> [00000000] *pgd=00000000
>>> Internal error: Oops: 5 [#1] PREEMPT SMP ARM
>>> Modules linked in:
>>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.38-02383-g5ccf32b-dirty #22
>>> task: 84074000 ti: 84078000 task.ti: 84078000
>>> PC is at bitmap_clear+0xc0/0xdc
>>> LR is at bitmap_clear+0x54/0xdc
>>> pc : [<8029deb8>] lr : [<8029de4c>] psr: 20000193
>>> sp : 84079d80 ip : 00000001 fp : 00000000
>>> r10: 00077fff r9 : 00000404 r8 : 00000001
>>> r7 : 00000001 r6 : 00000001 r5 : 00000000 r4 : ffffffff
>>> r3 : 00000001 r2 : 00000001 r1 : 20000193 r0 : 00000015
>>> Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
>>> Control: 10c53c7d Table: 8800406a DAC: 00000015
>>> Process swapper/0 (pid: 1, stack limit = 0x84078238)
>>> Stack: (0x84079d80 to 0x8407a000)
>>> 9d80: 80000113 00000000 87efa000 81109918 00001000 800197f8 84128558
>>> 00080008
>>> 9da0: 84079dec 000000d0 84bfeac0 84126c10 84126c10 ffffffff 00000404
>>> ffffffff
>>> 9dc0: 00000000 00000402 00000000 00000000 84126c10 80310ba8 ffffffff
>>> 00000000
>>> 9de0: 00000000 00000524 84078000 00000000 00000000 ffffffff ffffffff
>>> 84bfeac0
>>> 9e00: 84bfe800 8000b407 07eb0000 8116e0f8 00000000 804ee81c ffffffff
>>> ffffffff
>>> 9e20: 00000000 84126c10 84c92010 84bfeac0 00000000 84126c10 84126c00
>>> 84bfeac0
>>> 9e40: 84078030 804f08e4 804f03d8 84126c10 fffffdfb 8115401c 8115401c
>>> 00000000
>>> 9e60: 0000010f 80362330 803622ec 84126c10 811c8098 00000000 8115401c
>>> 80360b1c
>>> 9e80: 84126c10 8115401c 84126c44 00000000 80de1888 80360d28 00000000
>>> 8115401c
>>> 9ea0: 80360c9c 8035f10c 8406965c 84123634 8115401c 84c8bf80 8112f3c8
>>> 803602bc
>>> 9ec0: 80d08314 8115401c 00000006 8115401c 00000006 8116e080 8116e080
>>> 8036130c
>>> 9ee0: 00000000 80e00f78 00000006 800088dc 8400f900 80c94fe0 840bd480
>>> 80735184
>>> 9f00: 00000000 8116e080 0000150c 8012d430 00000000 811105b0 60000113
>>> 00000001
>>> 9f20: 87ffc576 8075ca38 0000010f 8004b0f0 80d66884 00000006 87ffc583
>>> 00000006
>>> 9f40: 811105a0 80e00f78 00000006 8116e080 8116e080 80da150c 0000010f
>>> 80df4154
>>> 9f60: 80df4148 80da1c4c 00000006 00000006 80da150c 9355553c 84079f9c
>>> 80731338
>>> 9f80: 00000000 00000000 80727254 00000000 00000000 00000000 00000000
>>> 00000000
>>> 9fa0: 00000000 8072725c 00000000 8000ecf8 00000000 00000000 00000000
>>> 00000000
>>> 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>>> 00000000
>>> 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 9355553c
>>> 9355553c
>>> [<8029deb8>] (bitmap_clear) from [<800197f8>]
>>> (__arm_dma_free.isra.18+0xe4/0x228)
>>> [<800197f8>] (__arm_dma_free.isra.18) from [<80310ba8>]
>>> (xen_swiotlb_free_coherent+0xfc/0x140)
>>> [<80310ba8>] (xen_swiotlb_free_coherent) from [<804ee81c>]
>>> (sdhci_add_host+0xb34/0xe64)
>>> [<804ee81c>] (sdhci_add_host) from [<804f08e4>]
>>> (sdhci_esdhc_imx_probe+0x50c/0x808)
>>> [<804f08e4>] (sdhci_esdhc_imx_probe) from [<80362330>]
>>> (platform_drv_probe+0x44/0xa4)
>>> [<80362330>] (platform_drv_probe) from [<80360b1c>]
>>> (driver_probe_device+0x120/0x25c)
>>> [<80360b1c>] (driver_probe_device) from [<80360d28>]
>>> (__driver_attach+0x8c/0x90)
>>> [<80360d28>] (__driver_attach) from [<8035f10c>]
>>> (bus_for_each_dev+0x60/0x94)
>>> [<8035f10c>] (bus_for_each_dev) from [<803602bc>]
>>> (bus_add_driver+0x148/0x1f0)
>>> [<803602bc>] (bus_add_driver) from [<8036130c>] (driver_register+0x78/0xf8)
>>> [<8036130c>] (driver_register) from [<800088dc>]
>>> (do_one_initcall+0xf8/0x144)
>>> [<800088dc>] (do_one_initcall) from [<80da1c4c>]
>>> (kernel_init_freeable+0x138/0x1d8)
>>> [<80da1c4c>] (kernel_init_freeable) from [<8072725c>] (kernel_init+0x8/0xf0)
>>> [<8072725c>] (kernel_init) from [<8000ecf8>] (ret_from_fork+0x14/0x3c)
>>> Code: 10866003 1206601f 10633006 11e02312 (e5953000)
>>> ---[ end trace f6f103bb73cc0503 ]---
>>> note: swapper/0[1] exited with preempt_count 1
>>> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>>>
>>> The piece code is at here:
>>> if (host->flags & SDHCI_USE_ADMA) {
>>> /*
>>> * We need to allocate descriptors for all sg entries
>>> * (128) and potentially one alignment transfer for
>>> * each of those entries.
>>> */
>>> host->adma_desc = dma_alloc_coherent(mmc_dev(host->mmc),
>>> ADMA_SIZE, &host->adma_addr,
>>> GFP_KERNEL);
>>> host->align_buffer = kmalloc(128 * 4, GFP_KERNEL);
>>> printk("%p %p\n", host->adma_desc, host->align_buffer); --->
>>> Here host->adma_desc is NULL
>>> if (!host->adma_desc || !host->align_buffer) {
>>> dma_free_coherent(mmc_dev(host->mmc), ADMA_SIZE,
>>> -->Trigger panic
>>> host->adma_desc, host->adma_addr);
>>> kfree(host->align_buffer);
>>>
>>> So dma_alloc_coherent failed, dma_free_coherent-->bitmap_clear trigger
>>> Dom0 panic. 128M memory is for Dom0, dma_alloc_coherent should not fail.
>>> Do you have any suggestions?
>>>
>
> Adding Stefano as he worked on DMA/swiotlb for ARM.
Already fixed. This is mmc/host/sdhci.c bug, I have a patch to fix this:
http://marc.info/?l=linux-kernel&m=143494451910852&w=2. Also I have a
configuration error, CONFIG_CMA_SIZE_MBYTES is too big 320M, but Dom0
mem only 128M.
>
>> Another problem comes to me, with 128M for Dom0, Dom0 can printk msg to
>> serial, but with "dom0_mem=1024M", I see nothing from serial for Dom0.
>
> Well, the RAM bank will surely be different between the 2 configurations.
>
> The DOM0 may have crashed before the console has effectively setup for
> multiple reason.
> Can you try this hacky patch [1], it will print everything using the Xen
> console.
>
> [1] http://lists.xen.org/archives/html/xen-devel/2014-10/msg03436.html
Thanks for this. Since there are two serial ports, I use uart2 for
earlyprintk.
I get why 512M or 1024M fail, but 128M and 256M is ok. But do not have
solution for this.
My platform's ddr memory is from 0x80000000 to 0xffffffff, total 2GB. My
xen boot args:
"
setenv xen_addr_r 0x80000000
setenv bootargs "console=dtuart
dtuart=/soc/aips-bus@30800000/serial@30860000 dom0_mem=256M"
fatload mmc 0:1 0x80000000 xen.image
fatload mmc 0:1 0x84000000 zImage
setenv kernel_addr_r 0x84000000
setenv fdt_high 0xffffffff
setenv fdt_addr 0x83000000
run loadfdt
fdt addr ${fdt_addr} 0x40000
fdt resize
fdt chosen
fdt set /chosen \#address-cells <1>
fdt set /chosen \#size-cells <1>
fdt mknod /chosen module@0
fdt set /chosen/module@0 compatible "xen,linux-zimage"
"xen,multiboot-module"
fdt set /chosen/module@0 reg <${kernel_addr_r} 0x${filesize}>
fdt set /chosen/module@0 bootargs "console=hvc0 ro root=/dev/mmcblk0p2
clk_ignore_unused uart_from_osc loglevel=8 earlyprintk"
bootz ${xen_addr_r} - ${fdt_addr}
"
I add debug log in this piece of code:
void __init sanity_check_meminfo(void)
{
phys_addr_t memblock_limit = 0;
int i, j, highmem = 0;
phys_addr_t vmalloc_limit = __pa(vmalloc_min - 1) + 1;
printk("vmalloc_min virt %x phys %x\n", vmalloc_min - 1,
__pa(vmalloc_min - 1));
printk("vmalloc_limit %x\n", vmalloc_limit);
If use 512M for Dom0, I found vmalloc_limit is 0xf800000, vmalloc_min is
0xef800000, This comes to a question, why __pa(vmalloc_min - 1) + will
make vmalloc_limit only 0xf800000 which is less than 128M. the pv stub
does some runtime fixup for virt_to_phys here.
Since vmalloc_limit is small, then all other memory bank in my platform
is recoginied as highmem, then arm_lowmem_limit is 0, then kernel panic:
"
dma_contiguous_reserve_area(size 1800000, base 00000000, limit 00000000)
CMA: failed to reserve 32 MiB
Memory policy: Data cache writealloc
Kernel panic - not syncing: ERROR: Failed to allocate 0x2000 bytes below
0x0.
"
0xffffffff - 0xef8000000 is about 264M. So I choose 256M as the Dom0
memory size. I do not have clear idea about this, current I am trying to
use xl to boot DomU, so just use 256M for Dom0 here.
>
> Regards,
>
Regards,
Peng.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Dom0 kernel panic when porting xen to new arm soc
2015-06-22 11:17 ` Peng Fan
@ 2015-06-22 14:02 ` Julien Grall
2015-06-23 13:03 ` Peng Fan
0 siblings, 1 reply; 15+ messages in thread
From: Julien Grall @ 2015-06-22 14:02 UTC (permalink / raw)
To: Peng Fan, Julien Grall, Ian Campbell; +Cc: xen-devel, Stefano Stabellini
On 22/06/15 12:17, Peng Fan wrote:
> I add debug log in this piece of code:
> void __init sanity_check_meminfo(void)
>
> {
>
> phys_addr_t memblock_limit = 0;
> int i, j, highmem = 0;
> phys_addr_t vmalloc_limit = __pa(vmalloc_min - 1) + 1;
>
>
> printk("vmalloc_min virt %x phys %x\n", vmalloc_min - 1,
> __pa(vmalloc_min - 1));
> printk("vmalloc_limit %x\n", vmalloc_limit);
>
> If use 512M for Dom0, I found vmalloc_limit is 0xf800000, vmalloc_min is
> 0xef800000, This comes to a question, why __pa(vmalloc_min - 1) + will
> make vmalloc_limit only 0xf800000 which is less than 128M. the pv stub
> does some runtime fixup for virt_to_phys here.
> Since vmalloc_limit is small, then all other memory bank in my platform
> is recoginied as highmem, then arm_lowmem_limit is 0, then kernel panic:
> "
> dma_contiguous_reserve_area(size 1800000, base 00000000, limit 00000000)
> CMA: failed to reserve 32 MiB
> Memory policy: Data cache writealloc
> Kernel panic - not syncing: ERROR: Failed to allocate 0x2000 bytes below
> 0x0.
> "
> 0xffffffff - 0xef8000000 is about 264M. So I choose 256M as the Dom0
> memory size. I do not have clear idea about this, current I am trying to
> use xl to boot DomU, so just use 256M for Dom0 here.
There use to be some issue with the way how the offset between physical
and virtual address was computed.
Do you use LPAE or short page table? Can you provide the xen log when
DOM0 is using 512MB?
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Dom0 kernel panic when porting xen to new arm soc
2015-06-22 14:02 ` Julien Grall
@ 2015-06-23 13:03 ` Peng Fan
2015-06-23 13:36 ` Julien Grall
0 siblings, 1 reply; 15+ messages in thread
From: Peng Fan @ 2015-06-23 13:03 UTC (permalink / raw)
To: Julien Grall, Ian Campbell; +Cc: xen-devel, Stefano Stabellini
On 6/22/2015 10:02 PM, Julien Grall wrote:
> On 22/06/15 12:17, Peng Fan wrote:
>> I add debug log in this piece of code:
>> void __init sanity_check_meminfo(void)
>>
>> {
>>
>> phys_addr_t memblock_limit = 0;
>> int i, j, highmem = 0;
>> phys_addr_t vmalloc_limit = __pa(vmalloc_min - 1) + 1;
>>
>>
>> printk("vmalloc_min virt %x phys %x\n", vmalloc_min - 1,
>> __pa(vmalloc_min - 1));
>> printk("vmalloc_limit %x\n", vmalloc_limit);
>>
>> If use 512M for Dom0, I found vmalloc_limit is 0xf800000, vmalloc_min is
>> 0xef800000, This comes to a question, why __pa(vmalloc_min - 1) + will
>> make vmalloc_limit only 0xf800000 which is less than 128M. the pv stub
>> does some runtime fixup for virt_to_phys here.
>> Since vmalloc_limit is small, then all other memory bank in my platform
>> is recoginied as highmem, then arm_lowmem_limit is 0, then kernel panic:
>> "
>> dma_contiguous_reserve_area(size 1800000, base 00000000, limit 00000000)
>> CMA: failed to reserve 32 MiB
>> Memory policy: Data cache writealloc
>> Kernel panic - not syncing: ERROR: Failed to allocate 0x2000 bytes below
>> 0x0.
>> "
>> 0xffffffff - 0xef8000000 is about 264M. So I choose 256M as the Dom0
>> memory size. I do not have clear idea about this, current I am trying to
>> use xl to boot DomU, so just use 256M for Dom0 here.
>
> There use to be some issue with the way how the offset between physical
> and virtual address was computed.
>
> Do you use LPAE or short page table? Can you provide the xen log when
> DOM0 is using 512MB?
I did not enable LPAE for DOM0 kernel, use shor page table.
Following is the full log from uboot to kernel with DOM0 512M:
U-Boot 2015.04-rc4-00145-gf12a16e-dirty (Jun 19 2015 - 15:26:52)
CPU: Freescale i.MX7D rev1.0 at 792 MHz
CPU: Thermal invalid data, fuse: 0x1b800
CPU: Temperature: Can't find sensor device
Reset cause: POR
Board: MX7D 12x12 LPDDR3 ARM2
I2C: ready
DRAM: 2 GiB
PMIC: PFUZE300 DEV_ID=0x30 REV_ID=0x10
MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
Display: MCIMX28LCD (800x480)
Video: 800x480x24
In: serial
Out: serial
Err: serial
switch to partitions #0, OK
mmc0 is current device
Net: FEC0
Error: FEC0 address not set.
Normal Boot
Hit any key to stop autoboot: 0
=> setenv xen_addr_r 0x80000000
=> setenv bootargs "console=dtuart
dtuart=/soc/aips-bus@30800000/serial@30860000 dom0_mem=256M"
=> fatload mmc 0:1 0x80000000 xen.image
reading xen.image
754544 bytes read in 129 ms (5.6 MiB/s)
=> setenv bootargs "console=dtuart
dtuart=/soc/aips-bus@30800000/serial@30860000 dom0_mem=512M"
=> run loadfdt
reading imx7d-12x12-lpddr3-arm2.dtb
40966 bytes read in 26 ms (1.5 MiB/s)
=> fatload mmc 0:1 0x84000000 zImage
reading zImage
6250016 bytes read in 286 ms (20.8 MiB/s)
=> setenv kernel_addr_r 0x84000000
=> setenv fdt_high 0xffffffff
=> setenv fdt_addr 0x83000000
=> fdt addr ${fdt_addr} 0x40000
=> fdt resize
=> fdt chosen
=> fdt set /chosen \#address-cells <1>
=> fdt set /chosen \#size-cells <1>
=> fdt set /chosen/module@0 compatible "xen,linux-zimage"
"xen,multiboot-module"
=> fdt set /chosen/module@0 reg <${kernel_addr_r} 0x${filesize}>
=> fdt set /chosen/module@0 bootargs "console=hvc0 ro
root=/dev/mmcblk0p2 clk_ignore_unused uart_from_osc loglevel=8 earlyprintk"
=> bootz ${xen_addr_r} - ${fdt_addr}
Kernel image @ 0x80000000 [ 0x000000 - 0x101700 ]
## Flattened Device Tree blob at 83000000
Booting using the fdt blob at 0x83000000
reserving fdt memory region: addr=83000000 size=b000
Using Device Tree in place at 83000000, end 8300dfff
Starting kernel ...
- UART enabled -
- CPU 00000000 booting -
- Xen starting in Hyp mode -
- Zero BSS -
- Setting up control registers -
- Turning on paging -
- Ready -
(XEN) Checking for initrd in /chosen
(XEN) RAM: 0000000080000000 - 00000000ffffffff
(XEN)
(XEN) MODULE[0]: 0000000083000000 - 000000008300b000 Device Tree
(XEN) MODULE[1]: 0000000084000000 - 00000000845f5e20 Kernel
console=hvc0 ro root=/dev/mmcblk0p2 clk_ignore_unused uart_from_osc
loglevel=8 earlyprintk
(XEN) RESVD[0]: 0000000083000000 - 000000008300b000
(XEN)
(XEN) Command line: console=dtuart
dtuart=/soc/aips-bus@30800000/serial@30860000 dom0_mem=512M
(XEN) Placing Xen at 0x00000000ffe00000-0x0000000100000000
(XEN) Update BOOTMOD_XEN from 0000000080000000-0000000080101701 =>
00000000ffe00000-00000000fff01701
(XEN) Xen heap: 00000000fa000000-00000000fe000000 (16384 pages)
(XEN) Dom heap: 507904 pages
(XEN) Domain heap initialised
(XEN) Platform: i.MX 7Dual
(XEN) Looking for dtuart at "/soc/aips-bus@30800000/serial@30860000",
options ""
(XEN) imx-uart.c:226: xx 30860000
(XEN) imx-uart.c:98: ===============UFCR USR1 a01 2050
Xen 4.6-unstable
(XEN) Xen version 4.6-unstable (Freenix@(none))
(arm-poky-linux-gnueabi-gcc (GCC) 4.8.2) debug=y Fri Jun 19 18:30:50 CST
2015
(XEN) Latest ChangeSet: Mon Jun 15 18:25:34 2015 +0800 git:c01e139-dirty
(XEN) Processor: 410fc075: "ARM Limited", variant: 0x0, part 0xc07, rev 0x5
(XEN) 32-bit Execution:
(XEN) Processor Features: 00001131:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle
(XEN) Extensions: GenericTimer Security
(XEN) Debug Features: 02010555
(XEN) Auxiliary Features: 00000000
(XEN) Memory Model Features: 10101105 40000000 01240000 02102211
(XEN) ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000
(XEN) Set Secondary entry to 00000000ffe0004c (0020004c)
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 8000 KHz
(XEN) GICv2 initialization:
(XEN) gic_dist_addr=0000000031001000
(XEN) gic_cpu_addr=0000000031002000
(XEN) gic_hyp_addr=0000000031004000
(XEN) gic_vcpu_addr=0000000031006000
(XEN) gic_maintenance_irq=25
(XEN) GICv2: 160 lines, 2 cpus, secure (IID 0100143b).
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) imx-uart.c:117: imx_uart_init_postirq
(XEN) Allocated console ring of 16 KiB.
(XEN) VFP implementer 0x41 architecture 2 part 0x30 variant 0x7 rev 0x5
(XEN) Brought up 1 CPUs
(XEN) P2M: 40-bit IPA
(XEN) P2M: 3 levels with order-1 root, VTCR 0x80003558
(XEN) I/O virtualisation disabled
(XEN) *** LOADING DOMAIN 0 ***
(XEN) domain_build.c:1383: idle loop
(XEN) Loading kernel from boot module @ 0000000084000000
(XEN) Allocating 1:1 mappings totalling 512MB for dom0:
(XEN) BANK[0] 0x000000a0000000-0x000000c0000000 (512MB)
(XEN) Loading zImage from 0000000084000000 to
00000000a7a00000-00000000a7ff5e20
(XEN) Allocating PPI 16 for event channel interrupt
(XEN) Loading dom0 DTB to 0x00000000a8000000-0x00000000a8009de2
(XEN) regs -> pc = 0xa7a00000
(XEN) it is 32 bit machine
(XEN) Scrubbing Free RAM on 1 nodes using 1 CPUs
(XEN) ................done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 284kB init memory.
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.14.38-02383-g5ccf32b-dirty (Freenix@linux-jyl1) (gcc
version 4.8.2 (GCC) ) #49 SMP PREEMPT Mon Jun 22 14:17:14 CST 2015
CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine model: Freescale i.MX7 LPDDR3 12x12 ARM2 Board
bootconsole [earlycon0] enabled
vmalloc_min virt ef7fffff phys f7fffff
dma_contiguous_reserve_area(size 1800000, base 00000000, limit 00000000)
CMA: failed to reserve 32 MiB
Memory policy: Data cache writealloc
Kernel panic - not syncing: ERROR: Failed to allocate 0x2000 bytes below
0x0.
>
> Regards,
>
Regards,
Peng.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Dom0 kernel panic when porting xen to new arm soc
2015-06-23 13:03 ` Peng Fan
@ 2015-06-23 13:36 ` Julien Grall
2015-06-23 13:56 ` Peng Fan
0 siblings, 1 reply; 15+ messages in thread
From: Julien Grall @ 2015-06-23 13:36 UTC (permalink / raw)
To: Peng Fan, Julien Grall, Ian Campbell; +Cc: Stefano Stabellini, xen-devel
Hi,
On 23/06/15 14:03, Peng Fan wrote:
> I did not enable LPAE for DOM0 kernel, use shor page table.
> Following is the full log from uboot to kernel with DOM0 512M:
Which CONFIG_VMSPLIT_* do you use? Can you try to use another one? I
remembered it had some effect on the offset between physical and virtual
address.
Regards,
--
Julien Grall
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Dom0 kernel panic when porting xen to new arm soc
2015-06-23 13:36 ` Julien Grall
@ 2015-06-23 13:56 ` Peng Fan
2015-06-25 14:09 ` Peng Fan
0 siblings, 1 reply; 15+ messages in thread
From: Peng Fan @ 2015-06-23 13:56 UTC (permalink / raw)
To: Julien Grall, Ian Campbell; +Cc: Stefano Stabellini, xen-devel
Hi,
On 6/23/2015 9:36 PM, Julien Grall wrote:
> Hi,
>
> On 23/06/15 14:03, Peng Fan wrote:
>> I did not enable LPAE for DOM0 kernel, use shor page table.
>> Following is the full log from uboot to kernel with DOM0 512M:
>
> Which CONFIG_VMSPLIT_* do you use? Can you try to use another one? I
> remembered it had some effect on the offset between physical and virtual
> address.
CONFIG_VMSPLIT_2G=y
CONFIG_PAGE_OFFSET=0x80000000
ok. Will try 3G:1G split.
>
> Regards,
>
Thanks,
Peng.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Dom0 kernel panic when porting xen to new arm soc
2015-06-23 13:56 ` Peng Fan
@ 2015-06-25 14:09 ` Peng Fan
2015-06-26 16:27 ` Julien Grall
0 siblings, 1 reply; 15+ messages in thread
From: Peng Fan @ 2015-06-25 14:09 UTC (permalink / raw)
To: Julien Grall, Ian Campbell; +Cc: xen-devel, Stefano Stabellini, xen-users
Hi Julien,
On 6/23/2015 9:56 PM, Peng Fan wrote:
> Hi,
>
> On 6/23/2015 9:36 PM, Julien Grall wrote:
>> Hi,
>>
>> On 23/06/15 14:03, Peng Fan wrote:
>>> I did not enable LPAE for DOM0 kernel, use shor page table.
>>> Following is the full log from uboot to kernel with DOM0 512M:
>>
>> Which CONFIG_VMSPLIT_* do you use? Can you try to use another one? I
>> remembered it had some effect on the offset between physical and virtual
>> address.
> CONFIG_VMSPLIT_2G=y
>
> CONFIG_PAGE_OFFSET=0x80000000
>
> ok. Will try 3G:1G split.
Later I'll reply with log info about this(Do not have log at hand).
Still panic, maybe something wrong with gnutab configration in my side,
I use default gnutab address/size.
Current I met a DomU boot issue, if do not use blk backend, DomU can
boot with ramfs as rootfs. If use an image file as rootfs, DomU can not
boot.
I am not sure why this happends:"
libxl: error: libxl_create.c:1195:domcreate_launch_dm: unable to add
disk devices
libxl: error: libxl_device.c:799:libxl__initiate_device_remove: unable
to get my domid
"
By using gdb, I found domcreate_launch_dm fails to get domid, then it
reports unable to add disk devices. I am not familiar with xenstore and
etc. Did I miss some configuation?
My cfg file:"
kernel = "/home/root/xen/domu.image"
memory = "128"
name = "domU"
vcpus = 1
serial="pty"
disk = [ 'phy:/dev/loop0,xvda,w' ]
extra = "earlyprintk=xenboot console=hvc0 root=/dev/xvda debug=/bin/sh"
"
My init script when Dom0 boots up:
"
mount -t xenfs xenfs /proc/xen
export LD_LIBRARY_PATH=/usr/local/lib
echo "Starting Xenstored"
xenstored -T /root/xenstored.log
echo "Xenstored started"
echo "Starting xenconsoled"
xenconsoled -i &
echo "Xenconsoled started"
echo "Setting up loop0"
losetup /dev/loop0 DomU.image
losetup -a
echo "Writing dom0 name to xenstore"
/usr/local/bin/xenstore-write "/local/domain/0/name" "Domain-0"
echo "Done"
mkdir -p /var/log/xen
"
Detail log when creat DomU:
xen# xl -vvv create -d DomU-test
Parsing config from DomU-test
{
"domid": null,
"config": {
"c_info": {
"type": "pv",
"name": "domU",
"uuid": "67000363-4ae4-41a5-9c1f-293c1b69aa69",
"run_hotplug_scripts": "True"
},
"b_info": {
"max_vcpus": 1,
"avail_vcpus": [
0
],
"max_memkb": 131072,
"target_memkb": 131072,
"shadow_memkb": 2048,
"sched_params": {
},
"claim_mode": "True",
"kernel": "/home/root/xen/domu.image",
"cmdline": "earlyprintk=xenboot console=hvc0 root=/dev/xvda
debug=/bin/sh",
"type.pv": {
}
},
"disks": [
{
"pdev_path": "/dev/loop0",
"vdev": "xvda",
"format": "raw",
"readwrite": 1
}
],
"on_reboot": "restart"
}
}
libxl: debug: libxl_create.c:1544:do_domain_create: ao 0x42eb80: create:
how=(nil) callback=(nil) poller=0x42eb08
libxl: debug: libxl_arm.c:58:libxl__arch_domain_prepare_config:
Configure the domain
libxl: debug: libxl_arm.c:61:libxl__arch_domain_prepare_config: -
Allocate 0 SPIs
libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk
vdev=xvda spec.backend=unknown
libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend: Disk
vdev=xvda, using backend phy
libxl: debug: libxl_create.c:949:initiate_domain_create: running bootloader
libxl: debug: libxl_bootloader.c:329:libxl__bootloader_run: no
bootloader configured, using user supplied kernel
libxl: debug: libxl_event.c:652:libxl__ev_xswatch_deregister: watch
w=0x42a7cc: deregister unregistered
domainbuilder: detail: xc_dom_allocate: cmdline="earlyprintk=xenboot
console=hvc0 root=/dev/xvda debug=/bin/sh", features="(null)"
libxl: debug: libxl_dom.c:630:libxl__build_pv: pv kernel mapped 0 path
/home/root/xen/domu.image
domainbuilder: detail: xc_dom_kernel_file:
filename="/home/root/xen/domu.image"
domainbuilder: detail: xc_dom_malloc_filemap : 6116 kB
domainbuilder: detail: xc_dom_boot_xen_init: ver 4.6, caps xen-3.0-armv7l
domainbuilder: detail: xc_dom_rambase_init: RAM starts at 40000
domainbuilder: detail: xc_dom_parse_image: called
domainbuilder: detail: xc_dom_find_loader: trying multiboot-binary
loader ...
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM64)
loader ...
domainbuilder: detail: xc_dom_probe_zimage64_kernel: kernel is not an
arm64 Image
domainbuilder: detail: loader probe failed
domainbuilder: detail: xc_dom_find_loader: trying Linux zImage (ARM32)
loader ...
domainbuilder: detail: loader probe OK
domainbuilder: detail: xc_dom_parse_zimage32_kernel: called
domainbuilder: detail: xc_dom_parse_zimage32_kernel: xen-3.0-armv7l:
0x40008000 -> 0x406012f8
libxl: debug: libxl_arm.c:571:libxl__arch_domain_init_hw_description:
constructing DTB for Xen version 4.6 guest
libxl: debug: libxl_arm.c:572:libxl__arch_domain_init_hw_description: -
vGIC version: V2
libxl: debug: libxl_arm.c:333:make_memory_nodes: Creating placeholder
node /memory@40000000
libxl: debug: libxl_arm.c:333:make_memory_nodes: Creating placeholder
node /memory@200000000
libxl: debug: libxl_arm.c:647:libxl__arch_domain_init_hw_description:
fdt total size 1290
domainbuilder: detail: xc_dom_devicetree_mem: called
domainbuilder: detail: xc_dom_mem_init: mem 128 MB, pages 0x8000 pages,
4k each
domainbuilder: detail: xc_dom_mem_init: 0x8000 pages
domainbuilder: detail: xc_dom_boot_mem_init: called
domainbuilder: detail: set_mode: guest xen-3.0-armv7l, address size 32
domainbuilder: detail: xc_dom_malloc : 256 kB
domainbuilder: detail: populate_guest_memory: populating RAM @
0000000040000000-0000000048000000 (128MB)
domainbuilder: detail: populate_one_size: populated 0x40/0x40 entries
with shift 9
domainbuilder: detail: arch_setup_meminit: placing boot modules at
0x47fff000
domainbuilder: detail: arch_setup_meminit: devicetree: 0x47fff000 ->
0x48000000
libxl: debug: libxl_arm.c:678:finalise_one_memory_node: Populating
placeholder node /memory@40000000
libxl: debug: libxl_arm.c:672:finalise_one_memory_node: Nopping out
placeholder node /memory@200000000
domainbuilder: detail: xc_dom_build_image: called
domainbuilder: detail: xc_dom_alloc_segment: kernel : 0x40008000
-> 0x40602000 (pfn 0x40008 + 0x5fa pages)
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn
0x40008+0x5fa at 0x75e8e000
domainbuilder: detail: xc_dom_load_zimage_kernel: called
domainbuilder: detail: xc_dom_load_zimage_kernel: kernel seg
0x40008000-0x40602000
domainbuilder: detail: xc_dom_load_zimage_kernel: copy 6263544 bytes
from blob 0x764c9000 to dst 0x75e8e000
domainbuilder: detail: xc_dom_alloc_segment: devicetree : 0x47fff000
-> 0x48000000 (pfn 0x47fff + 0x1 pages)
domainbuilder: detail: xc_dom_pfn_to_ptr_retcount: domU mapping: pfn
0x47fff+0x1 at 0x76f13000
domainbuilder: detail: alloc_magic_pages: called
domainbuilder: detail: count_pgtables_arm: called
domainbuilder: detail: xc_dom_build_image : virt_alloc_end : 0x48000000
domainbuilder: detail: xc_dom_build_image : virt_pgtab_end : 0x0
domainbuilder: detail: xc_dom_boot_image: called
domainbuilder: detail: arch_setup_bootearly: doing nothing
domainbuilder: detail: xc_dom_compat_check: supported guest type:
xen-3.0-armv7l <= matches
domainbuilder: detail: setup_pgtables_arm: called
domainbuilder: detail: clear_page: pfn 0x39000, mfn 0x39000
domainbuilder: detail: clear_page: pfn 0x39001, mfn 0x39001
domainbuilder: detail: start_info_arm: called
domainbuilder: detail: domain builder memory footprint
domainbuilder: detail: allocated
domainbuilder: detail: malloc : 293 kB
domainbuilder: detail: anon mmap : 0 bytes
domainbuilder: detail: mapped
domainbuilder: detail: file mmap : 6116 kB
domainbuilder: detail: domU mmap : 6124 kB
domainbuilder: detail: vcpu_arm32: called
domainbuilder: detail: Initial state CPSR 0x1d3 PC 0x40008000
domainbuilder: detail: launch_vm: called, ctxt=0x76f15004
domainbuilder: detail: xc_dom_gnttab_hvm_seed: called, pfn=0x38000
domainbuilder: detail: xc_dom_release: called
libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk
vdev=xvda spec.backend=phy
libxl: debug: libxl_event.c:600:libxl__ev_xswatch_register: watch
w=0x42f330 wpath=/local/domain/0/backend/vbd/5/51712/state token=3/0:
register slotnum=3
libxl: debug: libxl_create.c:1560:do_domain_create: ao 0x42eb80:
inprogress: poller=0x42eb08, flags=i
libxl: debug: libxl_event.c:537:watchfd_callback: watch w=0x42f330
wpath=/local/domain/0/backend/vbd/5/51712/state token=3/0: event
epath=/local/domain/0/backend/vbd/5/51712/state
libxl: debug: libxl_event.c:841:devstate_watch_callback: backend
/local/domain/0/backend/vbd/5/51712/state wanted state 2 ok
libxl: debug: libxl_event.c:638:libxl__ev_xswatch_deregister: watch
w=0x42f330 wpath=/local/domain/0/backend/vbd/5/51712/state token=3/0:
deregister slotnum=3
libxl: debug: libxl_event.c:652:libxl__ev_xswatch_deregister: watch
w=0x42f330: deregister unregistered
libxl: debug: libxl_event.c:652:libxl__ev_xswatch_deregister: watch
w=0x42f378: deregister unregistered
libxl: error: libxl_create.c:1195:domcreate_launch_dm: unable to add
disk devices
libxl: error: libxl_device.c:799:libxl__initiate_device_remove: unable
to get my domid
libxl: debug: libxl_event.c:652:libxl__ev_xswatch_deregister: watch
w=0x42e548: deregister unregistered
libxl: error: libxl.c:1657:devices_destroy_cb: libxl__devices_destroy
failed for 5
libxl: debug: libxl.c:1701:devices_destroy_cb: forked pid 763 for
destroy of domain 5
libxl: debug: libxl_event.c:1768:libxl__ao_complete: ao 0x42eb80:
complete, rc=-3
libxl: debug: libxl_event.c:1740:libxl__ao__destroy: ao 0x42eb80: destroy
xc: debug: hypercall buffer: total allocations:99 total releases:99
xc: debug: hypercall buffer: current allocations:0 maximum allocations:3
xc: debug: hypercall buffer: cache current size:3
xc: debug: hypercall buffer: cache hits:89 misses:3 toobig:7
>>
>> Regards,
>>
> Thanks,
> Peng.
>
Thanks,
Peng.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Dom0 kernel panic when porting xen to new arm soc
2015-06-25 14:09 ` Peng Fan
@ 2015-06-26 16:27 ` Julien Grall
0 siblings, 0 replies; 15+ messages in thread
From: Julien Grall @ 2015-06-26 16:27 UTC (permalink / raw)
To: Peng Fan, Ian Campbell; +Cc: xen-users, Stefano Stabellini, xen-devel
On 25/06/2015 16:09, Peng Fan wrote:
> Hi Julien,
Hi,
> On 6/23/2015 9:56 PM, Peng Fan wrote:
>> Hi,
>>
>> On 6/23/2015 9:36 PM, Julien Grall wrote:
>>> Hi,
>>>
>>> On 23/06/15 14:03, Peng Fan wrote:
>>>> I did not enable LPAE for DOM0 kernel, use shor page table.
>>>> Following is the full log from uboot to kernel with DOM0 512M:
>>>
>>> Which CONFIG_VMSPLIT_* do you use? Can you try to use another one? I
>>> remembered it had some effect on the offset between physical and virtual
>>> address.
>> CONFIG_VMSPLIT_2G=y
>>
>> CONFIG_PAGE_OFFSET=0x80000000
>>
>> ok. Will try 3G:1G split.
> Later I'll reply with log info about this(Do not have log at hand).
> Still panic, maybe something wrong with gnutab configration in my side,
> I use default gnutab address/size.
Did you check that the gnttab doesn't overlap a device/RAM region of
your hardware?
I've posted a patch a week ago to find automatically a region for the
grant table [1] in DOM0 memory. It will avoid you to go through the
datasheet.
> Current I met a DomU boot issue, if do not use blk backend, DomU can
> boot with ramfs as rootfs. If use an image file as rootfs, DomU can not
> boot.
>
> I am not sure why this happends:"
> libxl: error: libxl_create.c:1195:domcreate_launch_dm: unable to add
> disk devices
> libxl: error: libxl_device.c:799:libxl__initiate_device_remove: unable
> to get my domid
> "
> By using gdb, I found domcreate_launch_dm fails to get domid, then it
> reports unable to add disk devices. I am not familiar with xenstore and
> etc. Did I miss some configuation?
The "unable to get my domid" looks like an issue with xenstore. Is
xenstored running?
Also, did you built you DOM0 kernel with CONFIG_XEN_BLKDEV_BACKEND?
Regards,
[1] http://lists.xen.org/archives/html/xen-devel/2015-06/msg02831.html
--
Julien Grall
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2015-06-26 16:27 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-18 14:09 Dom0 kernel panic when porting xen to new arm soc Peng Fan
2015-06-18 14:24 ` Julien Grall
2015-06-18 14:54 ` Ian Campbell
2015-06-19 13:22 ` Peng Fan
2015-06-20 10:19 ` Julien Grall
2015-06-20 14:08 ` Peng Fan
2015-06-20 14:47 ` Peng Fan
2015-06-22 10:20 ` Julien Grall
2015-06-22 11:17 ` Peng Fan
2015-06-22 14:02 ` Julien Grall
2015-06-23 13:03 ` Peng Fan
2015-06-23 13:36 ` Julien Grall
2015-06-23 13:56 ` Peng Fan
2015-06-25 14:09 ` Peng Fan
2015-06-26 16:27 ` Julien Grall
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).