[PATCH] crash/symbols: Error out earlier in case _stext_vmlinux is NULL or UNINITIALIZED
by Bhupesh Sharma
While running crash on KASLR enabled live arm64 kernels I noticed
that the crash would fail after printing the following error messages
if it cannot find vmlinux for the boot'ed system:
crash: invalid kernel virtual address: 8470 type: "possible"
WARNING: cannot read cpu_possible_map
crash: invalid kernel virtual address: 8270 type: "present"
WARNING: cannot read cpu_present_map
crash: invalid kernel virtual address: 8070 type: "online"
WARNING: cannot read cpu_online_map
crash: invalid kernel virtual address: 8670 type: "active"
WARNING: cannot read cpu_active_map
crash: cannot resolve "_stext"
Since vmlinux is not available at the standard expected location, i.e
'/usr/lib/debug/lib/modules/<kernel-version>' directory, so
_stext_vmlinux stays UNINITIALIZED inside 'derive_kaslr_offset()'
and 'relocate' becomes 0.
Later-on this can lead to 'cannot resolve "_stext"' error in
'symbol_value()' function.
We can go ahead and fix the same, but ideally since we are running
on a live system, we should be finding the vmlinux at the standard
location, otherwise we should do proper error handling.
So this patch errors out earlier, if we don't find a valid value for
'_stext_vmlinux' and prompts the user to refer to the 'usage'
banner.
Signed-off-by: Bhupesh Sharma <bhsharma(a)redhat.com>
---
symbols.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/symbols.c b/symbols.c
index 4db9af7bf044..30669950635d 100644
--- a/symbols.c
+++ b/symbols.c
@@ -663,6 +663,24 @@ derive_kaslr_offset(bfd *abfd, int dynamic, bfd_byte *start, bfd_byte *end,
return;
}
+ /* For KASLR enabled live kernels, if vmlinux is not available
+ * at the standard expected location, i.e
+ * '/usr/lib/debug/lib/modules/<kernel-version>' directory,
+ * then _stext_vmlinux will be set to NULL or UNINITIALIZED.
+ *
+ * Later-on this may lead to "_stext" symbol not being resolved
+ * properly (which may lead to an ambiguous error message).
+ *
+ * So, error out earlier here itself, in case _stext_vmlinux
+ * is NULL or UNINITIALIZED.
+ */
+ if (!st->_stext_vmlinux || (st->_stext_vmlinux == UNINITIALIZED)) {
+ error(INFO, "_stext not found in vmlinux :\n"
+ " if running a live system -- please provide a suitable vmlinux,\n"
+ " otherwise -- please enter namelist argument.\n");
+ program_usage(SHORT_FORM);
+ }
+
/*
* To avoid mistaking an mismatched kernel version with
* a kaslr offset, we make sure that the offset is
--
2.7.4
6 years, 4 months
- 2
- 2
Re: [Crash-utility] linux_banner has garbage
by anderson
That's fixed upstream. You'll have to download the crash sources from github and build the latest and greatest.
Dave
Sent from my Verizon, Samsung Galaxy smartphone
-------- Original message --------From: Eshak <tmdeshak(a)gmail.com> Date: 2/6/18 9:27 PM (GMT-05:00) To: "Discussion list for crash utility usage, maintenance and development" <crash-utility(a)redhat.com> Subject: Re: [Crash-utility] linux_banner has garbage
Hi Dave,
I have /proc/kcore. But I'm getting 'cannot resolve 'init_level4_pgt' error.
[root@gt-Server2-gmt proc]# crash /home/mfusion/vmem_vmss_jan26/usr/lib/debug/usr/lib/modules/4.14.11-coreos/vmlinux /proc/kcore
crash 7.1.9-3.fc27
Copyright (C) 2002-2016 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for details.
crash: /dev/tty: No such device or address
NOTE: stdin: not a tty
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu"...
WARNING: kernel relocated [496MB]: patching 69420 gdb minimal_symbol values
crash: cannot resolve "init_level4_pgt"
[root@gt-Server2-gmt proc]#
But I believe this is fixed in crash 7.2. I have raised one issue against CoreOS to make crash 7.2 to be available in toolbox packages(https://github.com/coreos/bugs/issues/2347).
Meanwhile, Is there any workaround for this ?
-Eshak
On Tue, Feb 6, 2018 at 6:02 PM, anderson <anderson(a)prospeed.net> wrote:
To run live, you need either /dev/mem, /proc/kcore, or the /dev/crash driver. You could try "crash vmlinux /proc/kcore" to see if it's available. If not, you could try building the /dev/crash driver module. But I don't know if CoreOS offers a kernel-devel package that you could build the driver against? The driver source comes with the crash source package in the memory_driver subdirectory.
Dave
Sent from my Verizon, Samsung Galaxy smartphone
-------- Original message --------From: Eshak <tmdeshak(a)gmail.com> Date: 2/6/18 8:35 PM (GMT-05:00) To: "Discussion list for crash utility usage, maintenance and development" <crash-utility(a)redhat.com> Cc: hfu <hfu(a)vmware.com> Subject: Re: [Crash-utility] linux_banner has garbage
Hi Dave,
When trying to run crash live, I'm getting an error saying that /dev/mem is not available.I'm running crash from toolbox in a CoreOS VM. Is crash designed to run from a container ?
[root@gt-Server2-gmt ~]# crash -d8 /home/user/vmem_vmss_jan26/usr/lib/debug/usr/lib/modules/4.14.11-coreos/vmlinux
crash 7.1.9-3.fc27
Copyright (C) 2002-2016 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for details.
get_live_memory_source: /dev/mem
crash: /dev/mem: No such file or directory
[root@gt-Server2-gmt ~]#
Thank you,Eshak
On Tue, Feb 6, 2018 at 3:05 PM, Eshak <tmdeshak(a)gmail.com> wrote:
Thanks for the info Dave.Unfortunately, I cannot run crash live on the machine because the VM is in hung state right now. After resetting the VM(by tomorrow), will check for KASLR and phys_base and try the suggested option.
The complete output of crash is below:
[root@gt-Server2-gmt user]# crash -d8 /home/mfusion/vmem_vmss_jan26/usr/lib/debug/usr/lib/modules/4.14.11-coreos/vmlinux /home/mfusion/vmem_vmss_jan26/usr/lib/modules/4.14.11-coreos/build/System.map /home/mfusion/vmem_vmss_jan26/gt-Server2-gmt-612746ca.vmsscrash 7.1.9-3.fc27
Copyright (C) 2002-2016 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for details.
crash: diskdump / compressed kdump: dump does not have panic dump header
crash: sadump: read dump device as media format
crash: sadump: does not have partition header
vmw: Header: id=bed2bed2 version=8 numgroups=95
vmw: Checkpoint is 64-bit
vmw: Group: Checkpoint offset=0x1dbc size=0x0x3ab.
vmw: Group: GuestVars offset=0x2167 size=0x0xa3.
vmw: Group: cpuid offset=0x220a size=0x0x5e0e.
vmw: Group: cpu offset=0x8018 size=0x0x615bb.
vmw: Group: BusMemSample offset=0x695d3 size=0x0x1c.
vmw: Group: UUIDVMX offset=0x695ef size=0x0x2e.
vmw: Group: StateLogger offset=0x6961d size=0x0x2.
vmw: Group: memory offset=0x6961f size=0x0xa8.
vmw: Item align_mask[0][0] => position=0x69633 size=0x4: 0000FFFF
vmw: Item regionsCount => position=0x69645 size=0x4: 00000002
vmw: Item regionPageNum[0] => position=0x6965c size=0x4: 00000000
vmw: Item regionPPN[0] => position=0x6966f size=0x4: 00000000
vmw: Item regionSize[0] => position=0x69683 size=0x4: 000C0000
vmw: Item regionPageNum[1] => position=0x6969a size=0x4: 000C0000
vmw: Item regionPPN[1] => position=0x696ad size=0x4: 00100000
vmw: Item regionSize[1] => position=0x696c1 size=0x4: 00E40000
vmw: Group: MStats offset=0x696c7 size=0x0x1936.
vmw: Group: Snapshot offset=0x6affd size=0x0x4b9c.
vmw: Group: pic offset=0x6fb99 size=0x0x511.
vmw: Group: FTCpt offset=0x700aa size=0x0x2.
vmw: Group: ide1:0 offset=0x700ac size=0x0x16e.
vmw: Group: scsi0:0 offset=0x7021a size=0x0x46.
vmw: Group: Migrate offset=0x70260 size=0x0x2.
vmw: Group: TimeTracker offset=0x70262 size=0x0x99.
vmw: Group: Backdoor offset=0x702fb size=0x0x2e.
vmw: Group: PCI offset=0x70329 size=0x0x13.
vmw: Group: Cs440bx offset=0x7033c size=0x0x40539.
vmw: Group: ExtCfgDevice offset=0xb0875 size=0x0x30.
vmw: Group: Floppy offset=0xb08a5 size=0x0x918c.
vmw: Group: AcpiNotify offset=0xb9a31 size=0x0x1b.
vmw: Group: vcpuHotPlug offset=0xb9a4c size=0x0xf5.
vmw: Group: devHP offset=0xb9b41 size=0x0x86.
vmw: Group: ACPIWake offset=0xb9bc7 size=0x0x1b.
vmw: Group: DevicesPowerOn offset=0xb9be2 size=0x0x2.
vmw: Group: PCIBridge0 offset=0xb9be4 size=0x0x272.
vmw: Group: PCIBridge4 offset=0xb9e56 size=0x0x48e.
vmw: Group: pciBridge4:1 offset=0xba2e4 size=0x0x48e.
vmw: Group: pciBridge4:2 offset=0xba772 size=0x0x48e.
vmw: Group: pciBridge4:3 offset=0xbac00 size=0x0x48e.
vmw: Group: pciBridge4:4 offset=0xbb08e size=0x0x48e.
vmw: Group: pciBridge4:5 offset=0xbb51c size=0x0x48e.
vmw: Group: pciBridge4:6 offset=0xbb9aa size=0x0x48e.
vmw: Group: pciBridge4:7 offset=0xbbe38 size=0x0x48e.
vmw: Group: PCIBridge5 offset=0xbc2c6 size=0x0x48e.
vmw: Group: pciBridge5:1 offset=0xbc754 size=0x0x48e.
vmw: Group: pciBridge5:2 offset=0xbcbe2 size=0x0x48e.
vmw: Group: pciBridge5:3 offset=0xbd070 size=0x0x48e.
vmw: Group: pciBridge5:4 offset=0xbd4fe size=0x0x48e.
vmw: Group: pciBridge5:5 offset=0xbd98c size=0x0x48e.
vmw: Group: pciBridge5:6 offset=0xbde1a size=0x0x48e.
vmw: Group: pciBridge5:7 offset=0xbe2a8 size=0x0x48e.
vmw: Group: PCIBridge6 offset=0xbe736 size=0x0x48e.
vmw: Group: pciBridge6:1 offset=0xbebc4 size=0x0x48e.
vmw: Group: pciBridge6:2 offset=0xbf052 size=0x0x48e.
vmw: Group: pciBridge6:3 offset=0xbf4e0 size=0x0x48e.
vmw: Group: pciBridge6:4 offset=0xbf96e size=0x0x48e.
vmw: Group: pciBridge6:5 offset=0xbfdfc size=0x0x48e.
vmw: Group: pciBridge6:6 offset=0xc028a size=0x0x48e.
vmw: Group: pciBridge6:7 offset=0xc0718 size=0x0x48e.
vmw: Group: PCIBridge7 offset=0xc0ba6 size=0x0x48e.
vmw: Group: pciBridge7:1 offset=0xc1034 size=0x0x48e.
vmw: Group: pciBridge7:2 offset=0xc14c2 size=0x0x48e.
vmw: Group: pciBridge7:3 offset=0xc1950 size=0x0x48e.
vmw: Group: pciBridge7:4 offset=0xc1dde size=0x0x48e.
vmw: Group: pciBridge7:5 offset=0xc226c size=0x0x48e.
vmw: Group: pciBridge7:6 offset=0xc26fa size=0x0x48e.
vmw: Group: pciBridge7:7 offset=0xc2b88 size=0x0x48e.
vmw: Group: vide offset=0xc3016 size=0x0x10bb7.
vmw: Group: SCSI0 offset=0xd3bcd size=0x0x1200f.
vmw: Group: VGA offset=0xe5bdc size=0x0x404aa.
vmw: Group: SVGA offset=0x126086 size=0x0xa6e6.
vmw: Group: Ethernet0 offset=0x13076c size=0x0x15312.
vmw: Group: hpet0 offset=0x145a7e size=0x0xb4a.
vmw: Group: ich7m.hpet offset=0x1465c8 size=0x0xb4a.
vmw: Group: vmci0 offset=0x147112 size=0x0x11b0.
vmw: Group: OEMDevice offset=0x1482c2 size=0x0x17.
vmw: Group: HotButton offset=0x1482d9 size=0x0x36.
vmw: Group: vsock offset=0x14830f size=0x0x33a.
vmw: Group: GuestMsg offset=0x148649 size=0x0xcf.
vmw: Group: GuestRpc offset=0x148718 size=0x0x3d2.
vmw: Group: Timer offset=0x148aea size=0x0x308.
vmw: Group: ACPI offset=0x148df2 size=0x0x3a.
vmw: Group: XPMode offset=0x148e2c size=0x0xb.
vmw: Group: Tools offset=0x148e37 size=0x0x2e.
vmw: Group: Tools Install offset=0x148e65 size=0x0x19.
vmw: Group: GuestAppMonitor offset=0x148e7e size=0x0xc3.
vmw: Group: MKSVMX offset=0x148f41 size=0x0x4cc.
vmw: Group: ToolsDeployPkg offset=0x14940d size=0x0x2.
vmw: Group: DMA offset=0x14940f size=0x0x3a4.
vmw: Group: BackdoorAPM offset=0x1497b3 size=0x0xd.
vmw: Group: CMOS offset=0x1497c0 size=0x0x27c.
vmw: Group: FlashRam offset=0x149a3c size=0x0x42058.
vmw: Group: smram offset=0x18ba94 size=0x0x2801b.
vmw: Group: A20 offset=0x1b3aaf size=0x0x10.
vmw: Group: backdoorAbsMouse offset=0x1b3abf size=0x0x13.
vmw: Group: Keyboard offset=0x1b3ad2 size=0x0x5ef.
vmw: Group: SIO offset=0x1b40c1 size=0x0x86.
vmw: Group: monitorLate offset=0x1b4147 size=0x0x2.
vmw: Group: MemoryHotplug offset=0x1b4149 size=0x0x9fd4.
vmw: Group: devices offset=0x1be11d size=0x0x3f.
vmw: Group: configdbFT offset=0x1be15c size=0x0x2.
vmw: Group: FeatureCompat offset=0x1be15e size=0x0xde3.
vmw: Group: NamespaceMgr offset=0x1bef41 size=0x0x2.
vmw: Memory dump is not part of this vmss file.
vmw: Try to locate the companion vmem file ...
vmw: vmem file: /home/mfusion/vmem_vmss_jan26/gt-mfusion2-gmt-612746ca.vmemreadmem: read_vmware_vmss()
crash: /dev/tty: No such device or address
NOTE: stdin: not a ttycrash: pv_init_ops exists: ARCH_PVOPS
gdb /home/mfusion/vmem_vmss_jan26/usr/lib/debug/usr/lib/modules/4.14.11-coreos/vmlinux
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu"...
GETBUF(280 -> 0)
GETBUF(1500 -> 1)
FREEBUF(1)
FREEBUF(0)
<readmem: ffffffff82042858, KVADDR, "page_offset_base", 8, (FOE), d24568>
<read_vmware_vmss: addr: ffffffff82042858 paddr: 2042858 cnt: 8>
<readmem: ffffffff81c18500, KVADDR, "kernel_config_data", 32768, (ROE), 25df690>
<read_vmware_vmss: addr: ffffffff81c18500 paddr: 1c18500 cnt: 2816>
<read_vmware_vmss: addr: ffffffff81c19000 paddr: 1c19000 cnt: 4096>
<read_vmware_vmss: addr: ffffffff81c1a000 paddr: 1c1a000 cnt: 4096>
<read_vmware_vmss: addr: ffffffff81c1b000 paddr: 1c1b000 cnt: 4096>
<read_vmware_vmss: addr: ffffffff81c1c000 paddr: 1c1c000 cnt: 4096>
<read_vmware_vmss: addr: ffffffff81c1d000 paddr: 1c1d000 cnt: 4096>
<read_vmware_vmss: addr: ffffffff81c1e000 paddr: 1c1e000 cnt: 4096>
<read_vmware_vmss: addr: ffffffff81c1f000 paddr: 1c1f000 cnt: 4096>
<read_vmware_vmss: addr: ffffffff81c20000 paddr: 1c20000 cnt: 1280>
WARNING: could not find MAGIC_START!
GETBUF(280 -> 0)
FREEBUF(0)
GETBUF(64 -> 0)
<readmem: ffffffff82126300, KVADDR, "possible", 64, (ROE), f64640>
<read_vmware_vmss: addr: ffffffff82126300 paddr: 2126300 cnt: 64>
cpu_possible_mask: cpus: 4 6 8 9 12 13 14 15 18 20 21 23 27 28 29 31 32 33 36 37 39 44 45 47 48 49 50 51 54 55 57 58 62 64 65 67 68 69 71 72 73 74 77 80 81 83 84 85 88 89 92 101 102 105 107 108 109 111 112 120 122 124 125 126 128 133 137 138 139 140 141 144 146 148 149 150 151 152 153 154 155 156 157 159 161 163 165 166 167 170 175 176 177 178 179 180 183 184 185 186 187 191 192 194 195 196 198 201 205 207 208 209 212 217 219 221 225 227 228 230 232 233 238 240 242 244 246 251 252 253 255 256 257 258 262 266 267 269 271 274 278 280 281 283 286 287 290 293 294 295 296 297 298 299 300 301 302 310 312 313 314 315 316 317 318 319 320 321 322 325 327 328 329 330 331 335 336 338 339 340 342 345 351 353 354 355 356 357 358 359 360 361 362 364 365 366 367 368 370 372 373 375 377 378 380 381 383 384 389 391 392 393 394 395 396 397 398 404 405 406 409 410 413 414 416 417 418 425 427 428 429 430 431 432 433 437 440 444 445 446 447 448 449 451 453 454 457 459 460 461 464 467 468 473 474 475 476 477 478 480 482 483 486 488 489 490 491 492 493 495 496 500 501 502 503 509 510 511
<readmem: ffffffff82126280, KVADDR, "present", 64, (ROE), f64640>
<read_vmware_vmss: addr: ffffffff82126280 paddr: 2126280 cnt: 64>
cpu_present_mask: cpus: 1 3 5 10 11 12 15 16 17 18 19 20 21 23 24 26 29 30 32 33 34 35 36 41 43 44 50 56 58 60 63 67 68 69 71 72 73 76 77 78 79 80 81 86 90 91 93 96 97 99 104 105 106 108 111 114 117 118 119 121 123 124 127 129 131 133 135 137 138 140 143 144 145 149 152 155 156 158 162 164 165 166 167 169 172 173 174 175 178 180 183 189 191 192 193 194 196 197 199 201 203 206 210 211 212 213 215 216 218 219 222 224 225 226 227 228 230 231 232 235 238 240 244 245 246 250 251 253 255 256 258 259 263 264 267 268 271 272 274 275 276 278 280 282 284 285 287 289 293 294 295 297 299 300 301 303 305 308 310 312 316 317 318 320 322 323 324 326 328 329 331 332 334 335 340 342 343 344 345 346 349 350 351 356 358 364 366 368 369 370 371 372 377 379 381 385 386 387 394 397 400 401 404 406 407 409 412 413 414 415 416 417 419 420 421 422 423 425 427 429 430 431 433 439 440 444 447 449 452 454 455 456 459 460 462 463 465 467 468 469 470 472 476 478 480 482 483 484 485 486 488 489 490 491 492 494 495 496 501 504 506 508 509 510 511
<readmem: ffffffff821262c0, KVADDR, "online", 64, (ROE), f64640>
<read_vmware_vmss: addr: ffffffff821262c0 paddr: 21262c0 cnt: 64>
cpu_online_mask: cpus: 0 3 4 8 10 11 12 13 15 17 21 22 27 28 29 32 33 35 44 45 46 48 49 51 52 53 54 57 58 59 62 63 65 66 67 69 72 74 75 86 87 89 90 91 96 97 99 100 101 106 107 110 111 113 115 116 117 122 123 125 128 129 130 134 135 136 142 143 145 147 149 150 153 156 157 160 161 163 164 166 167 168 173 176 179 180 184 187 189 191 192 193 198 199 201 204 205 207 208 209 212 214 215 216 217 218 221 222 224 227 228 234 235 236 239 241 242 244 245 248 250 252 253 255 256 257 262 263 265 266 267 268 271 273 275 276 277 278 279 280 288 289 291 293 295 296 297 300 304 305 306 308 310 312 313 317 318 320 325 326 327 328 329 330 331 332 333 337 338 339 342 344 346 348 349 350 352 355 356 361 368 369 375 380 381 382 383 385 387 389 390 391 394 395 397 398 399 400 401 403 405 406 408 409 410 412 415 416 417 418 422 424 427 429 430 432 434 436 438 441 443 444 451 452 456 460 462 464 466 469 473 474 476 479 480 484 487 488 489 494 498 499 500 503 504 506 509 510
<readmem: ffffffff82126240, KVADDR, "active", 64, (ROE), f64640>
<read_vmware_vmss: addr: ffffffff82126240 paddr: 2126240 cnt: 64>
cpu_active_mask: cpus: 0 1 3 4 5 8 12 13 14 15 16 19 21 23 25 27 29 37 43 45 48 51 54 55 56 57 58 59 60 61 62 63 66 67 68 70 73 75 76 78 80 81 84 86 92 94 95 96 98 99 100 103 104 105 109 110 111 114 115 122 124 126 127 128 130 134 136 137 141 142 144 146 150 152 154 158 159 161 164 168 169 170 172 174 177 178 180 181 183 189 192 195 198 202 204 207 208 212 213 214 215 216 217 222 225 227 228 229 230 233 234 235 238 239 240 242 244 247 248 250 253 255 256 258 260 267 268 270 273 274 275 276 279 280 282 286 287 294 296 300 302 303 305 308 310 311 312 313 314 315 316 317 319 320 323 325 328 330 331 333 336 337 340 341 342 344 348 349 350 351 352 353 354 355 359 363 364 366 368 370 373 374 375 379 380 382 383 385 387 388 391 397 398 400 401 402 403 408 409 410 412 414 416 417 418 420 423 430 431 439 445 446 448 449 450 451 458 459 461 463 468 469 470 471 472 474 475 477 481 483 484 486 488 490 495 496 497 500 501 503 504 505 509
FREEBUF(0)
<readmem: ffffffff82031aa0, KVADDR, "pv_init_ops", 8, (ROE), 7fffa1149090>
<read_vmware_vmss: addr: ffffffff82031aa0 paddr: 2031aa0 cnt: 8>
GETBUF(280 -> 0)
FREEBUF(0)
GETBUF(280 -> 0)
FREEBUF(0)
<readmem: ffffffff84710860, KVADDR, "shadow_timekeeper xtime_sec", 8, (ROE), 7fffa1149030>
<read_vmware_vmss: addr: ffffffff84710860 paddr: 4710860 cnt: 8>
xtime timespec.tv_sec: 54d151d0619456fc: (null)
<readmem: ffffffff82012304, KVADDR, "init_uts_ns", 390, (ROE), d0a7fc>
<read_vmware_vmss: addr: ffffffff82012304 paddr: 2012304 cnt: 390>
utsname:
sysname: (not printable)
nodename: (not printable)
release: (not printable)
version: (not printable)
machine: (not printable)
domainname: (not printable)
crash: cannot determine base kernel version
<readmem: ffffffff81c00100, KVADDR, "accessible check", 8, (ROE|Q), 7fffa1146390>
<read_vmware_vmss: addr: ffffffff81c00100 paddr: 1c00100 cnt: 8>
<readmem: ffffffff81c00100, KVADDR, "read_string characters", 1499, (ROE|Q), 7fffa11466f0>
<read_vmware_vmss: addr: ffffffff81c00100 paddr: 1c00100 cnt: 1499>
linux_banner:
-ش????kB??C???Ã͞}&k?Xb?8/?ν?fF??&v;?Š???? ??
crash: /home/user/vmem_vmss_jan26/usr/lib/modules/4.14.11-coreos/build/System.map and /home/mfusion/vmem_vmss_jan26/gt-Server2-gmt-612746ca.vmss do not match!Usage:crash [OPTION]... NAMELIST MEMORY-IMAGE[@ADDRESS] (dumpfile form)
crash [OPTION]... [NAMELIST] (live system form)Enter "crash -h" for details.
[root@gt-Server2-gmt user]# Please let me know if you need any further information.Will get back to you after checking KASLR and phys_base.
Thank you,Eshak
On Tue, Feb 6, 2018 at 7:26 AM, Dave Anderson <anderson(a)redhat.com> wrote:
----- Original Message -----
>
>
> ----- Original Message -----
> > Hello,
> >
> > We have a CoreOS VM(46 vCPU, 60GB RAM) freeze issue and hoping to find out
> > what is going on in it at the time of freeze. When the VM froze, we have no
> > access to it via ssh and ping works sometimes but not always. So, we
> > suspended the VM which created vmem and vmss files.
> >
> > Since this is a CoreOS VM, I have used toolbox to install and run crash.
> > When trying to read these files using crash utility, I'm getting the below
> > message:
> >
> >
> >
> > <read_vmware_vmss: addr: ffffffff81c00100 paddr: 1c00100 cnt: 8>
> >
> > <readmem: ffffffff81c00100, KVADDR, "read_string characters", 1499,
> > (ROE|Q),
> > 7ffcf595cd70>
> >
> > <read_vmware_vmss: addr: ffffffff81c00100 paddr: 1c00100 cnt: 1499>
> >
> > linux_banner:
> >
> > -ش????kB??C???Ã͞}&k?Xb?8/?ν?fF??&v;?Š???? ??
>
> It would have been helpful to see the full crash -d# log, but I'm presuming
> that the utsname data and the cpus_[possible/present/online/active]_mask
> output
> that gets displayed just before the linux_banner output are also nonsensical?
>
> Typically this kind of problem is because phys_base cannot be determined,
> or if KASLR is enabled, the KASLR offset cannot be determined. Those two
> items are encoded into the dumpfile header for kdump dumpfiles, but there
> is no such information in a vmms dumpfile header.
>
> Can you run crash live on the machine? You can see whether the phys_base
> and KASLR offset are non-zero on the live system by entering:
>
> crash> help -m | grep phys_base
> phys_base: 129800000
> crash> help -k | grep relocate
> relocate: ffffffffcf400000 (KASLR offset: 30c00000 / 780MB)
> crash>
>
> If relocate is 0 (KASLR not enabled), then the phys_base value can
> be applied to your vmcore by entering, for example, "--machdep
> phys_base=780m"
> on the crash command line (using your phys_base).
Sorry, my mistake -- it would be "--machdep phys_base=129800000".
Dave
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
6 years, 4 months
- 3
- 10
[PATCH] arm64: fix page size calculation
by AKASHI Takahiro
As for v4.16-rc1, crash for arm64 fails to analyze the core dump,
with a message: cannot determine page size.
There seems to be a couple of reasons for this:
[1] splits a 64-bit field of image header, _kernel_flags_le, into two
32-bit values and in turn they have got a bit different names.
[2] and more recent [3] can possibly add extra space between idmap_pg_dir
and swapper_pg_dir.
This patch addresses both of changes.
[1] commit 6ad1fe5d9077 ("arm64: avoid R_AARCH64_ABS64 relocations for
Image header fields")
[2] commit 1e1b8c04fa34 ("arm64: entry: Move the trampoline to be before PAN")
[3] commit 4b65a5db3627 ("arm64: Introduce uaccess_{disable,enable}
functionality based on TTBR0_EL1")
Signed-off-by: AKASHI Takahiro <takahiro.akashi(a)linaro.org>
---
arm64.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/arm64.c b/arm64.c
index 7904f65..7f87d5b 100644
--- a/arm64.c
+++ b/arm64.c
@@ -172,8 +172,14 @@ arm64_init(int when)
if (!machdep->pagesize &&
kernel_symbol_exists("swapper_pg_dir") &&
kernel_symbol_exists("idmap_pg_dir")) {
- value = symbol_value("swapper_pg_dir") -
- symbol_value("idmap_pg_dir");
+ if (kernel_symbol_exists("tramp_pg_dir"))
+ value = symbol_value("tramp_pg_dir");
+ else if (kernel_symbol_exists("reserved_ttbr0"))
+ value = symbol_value("reserved_ttbr0");
+ else
+ value = symbol_value("swapper_pg_dir");
+
+ value -= symbol_value("idmap_pg_dir");
/*
* idmap_pg_dir is 2 pages prior to 4.1,
* and 3 pages thereafter. Only 4K and 64K
@@ -436,6 +442,12 @@ arm64_verify_symbol(const char *name, ulong value, char type)
if ((type == 'A') && STREQ(name, "_kernel_flags_le"))
machdep->machspec->kernel_flags = le64toh(value);
+ if ((type == 'A') && STREQ(name, "_kernel_flags_le_hi32"))
+ machdep->machspec->kernel_flags |= (le32toh(value) << 32);
+
+ if ((type == 'A') && STREQ(name, "_kernel_flags_le_lo32"))
+ machdep->machspec->kernel_flags |= le32toh(value);
+
if (((type == 'A') || (type == 'a')) && (highest_bit_long(value) != 63))
return FALSE;
--
2.15.1
6 years, 4 months
- 2
- 1
[ANNOUNCE] crash version 7.2.1 is available
by Dave Anderson
Download from: http://people.redhat.com/anderson
or
https://github.com/crash-utility/crash/releases
The github master branch serves as a development branch that will contain
all patches that are queued for the next release:
$ git clone git://github.com/crash-utility/crash.git
Changelog:
- Fix for the "runq" command on Linux 4.14 and later kernels that
contain commit cd9e61ed1eebbcd5dfad59475d41ec58d9b64b6a, titled
"rbtree: cache leftmost node internally". Without the patch,
the command fails with the error message "runq: invalid structure
member offset: cfs_rq_rb_leftmost".
(anderson(a)redhat.com)
- Fix to prevent a useless message during session inialization.
Without the patch, if the highest possible node bit in the
node_states[N_ONLINE] multi-word bitmask is set, then a message
such as "crash: next_online_node: 256 is too large!" will be
displayed.
(anderson(a)redhat.com)
- Additional fixes for the ARM64 "bt" command for Linux 4.14 kernels.
The patch corrects the contents of in-kernel exception frame register
dumps, and properly transitions the backtrace from the IRQ stack
to the process stack.
(takahiro.akashi(a)linaro.org)
- Implemented a new "search -T" option, which is identical to the
"search -t" option, except that the search is restricted to the
kernel stacks of active tasks.
(atomlin(a)redhat.com)
- Removal of the ARM64 "bt -o" option for Linux 4.14 and later kernels,
along with several cleanups/readability improvements.
(takahiro.akashi(a)linaro.org)
- Fix for support of KASLR enabled kernels captured by the SADUMP
dumpfile facility. SADUMP dumpfile headers do not contain phys_base
or VMCOREINFO notes, so without this patch, the crash session fails
during initialization with the message "crash: seek error: kernel
virtual address: <address> type: "page_offset_base". This patch
calculates the phys_base value and the KASLR offset using the IDTR
and CR3 registers from the dumpfile header.
(indou.takao(a)jp.fujitsu.com)
- Implemented a new "ps -y policy" option to filter the task display
by scheduling policy. Applicable to both standalone ps invocation
as well as via foreach.
(oleksandr(a)redhat.com)
- Fix for the "kmem -[sS]" options on Linux 4.14 and later kernels that
contain commit 2482ddec670fb83717d129012bc558777cb159f7, titled
"mm: add SLUB free list pointer obfuscation". Without the patch,
there will numerous error messages of the type "kmem: <cache name>
slab: <address> invalid freepointer: <obfuscated address>" if
the kernel is configured with CONFIG_SLAB_FREELIST_HARDENED.
(anderson(a)redhat.com)
- Fix for the validation of the bits located in the least signficant
bits of mem_section.section_mem_map pointers. Without the patch,
the validation functions always returned valid, due to a coding
error found by clang. However, it was never really a problem
because it is extremely unlikely that an existing mem_section would
ever be invalid.
(oleksandr(a)redhat.com, anderson(a)redhat.com)
- Fix for the x86_64 kernel virtual address to physical address
translation mechanism. Without the patch, when verifying that the
PAGE_PRESENT bit is set in the top-level page table, it would always
test positively, and the translation would continue parsing the
remainder of the page tables. This would virtually never be a
problem in practice because if the top-level page table entry
existed, its PAGE_PRESENT bit would be set.
(oleksandr(a)redhat.com, anderson(a)redhat.com)
- Removed a check for a negative block_size value which is always a
non-negative unsigned value in the SADUMP header parsing function.
(oleksandr(a)redhat.com)
- Removed a check for an impossible negative value when calculating
the beginning address when applying the context value specified by
the "search -x <count>" option.
(oleksandr(a)redhat.com)
- Implemented a new "timer -C <cpu-specifier>" option that restricts
the timer or hrtimer output to the timer queue data associated with
one or more cpus. For multiple cpus, the cpu-specifier uses the
standard comma or dash separated list format.
(oleksandr(a)redhat.com)
- Fix for a "ps -l" regression introduced by the new "ps -y" option
introduced above. Without the patch, the -l option generates a
segmentation violation if not accompanied by a -C cpu specifier
option.
(vinayakm.list(a)gmail.com)
- Fix for the "kmem -i" and "kmem -V" options in Linux 4.8 and later
kernels containing commit 75ef7184053989118d3814c558a9af62e7376a58,
titled "mm, vmstat: add infrastructure for per-node vmstats".
Without the patch, the CACHED line of "kmem -i" shows 0, and the
VM_STAT section of "kmem -V" is missing entirely.
(vinayakm.list(a)gmail.com)
- Fix for Linux 4.11 and later kernels that contain kernel commit
4b3ef9daa4fc0bba742a79faecb17fdaaead083b, titled "mm/swap: split
swap cache into 64MB trunks". Without the patch, the CACHED line
of "kmem -i" may show nonsensical data.
(vinayakm.list(a)gmail.com)
- Implemented a new "dev -D" option that is the same as "dev -d", but
filters out the display of disks that have no I/O in progress.
(oleksandr(a)redhat.com)
- If a line number request for a module text address initially fails,
force the embedded gdb module to complete its two-stage strategy
used for reading debuginfo symbol tables from module object files,
and then retry the line number extraction. This automatically does
what the "mod -r" or "crash --readnow" options accomplish.
(anderson(a)redhat.com)
- Update for support of Linux 4.12 and later PPC64 kernels where the
hash page table geometry accomodates a larger virtual address range.
Without the patch, the virtual-to-physical translation of user space
virtual addresses by "vm -p", "vtop", and "rd -u" may generate an
invalid translation or otherwise fail.
(hbathini(a)linux.vnet.ibm.com)
- Implemented a new "runq -T" option that displays the time lag of each
CPU relative to the most recent runqueue timestamp.
(oleksandr(a)redhat.com)
- Fix to support Linux 4.15 and later kernels that contain kernel
commit e8cfbc245e24887e3c30235f71e9e9405e0cfc39, titled "pid: remove
pidhash". The kernel's traditional usage of a pid_hash[] array to
store PIDs has been replaced by an IDR radix tree, requiring a new
crash plug-in function to gather the system's task set. Without the
patch, the crash session fails during initialization with the error
message "crash: cannot resolve init_task_union".
(anderson(a)redhat.com)
- Fix for the "net" command when the network device listing has an
unusually large number of IP addresses. In that case, without the
patch, the command may generate a segmentation violation.
(k-hagio(a)ab.jp.nec.com)
- Fix for Linux 4.15 and later kernels that are configured with
CONFIG_SPARSEMEM_EXTREME, and that contain kernel commit
83e3c48729d9ebb7af5a31a504f3fd6aff0348c4, titled "mm/sparsemem:
Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y".
Without the patch, kernels configured with SPARSEMEM_EXTREME
have changed the data type of "mem_section" from an array to
a pointer, leading to errors in commands such as "kmem -p",
"kmem -n", "kmem -s", and any other command that translates a
physical address to its page struct address.
(anderson(a)redhat.com)
- With the latest PPC64 NMI IPI changes, crash_ipi_callback is found
multiple times on the stack of active non-panic tasks. Ensure that
the symbol reference relates to an actual backtrace stack frame.
(hbathini(a)linux.vnet.ibm.com)
- Update the starting virtual address of vmalloc space for kernels
configured with CONFIG_X86_5LEVEL.
(douly.fnst(a)cn.fujitsu.com)
- Update the X86_64 VSYSCALL_END address to reflect that it only
contains 1 page.
(douly.fnst(a)cn.fujitsu.com)
- Prevent the X86_64 FILL_PML() macro from updating the internal
machdep->machspec->last_pml4_read address every time a vmalloc'd
kernel virtual address is translated.
(douly.fnst(a)cn.fujitsu.com)
- Fix for the "bt" command in x86_64 kernels that contain, or have
backports of, kernel commit 4950d6d48a0c43cc61d0bbb76fb10e0214b79c66,
titled "x86/dumpstack: Remove 64-byte gap at end of irq stack".
Without the patch, backtraces fail to transition from the IRQ stack
back to the process stack, showing an error message such as
"bt: cannot transition exception stack to IRQ stack to current
process stack".
(anderson(a)redhat.com)
- Initial pass for support of kernel page table isolation. The x86_64
"bt" command may indicate "bt: cannot transition from exception stack
to current process stack" if the crash callback NMI occurred while an
active task was running on the new entry trampoline stack. This has
only been tested on the RHEL7 backport of the upstream patch because
as of this commit, crash does not run on 4.15-rc kernels. Further
changes may be required for upstream kernels, and distributions that
implement the kernel changes differently than upstream.
(anderson(a)redhat.com)
- Fix for the "bt" command and the "ps -s" option for zombie tasks
whose kernel stacks have been freed/detached. Without the patch,
the "bt" command indicates "bt: invalid kernel virtual address: 0
type: stack contents" and "bt: read of stack at 0 failed"; it will
be changed to display "(no stack)". The "ps -s" option would fail
prematurely upon reaching such a task, indicating "ps: invalid kernel
virtual address: 0 type: stack contents" and "ps: read of stack at 0
failed".
(anderson(a)redhat.com)
- Fix for running on live systems on 4.15-rc2 and later kernels that
are configured with CONFIG_RANDOMIZE_BASE and contain kernel commit
668533dc0764b30c9dd2baf3ca800156f688326b, titled "kallsyms: take
advantage of the new '%px' format". Without the patch, a live crash
session does not show the "WARNING: kernel relocated ..." message
expected with KASLR, and then displays the message "crash: cannot set
context for pid: <pid>" prior to generating a SIGSEGV.
(anderson(a)redhat.com)
- Fix for 4.15-rc5 and later x86_64 kernels that contain kernel commit
c482feefe1aeb150156248ba0fd3e029bc886605, titled "x86/entry/64: Make
cpu_entry_area.tss read-only". Without the patch, the addresses and
sizes of the x86_64 exception stacks cannot be determined; therefore
if a backtrace starts on one of the exception stacks, then the "bt"
command will fail.
(anderson(a)redhat.com)
- Additional fix for support of KASLR enabled kernels captured by the
SADUMP dumpfile facility, where this patch fixes a problem when Page
Table Isolation(PTI) is enabled. When PTI is enabled, bit 12 of CR3
register is used to split user space and kernel space. Also bit 11:0
is used for Process Context IDentifiers(PCID). To open an SADUMP
dumpfile, the value of CR3 is used to calculate KASLR offset and
phys_base; this patch masks the CR3 register value correctly for
a PTI enabled kernel.
(indou.takao(a)jp.fujitsu.com)
- Second phase of future support for x86_64 5-level page tables. This
patch is a cleanup/collaboration of the original logic used by the
various vtop functions, where several new common functions have been
added for extracting page table entries from PGD, P4D, PUD, PMD and
PTE pages. The usage of the former PML4 and UPML pages have been
replaced with the use of the common PGD page, and use the PUD page
in 4-level page table translation. Support for 5-level page tables
has been incorporated into the the existing x86_64_kvtop() and
x86_64_uvtop_level4() functions. Backwards compatibility for older
legacy kernels has been maintained. The third phase of support will
automatically detect whether the kernel proper, and whether an
individual user task, is utilizing 5-level page tables. This patch
enables support for kernel-only 5-level page tables by entering the
command line option "--machdep vm=5level".
(douly.fnst(a)cn.fujitsu.com)
- Xen commit 615588563e99a23aaf37037c3fee0c413b051f4d (Xen 4.0.0.)
extended the direct mapping to 5 TB. This area was previously
reserved for future use, so it is OK to simply change the upper
bound unconditionally.
(ptesarik(a)suse.com)
- Add a new "foreach gleader" qualifier option, restricting the output
to user-space tasks that are thread group leaders.
(Jan.Karlsson(a)sony.com)
- Since Xen commit 666aca08175b ("sched: use the auto-generated list of
schedulers") crash cannot open Xen vmcores because the "schedulers"
symbol no longer exists. Xen 4.7 implemented schedulers as its own
section in "xen/arch/x86/xen.lds.S", delimited by the two symbols
"__start_schedulers_array" and "__end_schedulers_array". Without
the patch, the crash session fails during initialization with the
error message "crash: cannot resolve schedulers"
(npajkovsky(a)suse.cz)
- Fix the sample crash.ko memory driver to prevent an s390X kernel
addressing exception. Legitimate pages of RAM that successfully
pass the page_is_ram() and pfn_valid() verifier functions may not
be provided by the s390x hypervisor, and the memcpy() from the
non-existent memory to the bounce buffer panics the kernel. The
patch replaces the the memcpy() call with probe_kernel_read().
(anderson(a)redhat.com)
- Fix for the ARM64 "bt" command running against Linux 4.14 and
later kernels. Without the patch, the backtraces of the active
tasks in a kdump-generated dumpfile are truncated. Without the
patch, the panic task will just show the "crash_kexec" frame
and the kernel-entry user-space exception frame; the non-panic
tasks will show their backtraces starting from the stackframe
addresses captured in the per-cpu NT_PRSTATUS notes, and will
not display the exception frame generated by the NMI callback,
nor any stackframes on the IRQ stack.
(anderson(a)redhat.com)
- Fix for the ARM64 "bt" command in kernels that contain commit
30d88c0e3ace625a92eead9ca0ad94093a8f59fe, titled "arm64: entry:
Apply BP hardening for suspicious interrupts from EL0". Without
the patch, there may be invalid kernel kernel exception frames
displayed on an active task's kernel stack, often below a stackframe
of the "do_el0_ia_bp_hardening" function; the address translation
of the PC and LR values in the the bogus exception frame will
display "[unknown or invalid address]".
(anderson(a)redhat.com)
6 years, 4 months
- 1
- 0
Re: [Crash-utility] linux_banner has garbage
by anderson
To run live, you need either /dev/mem, /proc/kcore, or the /dev/crash driver. You could try "crash vmlinux /proc/kcore" to see if it's available. If not, you could try building the /dev/crash driver module. But I don't know if CoreOS offers a kernel-devel package that you could build the driver against? The driver source comes with the crash source package in the memory_driver subdirectory.
Dave
Sent from my Verizon, Samsung Galaxy smartphone
-------- Original message --------From: Eshak <tmdeshak(a)gmail.com> Date: 2/6/18 8:35 PM (GMT-05:00) To: "Discussion list for crash utility usage, maintenance and development" <crash-utility(a)redhat.com> Cc: hfu <hfu(a)vmware.com> Subject: Re: [Crash-utility] linux_banner has garbage
Hi Dave,
When trying to run crash live, I'm getting an error saying that /dev/mem is not available.I'm running crash from toolbox in a CoreOS VM. Is crash designed to run from a container ?
[root@gt-Server2-gmt ~]# crash -d8 /home/user/vmem_vmss_jan26/usr/lib/debug/usr/lib/modules/4.14.11-coreos/vmlinux
crash 7.1.9-3.fc27
Copyright (C) 2002-2016 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for details.
get_live_memory_source: /dev/mem
crash: /dev/mem: No such file or directory
[root@gt-Server2-gmt ~]#
Thank you,Eshak
On Tue, Feb 6, 2018 at 3:05 PM, Eshak <tmdeshak(a)gmail.com> wrote:
Thanks for the info Dave.Unfortunately, I cannot run crash live on the machine because the VM is in hung state right now. After resetting the VM(by tomorrow), will check for KASLR and phys_base and try the suggested option.
The complete output of crash is below:
[root@gt-Server2-gmt user]# crash -d8 /home/mfusion/vmem_vmss_jan26/usr/lib/debug/usr/lib/modules/4.14.11-coreos/vmlinux /home/mfusion/vmem_vmss_jan26/usr/lib/modules/4.14.11-coreos/build/System.map /home/mfusion/vmem_vmss_jan26/gt-Server2-gmt-612746ca.vmsscrash 7.1.9-3.fc27
Copyright (C) 2002-2016 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for details.
crash: diskdump / compressed kdump: dump does not have panic dump header
crash: sadump: read dump device as media format
crash: sadump: does not have partition header
vmw: Header: id=bed2bed2 version=8 numgroups=95
vmw: Checkpoint is 64-bit
vmw: Group: Checkpoint offset=0x1dbc size=0x0x3ab.
vmw: Group: GuestVars offset=0x2167 size=0x0xa3.
vmw: Group: cpuid offset=0x220a size=0x0x5e0e.
vmw: Group: cpu offset=0x8018 size=0x0x615bb.
vmw: Group: BusMemSample offset=0x695d3 size=0x0x1c.
vmw: Group: UUIDVMX offset=0x695ef size=0x0x2e.
vmw: Group: StateLogger offset=0x6961d size=0x0x2.
vmw: Group: memory offset=0x6961f size=0x0xa8.
vmw: Item align_mask[0][0] => position=0x69633 size=0x4: 0000FFFF
vmw: Item regionsCount => position=0x69645 size=0x4: 00000002
vmw: Item regionPageNum[0] => position=0x6965c size=0x4: 00000000
vmw: Item regionPPN[0] => position=0x6966f size=0x4: 00000000
vmw: Item regionSize[0] => position=0x69683 size=0x4: 000C0000
vmw: Item regionPageNum[1] => position=0x6969a size=0x4: 000C0000
vmw: Item regionPPN[1] => position=0x696ad size=0x4: 00100000
vmw: Item regionSize[1] => position=0x696c1 size=0x4: 00E40000
vmw: Group: MStats offset=0x696c7 size=0x0x1936.
vmw: Group: Snapshot offset=0x6affd size=0x0x4b9c.
vmw: Group: pic offset=0x6fb99 size=0x0x511.
vmw: Group: FTCpt offset=0x700aa size=0x0x2.
vmw: Group: ide1:0 offset=0x700ac size=0x0x16e.
vmw: Group: scsi0:0 offset=0x7021a size=0x0x46.
vmw: Group: Migrate offset=0x70260 size=0x0x2.
vmw: Group: TimeTracker offset=0x70262 size=0x0x99.
vmw: Group: Backdoor offset=0x702fb size=0x0x2e.
vmw: Group: PCI offset=0x70329 size=0x0x13.
vmw: Group: Cs440bx offset=0x7033c size=0x0x40539.
vmw: Group: ExtCfgDevice offset=0xb0875 size=0x0x30.
vmw: Group: Floppy offset=0xb08a5 size=0x0x918c.
vmw: Group: AcpiNotify offset=0xb9a31 size=0x0x1b.
vmw: Group: vcpuHotPlug offset=0xb9a4c size=0x0xf5.
vmw: Group: devHP offset=0xb9b41 size=0x0x86.
vmw: Group: ACPIWake offset=0xb9bc7 size=0x0x1b.
vmw: Group: DevicesPowerOn offset=0xb9be2 size=0x0x2.
vmw: Group: PCIBridge0 offset=0xb9be4 size=0x0x272.
vmw: Group: PCIBridge4 offset=0xb9e56 size=0x0x48e.
vmw: Group: pciBridge4:1 offset=0xba2e4 size=0x0x48e.
vmw: Group: pciBridge4:2 offset=0xba772 size=0x0x48e.
vmw: Group: pciBridge4:3 offset=0xbac00 size=0x0x48e.
vmw: Group: pciBridge4:4 offset=0xbb08e size=0x0x48e.
vmw: Group: pciBridge4:5 offset=0xbb51c size=0x0x48e.
vmw: Group: pciBridge4:6 offset=0xbb9aa size=0x0x48e.
vmw: Group: pciBridge4:7 offset=0xbbe38 size=0x0x48e.
vmw: Group: PCIBridge5 offset=0xbc2c6 size=0x0x48e.
vmw: Group: pciBridge5:1 offset=0xbc754 size=0x0x48e.
vmw: Group: pciBridge5:2 offset=0xbcbe2 size=0x0x48e.
vmw: Group: pciBridge5:3 offset=0xbd070 size=0x0x48e.
vmw: Group: pciBridge5:4 offset=0xbd4fe size=0x0x48e.
vmw: Group: pciBridge5:5 offset=0xbd98c size=0x0x48e.
vmw: Group: pciBridge5:6 offset=0xbde1a size=0x0x48e.
vmw: Group: pciBridge5:7 offset=0xbe2a8 size=0x0x48e.
vmw: Group: PCIBridge6 offset=0xbe736 size=0x0x48e.
vmw: Group: pciBridge6:1 offset=0xbebc4 size=0x0x48e.
vmw: Group: pciBridge6:2 offset=0xbf052 size=0x0x48e.
vmw: Group: pciBridge6:3 offset=0xbf4e0 size=0x0x48e.
vmw: Group: pciBridge6:4 offset=0xbf96e size=0x0x48e.
vmw: Group: pciBridge6:5 offset=0xbfdfc size=0x0x48e.
vmw: Group: pciBridge6:6 offset=0xc028a size=0x0x48e.
vmw: Group: pciBridge6:7 offset=0xc0718 size=0x0x48e.
vmw: Group: PCIBridge7 offset=0xc0ba6 size=0x0x48e.
vmw: Group: pciBridge7:1 offset=0xc1034 size=0x0x48e.
vmw: Group: pciBridge7:2 offset=0xc14c2 size=0x0x48e.
vmw: Group: pciBridge7:3 offset=0xc1950 size=0x0x48e.
vmw: Group: pciBridge7:4 offset=0xc1dde size=0x0x48e.
vmw: Group: pciBridge7:5 offset=0xc226c size=0x0x48e.
vmw: Group: pciBridge7:6 offset=0xc26fa size=0x0x48e.
vmw: Group: pciBridge7:7 offset=0xc2b88 size=0x0x48e.
vmw: Group: vide offset=0xc3016 size=0x0x10bb7.
vmw: Group: SCSI0 offset=0xd3bcd size=0x0x1200f.
vmw: Group: VGA offset=0xe5bdc size=0x0x404aa.
vmw: Group: SVGA offset=0x126086 size=0x0xa6e6.
vmw: Group: Ethernet0 offset=0x13076c size=0x0x15312.
vmw: Group: hpet0 offset=0x145a7e size=0x0xb4a.
vmw: Group: ich7m.hpet offset=0x1465c8 size=0x0xb4a.
vmw: Group: vmci0 offset=0x147112 size=0x0x11b0.
vmw: Group: OEMDevice offset=0x1482c2 size=0x0x17.
vmw: Group: HotButton offset=0x1482d9 size=0x0x36.
vmw: Group: vsock offset=0x14830f size=0x0x33a.
vmw: Group: GuestMsg offset=0x148649 size=0x0xcf.
vmw: Group: GuestRpc offset=0x148718 size=0x0x3d2.
vmw: Group: Timer offset=0x148aea size=0x0x308.
vmw: Group: ACPI offset=0x148df2 size=0x0x3a.
vmw: Group: XPMode offset=0x148e2c size=0x0xb.
vmw: Group: Tools offset=0x148e37 size=0x0x2e.
vmw: Group: Tools Install offset=0x148e65 size=0x0x19.
vmw: Group: GuestAppMonitor offset=0x148e7e size=0x0xc3.
vmw: Group: MKSVMX offset=0x148f41 size=0x0x4cc.
vmw: Group: ToolsDeployPkg offset=0x14940d size=0x0x2.
vmw: Group: DMA offset=0x14940f size=0x0x3a4.
vmw: Group: BackdoorAPM offset=0x1497b3 size=0x0xd.
vmw: Group: CMOS offset=0x1497c0 size=0x0x27c.
vmw: Group: FlashRam offset=0x149a3c size=0x0x42058.
vmw: Group: smram offset=0x18ba94 size=0x0x2801b.
vmw: Group: A20 offset=0x1b3aaf size=0x0x10.
vmw: Group: backdoorAbsMouse offset=0x1b3abf size=0x0x13.
vmw: Group: Keyboard offset=0x1b3ad2 size=0x0x5ef.
vmw: Group: SIO offset=0x1b40c1 size=0x0x86.
vmw: Group: monitorLate offset=0x1b4147 size=0x0x2.
vmw: Group: MemoryHotplug offset=0x1b4149 size=0x0x9fd4.
vmw: Group: devices offset=0x1be11d size=0x0x3f.
vmw: Group: configdbFT offset=0x1be15c size=0x0x2.
vmw: Group: FeatureCompat offset=0x1be15e size=0x0xde3.
vmw: Group: NamespaceMgr offset=0x1bef41 size=0x0x2.
vmw: Memory dump is not part of this vmss file.
vmw: Try to locate the companion vmem file ...
vmw: vmem file: /home/mfusion/vmem_vmss_jan26/gt-mfusion2-gmt-612746ca.vmemreadmem: read_vmware_vmss()
crash: /dev/tty: No such device or address
NOTE: stdin: not a ttycrash: pv_init_ops exists: ARCH_PVOPS
gdb /home/mfusion/vmem_vmss_jan26/usr/lib/debug/usr/lib/modules/4.14.11-coreos/vmlinux
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu"...
GETBUF(280 -> 0)
GETBUF(1500 -> 1)
FREEBUF(1)
FREEBUF(0)
<readmem: ffffffff82042858, KVADDR, "page_offset_base", 8, (FOE), d24568>
<read_vmware_vmss: addr: ffffffff82042858 paddr: 2042858 cnt: 8>
<readmem: ffffffff81c18500, KVADDR, "kernel_config_data", 32768, (ROE), 25df690>
<read_vmware_vmss: addr: ffffffff81c18500 paddr: 1c18500 cnt: 2816>
<read_vmware_vmss: addr: ffffffff81c19000 paddr: 1c19000 cnt: 4096>
<read_vmware_vmss: addr: ffffffff81c1a000 paddr: 1c1a000 cnt: 4096>
<read_vmware_vmss: addr: ffffffff81c1b000 paddr: 1c1b000 cnt: 4096>
<read_vmware_vmss: addr: ffffffff81c1c000 paddr: 1c1c000 cnt: 4096>
<read_vmware_vmss: addr: ffffffff81c1d000 paddr: 1c1d000 cnt: 4096>
<read_vmware_vmss: addr: ffffffff81c1e000 paddr: 1c1e000 cnt: 4096>
<read_vmware_vmss: addr: ffffffff81c1f000 paddr: 1c1f000 cnt: 4096>
<read_vmware_vmss: addr: ffffffff81c20000 paddr: 1c20000 cnt: 1280>
WARNING: could not find MAGIC_START!
GETBUF(280 -> 0)
FREEBUF(0)
GETBUF(64 -> 0)
<readmem: ffffffff82126300, KVADDR, "possible", 64, (ROE), f64640>
<read_vmware_vmss: addr: ffffffff82126300 paddr: 2126300 cnt: 64>
cpu_possible_mask: cpus: 4 6 8 9 12 13 14 15 18 20 21 23 27 28 29 31 32 33 36 37 39 44 45 47 48 49 50 51 54 55 57 58 62 64 65 67 68 69 71 72 73 74 77 80 81 83 84 85 88 89 92 101 102 105 107 108 109 111 112 120 122 124 125 126 128 133 137 138 139 140 141 144 146 148 149 150 151 152 153 154 155 156 157 159 161 163 165 166 167 170 175 176 177 178 179 180 183 184 185 186 187 191 192 194 195 196 198 201 205 207 208 209 212 217 219 221 225 227 228 230 232 233 238 240 242 244 246 251 252 253 255 256 257 258 262 266 267 269 271 274 278 280 281 283 286 287 290 293 294 295 296 297 298 299 300 301 302 310 312 313 314 315 316 317 318 319 320 321 322 325 327 328 329 330 331 335 336 338 339 340 342 345 351 353 354 355 356 357 358 359 360 361 362 364 365 366 367 368 370 372 373 375 377 378 380 381 383 384 389 391 392 393 394 395 396 397 398 404 405 406 409 410 413 414 416 417 418 425 427 428 429 430 431 432 433 437 440 444 445 446 447 448 449 451 453 454 457 459 460 461 464 467 468 473 474 475 476 477 478 480 482 483 486 488 489 490 491 492 493 495 496 500 501 502 503 509 510 511
<readmem: ffffffff82126280, KVADDR, "present", 64, (ROE), f64640>
<read_vmware_vmss: addr: ffffffff82126280 paddr: 2126280 cnt: 64>
cpu_present_mask: cpus: 1 3 5 10 11 12 15 16 17 18 19 20 21 23 24 26 29 30 32 33 34 35 36 41 43 44 50 56 58 60 63 67 68 69 71 72 73 76 77 78 79 80 81 86 90 91 93 96 97 99 104 105 106 108 111 114 117 118 119 121 123 124 127 129 131 133 135 137 138 140 143 144 145 149 152 155 156 158 162 164 165 166 167 169 172 173 174 175 178 180 183 189 191 192 193 194 196 197 199 201 203 206 210 211 212 213 215 216 218 219 222 224 225 226 227 228 230 231 232 235 238 240 244 245 246 250 251 253 255 256 258 259 263 264 267 268 271 272 274 275 276 278 280 282 284 285 287 289 293 294 295 297 299 300 301 303 305 308 310 312 316 317 318 320 322 323 324 326 328 329 331 332 334 335 340 342 343 344 345 346 349 350 351 356 358 364 366 368 369 370 371 372 377 379 381 385 386 387 394 397 400 401 404 406 407 409 412 413 414 415 416 417 419 420 421 422 423 425 427 429 430 431 433 439 440 444 447 449 452 454 455 456 459 460 462 463 465 467 468 469 470 472 476 478 480 482 483 484 485 486 488 489 490 491 492 494 495 496 501 504 506 508 509 510 511
<readmem: ffffffff821262c0, KVADDR, "online", 64, (ROE), f64640>
<read_vmware_vmss: addr: ffffffff821262c0 paddr: 21262c0 cnt: 64>
cpu_online_mask: cpus: 0 3 4 8 10 11 12 13 15 17 21 22 27 28 29 32 33 35 44 45 46 48 49 51 52 53 54 57 58 59 62 63 65 66 67 69 72 74 75 86 87 89 90 91 96 97 99 100 101 106 107 110 111 113 115 116 117 122 123 125 128 129 130 134 135 136 142 143 145 147 149 150 153 156 157 160 161 163 164 166 167 168 173 176 179 180 184 187 189 191 192 193 198 199 201 204 205 207 208 209 212 214 215 216 217 218 221 222 224 227 228 234 235 236 239 241 242 244 245 248 250 252 253 255 256 257 262 263 265 266 267 268 271 273 275 276 277 278 279 280 288 289 291 293 295 296 297 300 304 305 306 308 310 312 313 317 318 320 325 326 327 328 329 330 331 332 333 337 338 339 342 344 346 348 349 350 352 355 356 361 368 369 375 380 381 382 383 385 387 389 390 391 394 395 397 398 399 400 401 403 405 406 408 409 410 412 415 416 417 418 422 424 427 429 430 432 434 436 438 441 443 444 451 452 456 460 462 464 466 469 473 474 476 479 480 484 487 488 489 494 498 499 500 503 504 506 509 510
<readmem: ffffffff82126240, KVADDR, "active", 64, (ROE), f64640>
<read_vmware_vmss: addr: ffffffff82126240 paddr: 2126240 cnt: 64>
cpu_active_mask: cpus: 0 1 3 4 5 8 12 13 14 15 16 19 21 23 25 27 29 37 43 45 48 51 54 55 56 57 58 59 60 61 62 63 66 67 68 70 73 75 76 78 80 81 84 86 92 94 95 96 98 99 100 103 104 105 109 110 111 114 115 122 124 126 127 128 130 134 136 137 141 142 144 146 150 152 154 158 159 161 164 168 169 170 172 174 177 178 180 181 183 189 192 195 198 202 204 207 208 212 213 214 215 216 217 222 225 227 228 229 230 233 234 235 238 239 240 242 244 247 248 250 253 255 256 258 260 267 268 270 273 274 275 276 279 280 282 286 287 294 296 300 302 303 305 308 310 311 312 313 314 315 316 317 319 320 323 325 328 330 331 333 336 337 340 341 342 344 348 349 350 351 352 353 354 355 359 363 364 366 368 370 373 374 375 379 380 382 383 385 387 388 391 397 398 400 401 402 403 408 409 410 412 414 416 417 418 420 423 430 431 439 445 446 448 449 450 451 458 459 461 463 468 469 470 471 472 474 475 477 481 483 484 486 488 490 495 496 497 500 501 503 504 505 509
FREEBUF(0)
<readmem: ffffffff82031aa0, KVADDR, "pv_init_ops", 8, (ROE), 7fffa1149090>
<read_vmware_vmss: addr: ffffffff82031aa0 paddr: 2031aa0 cnt: 8>
GETBUF(280 -> 0)
FREEBUF(0)
GETBUF(280 -> 0)
FREEBUF(0)
<readmem: ffffffff84710860, KVADDR, "shadow_timekeeper xtime_sec", 8, (ROE), 7fffa1149030>
<read_vmware_vmss: addr: ffffffff84710860 paddr: 4710860 cnt: 8>
xtime timespec.tv_sec: 54d151d0619456fc: (null)
<readmem: ffffffff82012304, KVADDR, "init_uts_ns", 390, (ROE), d0a7fc>
<read_vmware_vmss: addr: ffffffff82012304 paddr: 2012304 cnt: 390>
utsname:
sysname: (not printable)
nodename: (not printable)
release: (not printable)
version: (not printable)
machine: (not printable)
domainname: (not printable)
crash: cannot determine base kernel version
<readmem: ffffffff81c00100, KVADDR, "accessible check", 8, (ROE|Q), 7fffa1146390>
<read_vmware_vmss: addr: ffffffff81c00100 paddr: 1c00100 cnt: 8>
<readmem: ffffffff81c00100, KVADDR, "read_string characters", 1499, (ROE|Q), 7fffa11466f0>
<read_vmware_vmss: addr: ffffffff81c00100 paddr: 1c00100 cnt: 1499>
linux_banner:
-ش????kB??C???Ã͞}&k?Xb?8/?ν?fF??&v;?Š???? ??
crash: /home/user/vmem_vmss_jan26/usr/lib/modules/4.14.11-coreos/build/System.map and /home/mfusion/vmem_vmss_jan26/gt-Server2-gmt-612746ca.vmss do not match!Usage:crash [OPTION]... NAMELIST MEMORY-IMAGE[@ADDRESS] (dumpfile form)
crash [OPTION]... [NAMELIST] (live system form)Enter "crash -h" for details.
[root@gt-Server2-gmt user]# Please let me know if you need any further information.Will get back to you after checking KASLR and phys_base.
Thank you,Eshak
On Tue, Feb 6, 2018 at 7:26 AM, Dave Anderson <anderson(a)redhat.com> wrote:
----- Original Message -----
>
>
> ----- Original Message -----
> > Hello,
> >
> > We have a CoreOS VM(46 vCPU, 60GB RAM) freeze issue and hoping to find out
> > what is going on in it at the time of freeze. When the VM froze, we have no
> > access to it via ssh and ping works sometimes but not always. So, we
> > suspended the VM which created vmem and vmss files.
> >
> > Since this is a CoreOS VM, I have used toolbox to install and run crash.
> > When trying to read these files using crash utility, I'm getting the below
> > message:
> >
> >
> >
> > <read_vmware_vmss: addr: ffffffff81c00100 paddr: 1c00100 cnt: 8>
> >
> > <readmem: ffffffff81c00100, KVADDR, "read_string characters", 1499,
> > (ROE|Q),
> > 7ffcf595cd70>
> >
> > <read_vmware_vmss: addr: ffffffff81c00100 paddr: 1c00100 cnt: 1499>
> >
> > linux_banner:
> >
> > -ش????kB??C???Ã͞}&k?Xb?8/?ν?fF??&v;?Š???? ??
>
> It would have been helpful to see the full crash -d# log, but I'm presuming
> that the utsname data and the cpus_[possible/present/online/active]_mask
> output
> that gets displayed just before the linux_banner output are also nonsensical?
>
> Typically this kind of problem is because phys_base cannot be determined,
> or if KASLR is enabled, the KASLR offset cannot be determined. Those two
> items are encoded into the dumpfile header for kdump dumpfiles, but there
> is no such information in a vmms dumpfile header.
>
> Can you run crash live on the machine? You can see whether the phys_base
> and KASLR offset are non-zero on the live system by entering:
>
> crash> help -m | grep phys_base
> phys_base: 129800000
> crash> help -k | grep relocate
> relocate: ffffffffcf400000 (KASLR offset: 30c00000 / 780MB)
> crash>
>
> If relocate is 0 (KASLR not enabled), then the phys_base value can
> be applied to your vmcore by entering, for example, "--machdep
> phys_base=780m"
> on the crash command line (using your phys_base).
Sorry, my mistake -- it would be "--machdep phys_base=129800000".
Dave
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
6 years, 4 months
- 2
- 1
linux_banner has garbage
by Eshak
Hello,
We have a CoreOS VM(46 vCPU, 60GB RAM) freeze issue and hoping to find out
what is going on in it at the time of freeze. When the VM froze, we have no
access to it via ssh and ping works sometimes but not always. So, we
suspended the VM which created vmem and vmss files.
Since this is a CoreOS VM, I have used toolbox to install and run crash.
When trying to read these files using crash utility, I'm getting the below
message:
<read_vmware_vmss: addr: ffffffff81c00100 paddr: 1c00100 cnt: 8>
<readmem: ffffffff81c00100, KVADDR, "read_string characters", 1499,
(ROE|Q), 7ffcf595cd70>
<read_vmware_vmss: addr: ffffffff81c00100 paddr: 1c00100 cnt: 1499>
linux_banner:
-ش????kB??C???Ã͞}&k?Xb?8/?ν?fF??&v;?Š???? ??
crash:
/home/user/vmem_vmss_jan26/usr/lib/debug/usr/lib/modules/4.14.11-coreos/vmlinux
and /home/user/vmem_vmss_jan26/gt-server2-gmt-612746ca.vmss do not match!
Usage:
crash [OPTION]... NAMELIST MEMORY-IMAGE[@ADDRESS] (dumpfile form)
crash [OPTION]... [NAMELIST] (live system form)
Enter "crash -h" for details.
[root@gt-server2-gmt mfusion]#
1. Does crash utility reads a 60GB file successfully ? Or is there a limit
to file size ?
2. What does the garbage in linux_banner mean ?
Can someone please guide me on reading the memory dump ?
Thank you,
Eshak
6 years, 4 months
- 2
- 4
[PATCH v2 1/2] dynamically allocate schedulers_buf
by Nikola Pajkovsky
crash can simply determinate length of xen schedulers struct.
static const struct scheduler *schedulers[] = {
...
};
Signed-off-by: Nikola Pajkovsky <npajkovsky(a)suse.cz>
---
xen_hyper.c | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/xen_hyper.c b/xen_hyper.c
index 27e44c6e733d..479aa1acfd43 100644
--- a/xen_hyper.c
+++ b/xen_hyper.c
@@ -435,7 +435,6 @@ xen_hyper_misc_init(void)
/*
* Do initialization for scheduler of Xen Hyper system here.
*/
-#define XEN_HYPER_SCHEDULERS_ARRAY_CNT 10
#define XEN_HYPER_SCHEDULER_NAME 1024
static void
@@ -443,7 +442,8 @@ xen_hyper_schedule_init(void)
{
ulong addr, opt_sched, schedulers, opt_name;
long scheduler_opt_name;
- long schedulers_buf[XEN_HYPER_SCHEDULERS_ARRAY_CNT];
+ long *schedulers_buf;
+ int nr_schedulers;
struct xen_hyper_sched_context *schc;
char *buf;
char opt_name_buf[XEN_HYPER_OPT_SCHED_SIZE];
@@ -469,15 +469,17 @@ xen_hyper_schedule_init(void)
XEN_HYPER_OPT_SCHED_SIZE, "opt_sched,", RETURN_ON_ERROR)) {
error(FATAL, "cannot read opt_sched,.\n");
}
+ nr_schedulers = get_array_length("schedulers", 0, 0);
+ schedulers_buf = (long *)GETBUF(nr_schedulers * sizeof(long));
schedulers = symbol_value("schedulers");
addr = schedulers;
while (xhscht->name == NULL) {
if (!readmem(addr, KVADDR, schedulers_buf,
- sizeof(long) * XEN_HYPER_SCHEDULERS_ARRAY_CNT,
- "schedulers", RETURN_ON_ERROR)) {
+ sizeof(long) * nr_schedulers,
+ "schedulers", RETURN_ON_ERROR)) {
error(FATAL, "cannot read schedulers.\n");
}
- for (i = 0; i < XEN_HYPER_SCHEDULERS_ARRAY_CNT; i++) {
+ for (i = 0; i < nr_schedulers; i++) {
if (schedulers_buf[i] == 0) {
error(FATAL, "schedule data not found.\n");
}
@@ -514,9 +516,10 @@ xen_hyper_schedule_init(void)
strncpy(xhscht->name, buf, strlen(buf));
break;
}
- addr += sizeof(long) * XEN_HYPER_SCHEDULERS_ARRAY_CNT;
+ addr += sizeof(long) * nr_schedulers;
}
FREEBUF(buf);
+ FREEBUF(schedulers_buf);
/* get schedule_data information */
if((xhscht->sched_context_array =
--
2.13.6
6 years, 4 months
- 2
- 2
Re: [Crash-utility] [PATCH] Extend Xen hypervisor direct mapping on x86_64
by Dave Anderson
Thanks Petr, queued for crash-7.2.1:
https://github.com/crash-utility/crash/commit/e9ae5eb9749a62060610dc29d1b...
Dave
----- Original Message -----
> Xen commit 615588563e99a23aaf37037c3fee0c413b051f4d (Xen 4.0.0.)
> extended the direct mapping to 5 TB. This area was previously
> reserved for future use, so it is OK to simply change the upper
> bound unconditionally.
>
> Signed-off-by: Petr Tesarik <ptesarik(a)suse.com>
> ---
> xen_hyper_defs.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen_hyper_defs.h b/xen_hyper_defs.h
> index 6d5d256..b871bdd 100644
> --- a/xen_hyper_defs.h
> +++ b/xen_hyper_defs.h
> @@ -63,7 +63,7 @@
> #define HYPERVISOR_VIRT_START (0xffff800000000000)
> #define HYPERVISOR_VIRT_END (0xffff880000000000)
> #define DIRECTMAP_VIRT_START (0xffff830000000000)
> -#define DIRECTMAP_VIRT_END (0xffff840000000000)
> +#define DIRECTMAP_VIRT_END (0xffff880000000000)
> #define PAGE_OFFSET_XEN_HYPER DIRECTMAP_VIRT_START
> #define XEN_VIRT_START (xht->xen_virt_start)
> #define XEN_VIRT_ADDR(vaddr) \
> --
> 2.13.6
>
6 years, 4 months
- 1
- 0
[PATCH] fix error crash: cannot resolve "schedulers"
by Nikola Pajkovsky
Since Xen commit 666aca08175b ("sched: use the auto-generated list of
schedulers") crash cannot open Xen vmcores, because symbol 'schedulers'
does not exits. Xen 4.7 implemented schedulers as its own section.
xen/arch/x86/xen.lds.S
__start_schedulers_array = .;
*(.data.schedulers)
__end_schedulers_array = .;
Crash must not look up for "schedulers" symbol and fails, if symbol is
not found. It must check if __start_schedulers_array exits, and if it
does, use it and get size of the section. Otherwise, crash fallback to
looking up "schedulers" symbol. That way, crash can open vmcore before
and after Xen 4.7.
Signed-off-by: Nikola Pajkovsky <npajkovsky(a)suse.cz>
---
xen_hyper.c | 40 +++++++++++++++++++++++++++++++++-------
1 file changed, 33 insertions(+), 7 deletions(-)
diff --git a/xen_hyper.c b/xen_hyper.c
index 27e44c6e733d..e8268cf40c78 100644
--- a/xen_hyper.c
+++ b/xen_hyper.c
@@ -438,6 +438,19 @@ xen_hyper_misc_init(void)
#define XEN_HYPER_SCHEDULERS_ARRAY_CNT 10
#define XEN_HYPER_SCHEDULER_NAME 1024
+/*
+ * does similar function exits in crash??
+ */
+static int section_size(char *start_section, char *end_section)
+{
+ ulong sp_start, sp_end;
+
+ sp_start = symbol_value(start_section);
+ sp_end = symbol_value(end_section);
+
+ return (sp_end - sp_start) / sizeof(size_t);
+}
+
static void
xen_hyper_schedule_init(void)
{
@@ -448,6 +461,8 @@ xen_hyper_schedule_init(void)
char *buf;
char opt_name_buf[XEN_HYPER_OPT_SCHED_SIZE];
int i, cpuid, flag;
+ char *sp_name;
+ int xen_hyper_nr_schedulers;
/* get scheduler information */
if((xhscht->scheduler_struct =
@@ -469,21 +484,32 @@ xen_hyper_schedule_init(void)
XEN_HYPER_OPT_SCHED_SIZE, "opt_sched,", RETURN_ON_ERROR)) {
error(FATAL, "cannot read opt_sched,.\n");
}
- schedulers = symbol_value("schedulers");
+
+ if (symbol_exists("__start_schedulers_array")) {
+ sp_name = "__start_schedulers_array";
+ xen_hyper_nr_schedulers = section_size("__start_schedulers_array",
+ "__end_schedulers_array");
+ } else {
+ sp_name = "schedulers";
+ xen_hyper_nr_schedulers = XEN_HYPER_SCHEDULERS_ARRAY_CNT;
+ }
+
+ schedulers = symbol_value(sp_name);
+
addr = schedulers;
while (xhscht->name == NULL) {
if (!readmem(addr, KVADDR, schedulers_buf,
- sizeof(long) * XEN_HYPER_SCHEDULERS_ARRAY_CNT,
- "schedulers", RETURN_ON_ERROR)) {
+ sizeof(long) * xen_hyper_nr_schedulers,
+ sp_name, RETURN_ON_ERROR)) {
error(FATAL, "cannot read schedulers.\n");
}
- for (i = 0; i < XEN_HYPER_SCHEDULERS_ARRAY_CNT; i++) {
+ for (i = 0; i < xen_hyper_nr_schedulers; i++) {
if (schedulers_buf[i] == 0) {
error(FATAL, "schedule data not found.\n");
}
if (!readmem(schedulers_buf[i], KVADDR,
- xhscht->scheduler_struct, XEN_HYPER_SIZE(scheduler),
- "scheduler", RETURN_ON_ERROR)) {
+ xhscht->scheduler_struct, XEN_HYPER_SIZE(scheduler),
+ "scheduler", RETURN_ON_ERROR)) {
error(FATAL, "cannot read scheduler.\n");
}
opt_name = ULONG(xhscht->scheduler_struct +
@@ -514,7 +540,7 @@ xen_hyper_schedule_init(void)
strncpy(xhscht->name, buf, strlen(buf));
break;
}
- addr += sizeof(long) * XEN_HYPER_SCHEDULERS_ARRAY_CNT;
+ addr += sizeof(long) * xen_hyper_nr_schedulers;
}
FREEBUF(buf);
--
2.13.6
6 years, 4 months
- 2
- 3
[PATCH] Extend Xen hypervisor direct mapping on x86_64
by Petr Tesarik
Xen commit 615588563e99a23aaf37037c3fee0c413b051f4d (Xen 4.0.0.)
extended the direct mapping to 5 TB. This area was previously
reserved for future use, so it is OK to simply change the upper
bound unconditionally.
Signed-off-by: Petr Tesarik <ptesarik(a)suse.com>
---
xen_hyper_defs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen_hyper_defs.h b/xen_hyper_defs.h
index 6d5d256..b871bdd 100644
--- a/xen_hyper_defs.h
+++ b/xen_hyper_defs.h
@@ -63,7 +63,7 @@
#define HYPERVISOR_VIRT_START (0xffff800000000000)
#define HYPERVISOR_VIRT_END (0xffff880000000000)
#define DIRECTMAP_VIRT_START (0xffff830000000000)
-#define DIRECTMAP_VIRT_END (0xffff840000000000)
+#define DIRECTMAP_VIRT_END (0xffff880000000000)
#define PAGE_OFFSET_XEN_HYPER DIRECTMAP_VIRT_START
#define XEN_VIRT_START (xht->xen_virt_start)
#define XEN_VIRT_ADDR(vaddr) \
--
2.13.6
6 years, 4 months
- 1
- 0