[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [systemd:1]



Let’s assume it’s not hardware, Dennis has posted the tests and states the machine ran Sol10 fine. My only ideas are 

1) Try using apt to update some individual packages to see if that even works. Try dash and bash and whatever but avoid Systemd and any related libraries.

2a) If those succeed trying update systemd and see if causes the crash.

or

2b) Trying re-exec systemd I think “kill 1” does that these days. 

If you can isolate that it is systemd related the question why that, is it something in the Dbus or some other subsystem.???

In a month or so I’ll be finally going to storage and I’d happy to grab my Netra t105 and play along at that point, it would interesting to know if this issue is specific to the Netra series.

-Mike

> On Mar 13, 2021, at 12:58 PM, Frank Scheiner <frank.scheiner@web.de> wrote:
> 
> Hi Dennis,
> 
> On 13.03.21 20:21, Dennis Clarke wrote:
>> On 3/13/21 5:29 PM, Mike Tremaine wrote:
>>>> On Mar 12, 2021, at 5:56 AM,
>>>> Dennis Clarke <dclarke@blastwave.org> wrote:
>> [...]
>> I did sent a BRK to the serial port and that drops us into the firmware
>> "ok" prompt.  There is a failed fan but in fact the fan is entirely not
>> there. At all. I removed it because it had failed five or six years ago
>> and getting another one is just annoying.  Also it is not really needed.
> 
> Is the heatsink on the board cooled by a chassis then?
> 
>> 
>> We can see that there is 1G of ECC memory and the memory passes all the
>> basic tests.
>> 
>> Now I setup a few of the firmware variables and reset the unit :
>> 
>> ok printenv
>> Variable Name         Value                          Default Value
>> 
>> [...]
>> local-mac-address?    false                          false
>> [...]
> >
>> ceres# ip link show
>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode
>> DEFAULT group default qlen 1000
>>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>> 2: enp1s1f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
>> state UNKNOWN mode DEFAULT group default qlen 1000
>>     link/ether 08:00:20:c2:46:48 brd ff:ff:ff:ff:ff:ff
>> 3: enp1s3f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
>> DEFAULT group default qlen 1000
>>     link/ether 08:00:20:c2:46:48 brd ff:ff:ff:ff:ff:ff
>> ceres#
>> 
>> However there must be a bug somewhere because the physical MAC address
>> is the same on both interfaces.
> 
> This is due to `local-mac-address?` set to `false` in OBP. See e.g. [1]
> for details.
> 
> [1]: https://docs.oracle.com/cd/E36784_01/html/E37475/eyprp.html
> 
> Cheers,
> Frank


Reply to: