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 
> wrote:
>> 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:
>>>> All,
>>>> 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 
>> info.
>> attached file (disassembly-image-info.txt) is having info collected based on 
>> "1f2d83".
>>
> 
> 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 
> debugging.
> 

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.

Jan

-- 
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 
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jailhouse-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to