[linux-sparc-devel] Kernel Panic 4.1.12-32.el6uek.sparc64

[Alexandre Chartre]

It's definitively a bug.

It looks like, the sunvdisk driver is not correctly handling the fact
that the vdisk backend is not available when attaching the sunvdisk
driver.

Basically, sunvdisk connects to the Solaris vds driver over a LDC channel,
and starts a handshake. Because the vdisk backend is not available, the
Solaris vds driver will eventually fails the handshake and reset the LDC
channel.

So the sunvdisk driver will receive the LDC channel reset while it is still
probing the vdisk, and the LDC reset handler fails because some vdisk structures
are not initialized yet as we are still probing the vdisk.

I will open a bug and we will work on a fix.

Thanks for reporting the issue.

alex.


On 04/25/2016 02:41 PM, Alexandre Chartre wrote:
>
> On 04/25/2016 02:36 PM, Riaan Rossouw wrote:
>> Yes Alex starting this guest domain on a T5-2.
>>
>> Is below enough?
>
> Yes, thanks (re-adding the list, I forgot to include it initially).
>
> alex.
>
>> ###############################################
>> sunvdc: Virtual Hard disk vdiska
>> sunvdc: vdiska: 41943040 sectors (20480 MB) protocol 1.1
>>    vdiska: vdiska1 vdiska2 vdiska3
>> sunvdc: vdiskb: Attribute NACK
>> sunvdc: vdiskb ldc link reset
>> Unable to handle kernel NULL pointer dereference
>> tsk->{mm,active_mm}->context = 000000000000003b
>> tsk->{mm,active_mm}->pgd = fff8002040892000
>>                 \|/ ____ \|/
>>                 "@'/ .. \`@"
>>                 /_| \__/ |_\
>>                    \__U_/
>> kworker/0:1(18): Oops [#1]
>> CPU: 0 PID: 18 Comm: kworker/0:1 Not tainted 4.1.12-32.el6uek.sparc64 #1
>> Workqueue: sunvdc vdc_ldc_reset_work [sunvdc]
>> task: fff800204a54a2a0 ti: fff800204a54c000 task.ti: fff800204a54c000
>> TSTATE: 0000004480e01606 TPC: 000000001004aa00 TNPC: 00000000006a72c0 Y: 00000000    Not tainted
>> TPC: <vdc_ldc_reset+0x40/0x240 [sunvdc]>
>> g0: 0000000000000000 g1: 0000000000000000 g2: 0000000000dabef0 g3: 00000000000000d3
>> g4: fff800204a54a2a0 g5: fff800204f12a000 g6: fff800204a54c000 g7: 0000000000000720
>> o0: 000000000000001d o1: fff80020409994e6 o2: 0000000000000001 o3: 0000000000000001
>> o4: 0000000000000000 o5: 0000000000000000 sp: fff800204a54f2d1 ret_pc: 000000001004a9fc
>> RPC: <vdc_ldc_reset+0x3c/0x240 [sunvdc]>
>> l0: fff8002040998000 l1: fff80020408084e0 l2: 0000000000000000 l3: 00000000009d8c38
>> l4: 0000000000000005 l5: 0000000000000001 l6: fff80020409994e6 l7: 0000000000244220
>> i0: fff8002040998000 i1: 0000000000c80008 i2: 0000000000bf1000 i3: 0000000000000001
>> i4: fff80020409994c0 i5: 0000000000000000 i6: fff800204a54f381 i7: 000000001004ad04
>> I7: <vdc_ldc_reset_work+0x24/0x40 [sunvdc]>
>> Call Trace:
>>    [000000001004ad04] vdc_ldc_reset_work+0x24/0x40 [sunvdc]
>>    [00000000004867a0] process_one_work+0x160/0x3e0
>>    [0000000000486b54] worker_thread+0x134/0x400
>>    [000000000048bbac] kthread+0xac/0xe0
>>    [0000000000406104] ret_from_fork+0x1c/0x2c
>>    [0000000000000000]           (null)
>> Disabling lock debugging due to kernel taint
>> Caller[000000001004ad04]: vdc_ldc_reset_work+0x24/0x40 [sunvdc]
>> Caller[00000000004867a0]: process_one_work+0x160/0x3e0
>> Caller[0000000000486b54]: worker_thread+0x134/0x400
>> Caller[000000000048bbac]: kthread+0xac/0xe0
>> Caller[0000000000406104]: ret_from_fork+0x1c/0x2c
>> Caller[0000000000000000]:           (null)
>> Instruction DUMP: 92100016  c25e2428  7c197231 <d0586380> c2062040  e0062044  80a40001  02400024  01000000
>> Kernel panic - not syncing: Fatal exception
>> Press Stop-A (L1-A) to return to the boot prom
>> ---[ end Kernel panic - not syncing: Fatal exception
>> ###############################################
>>
>> -----Original Message-----
>> From: Alexandre Chartre [mailto:alexandre.chartre at oracle.com]
>> Sent: Monday, April 25, 2016 2:29 AM
>> To: Riaan Rossouw
>> Subject: Re: [linux-sparc-devel] Kernel Panic 4.1.12-32.el6uek.sparc64
>>
>>
>> Do you see this panic when booting the guest domain?
>> Can you provide the entire stack trace?
>>
>> Thanks,
>>
>> alex.
>>
>>
>> On 04/24/2016 07:22 PM, Riaan Rossouw wrote:
>>> Guys not sure if this email makes it to a moderator or to the list...
>>>
>>> FYI I can reproduce a kernel panic when I have a non existent LDM NFS attachment added as a vdisk).
>>>
>>> vdc_port: probe of vdc-port-1-0 failed with error -54
>>>
>>>                  \|/ ____ \|/
>>>
>>>                  "@'/ .. \`@"
>>>
>>>                  /_| \__/ |_\
>>>
>>>                     \__U_/
>>>
>>> kworker/3:1(77): Oops [#1]
>>>
>>> attachment was:
>>>
>>> # ldm bind usli-plag-ut02
>>>
>>> Path /software/LinuxSparc/linux-sparc-1.0-DVD.iso is not a valid file or device on service domain primary
>>>
>>> # uname -a
>>>
>>> Linux usli-plag-ut02 4.1.12-32.el6uek.sparc64 #1 SMP Thu Dec 17 19:27:27 PST 2015 sparc64 sparc64 sparc64 GNU/Linux
>>>
>>>
>>>
>>> _______________________________________________
>>> linux-sparc-devel mailing list
>>> linux-sparc-devel at oss.oracle.com
>>> https://oss.oracle.com/mailman/listinfo/linux-sparc-devel
>>>
>
> _______________________________________________
> linux-sparc-devel mailing list
> linux-sparc-devel at oss.oracle.com
> https://oss.oracle.com/mailman/listinfo/linux-sparc-devel
>