On 15-01-26 11:54 PM, Yani Dubin wrote:
Hi,
I have run up against a kernel bug on the dizzy branch where a read of
an ADC channel (IIO bus) on a Sitara (am335x) processor locks up the
process reading the /sys/bus/iio/devices/iio\:device0/in_voltage?_raw
node. The system remains stable, but the locked process does not
respond to SIGKILL. No kernel errors or debugging info in the logs -
but I have taken no steps to improve verbosity. fuser shows the files
as being open by the crashed process.
I did google the issue, but turned up nothing. This is very
reproduceable, and I have done my best to narrow it down on the dizzy
timeline. In each case I have used the same rootfs (built from dizzy
tip), but just flashed a different kernel.
The (yocto) changesets in question are:
36e42c0ddb7a40b3022e9b165560622479f1aa5c - 3.14.26ltsi exhibits issue
446acfb5a474b23041b46c49732474f2d415160d - 3.14.24 doesn't build
d7c61053da96d675c3912a45ee448c20ae91721b - 3.14.19 issue not present
The build error in question is "ERROR: Fetcher failure: Unable to find
revision fba2d0cdb745e0f807ce134fd9d1524b7bed9742 in branch meta even
from upstream".
These are 3 adjacent changesets on the dizzy branch - I gather that is
as much as I can narrow it down?
Should I be submitting this bug to yocto bugzilla (since it affects
the stable release, and I am using linux-yocto) or a linux kernel bug
tracker / mailing list? Or is there further information I should be
getting (enabling kernel debugging / increasing verbosity perhaps)?
Should I do a build off the unstable branch for comparison? (to see if
this has a newer kernel, with upstream fix which resolves the issue)
We may need to get your help in tracking the problem down, since without
the h/w on hand, it will be difficult to figure out what changed between the
working and non-working revisions.
I have some additional 3.14 updates queued, and they may fix the issue ..
but again, I can't say for sure.
Are you able to bisect the kernel directly ? I only submit SRCREV updates to
the linux-yocto recipes at particular milestones, but within the kernel we
obviously have more granularity.
After you've built the kernel the first time, you can head into devshell
and
then use the unpacked and patched src tree and do a normal git bisect/build
workflow. You'd need to copy the resulting kernels out to your target,
but that
would narrow down the bad commit/merge pretty quickly.
Bruce
Meanwhile, I thought I would see if anyone else is experiencing this,
or has similar hardware and can see if they are also affected. This is
a custom board, but similar processor-wise to the Beaglebone Black.
Steps to reproduce:
cat /sys/bus/iio/devices/iio\:device0/in_voltage?_raw
The particular drivers in use are:
CONFIG_TI_AM335X_ADC=y
CONFIG_MFD_TI_AM335X_TSCADC=y
Regards,
Yani.
------------------------------------------------------------------------
This email, including any attachments, is only for the intended
recipient. It is subject to copyright, is confidential and may be the
subject of legal or other privilege, none of which is waived or lost
by reason of this transmission.
If you are not an intended recipient, you may not use, disseminate,
distribute or reproduce such email, any attachments, or any part
thereof. If you have received a message in error, please notify the
sender immediately and erase all copies of the message and any
attachments.
Unfortunately, we cannot warrant that the email has not been altered
or corrupted during transmission nor can we guarantee that any email
or any attachments are free from computer viruses or other conditions
which may damage or interfere with recipient data, hardware or
software. The recipient relies upon its own procedures and assumes all
risk of use and of opening any attachments.
------------------------------------------------------------------------
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
