On 2018-02-21 09:32, r.ravindran...@matellio.com wrote:
> On Tuesday, February 20, 2018 at 2:44:39 PM UTC+5:30, r.ravin...@matellio.com
>> On Monday, February 19, 2018 at 6:23:13 PM UTC+5:30, J. Kiszka wrote:
>>> On 2018-02-19 12:41, r.ravindran...@matellio.com wrote:
>>>> I have two LAN ports in X86 and want to establish connection
>>>> using Jailhouse root-cell & non-root-cell.
>>>> host system : CENTOS linux 7
>>>> root-cell : jan's 4.14.18 kernel
>>>> non-root-cell : same but based for PCI device "0000:03:00.0"
>>>> Did experimentation with above setup.
>>>> One LAN (0000:03:00.1) port be used in root-cell,
>>>> while other LAN port (0000:03:00.0) used in non-root-cell.
>>>> created the non-root-cell config file based on the LAN device 0000:03:00.0.
>>>> Did quite a few experimentation before reaching the crash.
>>>> I am not able to proceed in debugging. Please help here.
>>> Let's look at the boot log of Linux:
>>>> [ 0.122355] pci 0000:00:01.0: PCI bridge to [bus 01]
>>>> [ 0.127058] pci 0000:00:03.0: PCI bridge to [bus 02]
>>>> FATAL: unsupported instruction (0x66 [0x00] 0x00 0x00)
>>>> FATAL: Invalid MMIO/RAM read, addr: 0x0000000080300168 size: 0
>>>> RIP: 0xffffffffa41f2d83 RSP: 0xffffa9538006bba0 FLAGS: 10282
>>> So, the first FATAL is because Jailhouse is trying to handle MMIO that
>>> is issued by an instruction sequence not understood by Jailhouse so far.
>>> The accessed address is printed in the second FATAL line. That's right
>>> inside the MMCFG region, and it is targeting the device 00:03.0 which is
>>> legal according to the cell config.
>>> OK, it seems your Linux kernel is accessing MMCFG via some unsupported
>>> SSE2 mov instruction. Could you disassemble the non-root kernel around
>>> 0xffffffffa41f2d83, maybe also share your .config and compiler version?
>> Thank you Jan.
>> Attached .config (dotConfigLnx4p14p18Kernel.txt) file and
>> compiler version is below
>> # gcc --version
>> gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16)
>> Sorry Jan, I am not able to get the details (around or nearby) of above RIP
>> address (0xffffffffa41f2d83) from kernel image using objdump. I did not find
>> any relevant info.
>> But used "1f2d83" from RIP address "0xffffffffa41f2d83" to trace relevant
>> attached file (disassembly-image-info.txt) is having info collected based on
> Hi Team,
> Could you please share your thoughts on what is wrong in my setup or missing
> from above crash and files been attached ?.
> If any inputs (for log file) is needed, i will surely attach for further
That triggering address may come from module. Record, prior to
triggering the issue, what /proc/modules contains and map the faulty
address later on to the module. With the module offset, you can do the
disassembly relatively afterwards.
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.