Bug 753339
| Summary: | Hang during reboot - unable to umount partition | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Peter Bieringer <pb> |
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 16 | CC: | alfredo.maria.ferrari, bugzilla, chrisburel, dwalsh, gansalmon, harald, hvtaifwkbgefbaei, itamar, jan.public, Jes.Sorensen, jfeeney, jgetsoian, johannbg, johannbg, johannbg, jonathan, kernel-maint, lpoetter, madasafan, madhu.chinakonda, metherid, ml054, mschmidt, naveed, notting, pb, plautrba, systemd-maint, tygrys |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 713224 | Environment: | |
| Last Closed: | 2012-02-14 22:30:14 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Peter Bieringer
2011-11-11 22:15:41 UTC
Meanwhile I also use FC16 on my workstation and noticed the problem while shutdown at two different lines: *) Unmounted /dev/mqueue. *) Unmounted /dev/hugepages. I did a fresh install of F16 (multiple to test), and I see this now - hangs on every shutdown. Previously it didn't happen, but that was an install upgraded from F15. If I leave it long enough I get a timeout on the console which references systemd holding a lock. The same issue shows itself in rawhide - this is starting to look like a showstopper..... Jes (In reply to comment #2) > If I leave it long enough I get a timeout on the console which references > systemd holding a lock. Could you be more specific? Is it a lockdep message, a softlockup, or what? Can this bug be explained by this?: https://bugzilla.redhat.com/show_bug.cgi?id=752593#c7 Sorry I didn't get a log of it, and it seems to have to sit there for a very long time before it shows up. It was a console message with a backtrace from the kernel. I do not remember if it was lockdep or softlockup though. It is most likely due to what you explain in 752593. I added the comment because I see it too on fresh installs (I didn't with my older upgraded ones), so it is going to become an urgent issue to get the case fixed you mention in 752593. I have the same problem on two different brand new laptops (a Dell E6220 and a Dell E6520), both running a fully updated fresh install of Fedora 16 (x86_64). None of them has a raid system (even though the BIOS could support them) or mounts nfs partitions. They both run a very plain disk layout (dual boot W7/F16). If I hit "shutdown" on the graphical menu, or I issue "shutdown -h now" the laptops come down neatly. If I hit "restart" or I issue "shutdown -r now" they both start the shutdown process (the window manager disappears and the graphical boot logo appears) but then they hang forever with no relevant message in the system logs and only the power button can succeed in powering them off. Fully reproducible (I was never able to get reboot working even once). Rather a Dell E6500 (two years older), with F16 (x86) upgraded from F15, reboots successfully, but half of the times I hit "shutdown" it rather reboots... Finally a Dell E4310 (1 year old), with F16 (x86) upgraded from F15, reboots and shutdowns in the correct way. Rather than their model/age and x86 vs x86_64, fresh install vs upgrade, the four laptops have nearly identical disk layouts and F16 installations. I truly appreciate the fun that systemd or more in general F15 and F16 brought to us (this one is just one of the many examples, I just spent yesterday getting vncserver working again "a la systemd"). As an old Linux user (I started with RedHat 4.2 and I use Linux almost exclusively for work on several machines and clusters, some managed by me). it is the first time I feel Windows more robust... I never thought "reboot" could become such a complex issue. (In reply to comment #5) > I never thought "reboot" could become such a complex issue. There are other possible reasons besides the systemd + storage-daemons-in-userspace why machines may have trouble rebooting: http://mjg59.livejournal.com/137313.html The Dells will probably be able to reboot if you pass "reboot=pci" on the kernel command line. Give it a try. Peter, are you still seeing the problem? What hardware do you have? Could you turn off the sandbox init script and see if this fixes the problem. About the suggestion to boot with reboot=pci for the DELL laptops. Thanks for the suggestion. It works for the E6220 (yet to try on the other one), with that kernel parameter it reboots correctly. Assuming the other laptop will be fixed as well, how could a "normal" (and decently experienced) user guess it? And for which hardware/software configurations is this switch required (I have other DELL laptops/desktops which reboot without it)? Also wouldn't it be better if the installer takes care of checking and possibly providing the correct boot line? (In reply to comment #9) > how could a "normal" (and decently experienced) user guess it? I guessed it by querying "E6220 linux reboot" in Google. > And for which hardware/software configurations is this switch required > (I have other DELL laptops/desktops which reboot without it)? For the broken ones. I don't know the list. > Also wouldn't it be better if the installer takes care of checking and > possibly providing the correct boot line? No. It would be better if this were fixed in the kernel. Apparently Ubuntu have added quirks for some Dells to their "sauce" patchset. They tried to push them upstream, but they failed: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/833705/comments/13 Matthew, would you know more about the problem that Dell E6220 and E6520 require 'reboot=pci'? Why weren't the Ubuntu quirks accepted upstream? Is there going to be a better solution? It's a Dell firmware bug. They work fine if you disable VT-d first. If Dell aren't going to fix their firmware then we need to tear down VT-d state before reboot, not keep adding to a list of quirks. Just out of curiosity has someone try to contact Dell and inform them about this issue? If so what was their response ( if any ) as do they accept this as a valid bug or do they ( or vendors in general ) dismiss firmware bugs since this is not running windows? (In reply to comment #7) > The Dells will probably be able to reboot if you pass "reboot=pci" on the > kernel command line. Give it a try. > > Peter, are you still seeing the problem? What hardware do you have? Yes, I have still the problem, mainboard is Intel DX58SO with BIOS SOX5810J.86A.5559.2011.0405.2144. VT-d disabled at the moment, tried also "reboot=pci", but don't help, at the moment hanging on Unmounting /sys/kernel/debug for me it looks like that it's depending on the Intel Software RAID. Harald recently landed in dracut I do believe the final missing piece of the puzzle to proper working solution. http://git.kernel.org/?p=boot/dracut/dracut.git;a=commit;h=e539fa99801d0b0b316017702ee013a50d2c19d3 Not sure if the solution makes it to F17 Alpha spin for someone using intel bios raid to start testing it thou.... (In reply to comment #14) > for me it looks like that it's depending on the Intel Software RAID. Then it's indeed bug 752593 or something closely related. I'm closing it as duplicate. When that bug gets fixed and if you're still seeing the problem then, please file a new one. *** This bug has been marked as a duplicate of bug 752593 *** |