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

Bug#1001001: linux-image-5.10.0-9-arm64: kernel BUG at include/linux/swapops.h:204!



Hi Paul,

On Wednesday, 22 June 2022 21:57:06 CEST Paul Gevers wrote:
> On 21-06-2022 23:19, Diederik de Haas wrote:
> 
> > I think that the install logs aren't that important (anymore) as the
> > issue/symptoms appear to be the same:
> > - some swap action resulting in some failure
> > - CPU gets stuck
> > - watchdog triggers a reboot
> 
> If the reboot would actually happen/finish, I wouldn't have problems of 
> the hanging host. The issues I spotted required a manual reboot (and 
> that's why I spotted them).

Hmm ...interesting. AFAIK that is a watchdog's task.
And I was certain I saw sth about it as I've seen (a yet to be reported) an 
issue related to watchdog myself, hence why I remembered it.

On Saturday, 4 December 2021 22:44:38 CEST Paul Gevers wrote:
> I noticed in the logs that *after* the reported kernel bug but before
> the actual hang, I see multiple instances of:
> watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [apt-get:2204621]
> and
> watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [kcompactd0:40]
> on ci-worker-arm64-07.

And here is where I saw it. (My watchdog issue doesn't cause a hang btw)

> > How is swap configured on these devices?
> 
> https://salsa.debian.org/ci-team/debian-ci-config/-/blob/master/cookbooks/ba
> sics/default.rb#L3 until line 11

Not familiar with Ruby, but IIUC a swap file get created half the size of RAM.
I _think_ the swapon command isn't technically needed as it will be done on 
bootup through fstab, but shouldn't hurt either. Seems fine :)

> > I *assumed* it was running on arm64 (native) hardware and was about to
> > ask specifics about it and then I noticed this:
> > Host bridge [0600]: Red Hat, Inc. QEMU PCIe Host bridge [1b36:0008]
> > 
> > Qemu. Quite likely unrelated, but a while back I had an issue with qemu
> > in building arm64 images: https://bugs.debian.org/988174
> 
> hmm, OK, right (I forgot that I knew this).
> 
> > I think it would be useful to know which qemu version(s) were used.
> 
> Is there any way to know from inside the VM?

If you have access to the host, APT should be able to tell you.

Via sources.list.erb I found that "<%= node['debian_release'] %>-backports" 
gets enabled, which I assume results in Stable-backports.
It appears that various tools get installed (but I don't see qemu mentioned 
(explicitly), but I do see 'virt-what' and the package description seems to 
indicate it may be useful to figure out detail of the VM.

@mjt, I have two questions for you:
1) do you know if/how the qemu version can be queried from within the VM?
2) Are you aware of potential issues wrt hangs in arm64 VM created with Qemu?
Or IOW, could you take a look at this bug and can you give tips which could 
help in tracking down the cause and subsequently the solution?

TIA,
  Diederik

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: