Discussed with Oliver on IRC. I reverted the /vendor/firmware and
/system/firmware lookup bits, but that was a no-op change after all as
lxc-android-cfg diverts the rules.
There is no need for diversion there, BTW: lxc-android-cfg could just
ship (or create in postinst) an empty
/etc/udev/rules.d/
On Fri, Jun 07, 2013 at 04:59:51AM -, Martin Pitt wrote:
> Does that mean we should revert the firmware lookup from /system and
> /vendor in udev?
Possibly. You were rather quick on the draw in uploading that change, I was
expecting more discussion first. ;-)
For the moment, lxc-android-conf
Does that mean we should revert the firmware lookup from /system and
/vendor in udev?
** Changed in: systemd (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/118
Apparently I missed something in the changelog; but this workaround to
lxc-android-config has been uploaded. Changelog entry:
lxc-android-config (0.14) saucy; urgency=low
* Add diversions for /lib/udev/rules.d/50-firmware.rules and
/lib/udev/rules.d/60-persistent-v4l.rules: the first becau
Fundamentally this is a kernel bug, for panicing when the firmware load
fails. But we should also be working through the issue of udev+ueventd
double-handling of firmware requests. The change for bug #1187616
already lets udev read firmware from /system/firmware +
/vendor/firmware, but we may not
** Also affects: systemd (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1187189
Title:
Kernel crash and reboot when accessing video device
To man
However, if I disable firmware.rules, *but* leave persistent_v4l.rules
enabled, I still get a crash on boot - probably because udev is trying
to probe the hardware before ueventd has started up to handle the
firmware request.
[4.898886] msm_mctl_dev_open mctl NULL!
[4.899221] Unable to han
Here's the stacktrace from /proc/last_kmsg. This is clearly another
knock-on problem from udev (not ueventd) handling the firmware requests.
We may want to disable /lib/udev/rules.d/50-firmware.rules on these
images as a workaround.
[13793.644710]
[13793.644710] err: request_firmware for vidc_
Disabling /lib/udev/rules.d/50-firmware.rules would probably also solve
the udev/ueventd boot ordering problem
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1187189
Title:
Kernel crash and reboot wh
to debug this, boot into recovery right after the crash, log in via adb and
issue:
cat /proc/last_kmsg
that should give you teh oops (if there is one)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/11
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: linux-mako (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1187189
Title:
** Changed in: linux-mako (Ubuntu)
Importance: Undecided => High
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1187189
Title:
Kernel crash and reboot when accessing video device
To manage notifi
12 matches
Mail list logo
