| Summary: | plymouthd crashed with SIGABRT in __assert_fail_base() | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Bryce Harrington <bryce> | ||||||||||||||
| Component: | libdrm | Assignee: | Default DRI bug account <dri-devel> | ||||||||||||||
| Status: | RESOLVED MOVED | QA Contact: | |||||||||||||||
| Severity: | major | ||||||||||||||||
| Priority: | high | CC: | apw, steve.langasek | ||||||||||||||
| Version: | unspecified | ||||||||||||||||
| Hardware: | x86-64 (AMD64) | ||||||||||||||||
| OS: | Linux (All) | ||||||||||||||||
| Whiteboard: | |||||||||||||||||
| i915 platform: | i915 features: | ||||||||||||||||
| Attachments: |
|
||||||||||||||||
|
Description
Bryce Harrington
2012-04-18 14:22:54 UTC
Created attachment 60277 [details]
BootDmesg.txt
Created attachment 60278 [details]
CurrentDmesg.txt
Created attachment 60279 [details]
Lspci.txt
Created attachment 60280 [details]
ProcModules.txt
Created attachment 60281 [details]
ProcModules.txt
Created attachment 60282 [details]
ThreadStacktrace.txt
This is another bug that we think is the same root cause: https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/982889 in this one, X comes up before the drm device is ready, and so trips on a different chunk of code. You can see from comparing timestamps in Xorg.0.log and dmesg when drm is accessed vs. when it is reporting itself ready. We've got a couple ideas on how to fix this in the distro. One is to put a loop around the code paths where the failures occur, to continue retrying for some number of seconds. But that feels like a big hack. The other idea would be if there was an event to indicate the driver is ready for use, that we could listen for and delay plymouth, X, etc. until it's received. But we don't know the feasibility of that. We suspect that the reason this happens is due to a Ubuntu kernel patch, which was added to work around other boot crashing problems: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-precise.git;a=commitdiff;h=6d74feca6235b463ade4ecddd1dfdb73d30a2ff7;hp=e29a4668d7441aa88d8015da51674a7e8159312b "When a drm driver is initialised we first allocate and initialise the drm minor numbers including creating the sysfs files, then we trigger the driver load method. The act of creating the sysfs files triggers the uevent. This means udev may start programs which open /dev/dri/card0 and other interfaces, this can occur before the load method has even started and thus before the driver has fully initialised its data structures. In the case of plymouthd this leads to it opening and closing (in disgust) the interface, which in turn leads to a kernel panic as the mutexes are yet to be initialised. "This patch delays the linking up of the drm devices minor numbers until the driver is fully initialised. As it is possible for consumers of these interfaces to reach them before they are fully initialised we arrange for opens of these devices to return EAGAIN until the device is fully initialised." <jbarnes> so for 48894 I'd open a separate bug against drm for the core issue: if you access the device too early you get a crash <jbarnes> there's a similar bug with accessing the dpms status files in sysfs <jbarnes> if the module is unloading at the time, you can panic the kenrel <jbarnes> also a kernel bug I'll move this bug to drm, as I think the core issue is what we're really looking for advice on here. <jbarnes> ok looks like a core drm kernel bug <jbarnes> we don't lock properly around initialization -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/drm/issues/8. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.