3.17 kernel, BUG: using smp_processor_id() in preemptible - caller is zio_nowait #2769
Comments
|
@kernelOfTruth is this the very latest master code? If so this is likely a regression due to e022864 which was just merged. |
|
That's exactly what happened. Let me push a patch quick to fix it, if you could verify that fix that would be great. |
|
@kernelOfTruth #2770 addresses the issue. If you could verify the fix that would be great, I'd like to get this merged faster than usual since I'm not keen on leaving the master branch in it's current state for long. |
|
@behlendorf unfortunately I can't tell anything whether it helps except the following experience: after booting into the kernel with the patches ZFS code I get stall reported by rcu_preempt did 4 reboots so far and no luck 1st boot) booting into composited xfce4, opened a few apps (tomboy notes, klipper, gnome-terminal) - during attempt to modify a file (~/.xinitrc) -> a letter was stuck, being repeated - numlock still worked for some time, mouse couldn't move - desktop frozen, then even magic sysrq key didn't work; - only reset helped (via button on PC case) 2nd boot) reboot, zfs mount -a; still in VT; if I remember correctly that was all - then there came an error message - unfortunately the first part of it scrolled by too fast (or even 2 traces) - only the 3rd I could take a picture: ... hardlock after some time - only reset via button helped 3rd boot) zfs mount -a; /etc/init.d/slim restart (firing up the display manager); then when entering the usual desktop environment LXQt - it would hardlock up after a few seconds of starting up apps (e.g. klipper, tomboy notes, ...) 4th boot) zfs mount -a; /etc/init.d/slim restart (firing up the display manager); then when entering the usual desktop environment LXQt - it would hardlock up after a few seconds of starting up Chromium After this even booting into the 3.17-based kernel with the zfs-code which had not been patched the locked would occur - this got me worried whether ~/.xinitrc or the pool was broken Data seems fine so far and I'm currently writing from a 3.16.4-based kernel with latest code from yesterday, (CEST), to be honest I don't know whether the 5176 illumos code change already was included and am a little scared - so I'll stay on this kernel for some time Sorry for being unable to provide more info (call trace, BUG name, etc.) - tried to get the error message but none is shown - also last kernel messages, etc. can't be shown since it's a hardlock which happens rather fast |
|
I'll try again and wipe all information related to 3.17 kernels from root and /lib/modules hopefully that improves things ... |
|
@kernelOfTruth thanks for the update. The root cause of the original BUG you've posted has been addressed in master. But please let us know if you observe any other strange symptoms. |
|
compiled a new kernel with added zram & btrfs patches added on top only and no hardlocks so far I suspect that there was an issue with the graphics driver (or even virtualbox, since I haven't installed that module this time yet) that interacted badly with ZFS so far it has survived 2 incremental data transfers via rsync to an Btrfs and an ZFS volume (1.8 TB of data) dmesg | grep -i zfs dmesg | grep -i spl no additional (problem indicating) messages so far in dmesg Thanks 👍 |
|
FYI: There seems to be a deeper issue with 3.17.y kernels and RCU stalls: http://marc.info/?l=linux-kernel&m=141288512930863 [RCU stalls -> lockup linux-3.17] so I'm not the only one and it's most probably NOT related to ZFS or SPL |
Hi,
just completed booting up a 3.17.0-based kernel
during loading of the kernel modules the following is shown:
full error message:
http://pastebin.com/G6YkLSeb
is this an zfs- or rather a spl-related issue ?
The text was updated successfully, but these errors were encountered: