ease again, forcing us
to reboot the cards.
Best regards,
Mattis Lorentzon
***
Consider the environment before printing this message.
To read Autoliv's Information and Confidentiality Notice, follow th
ethernet issues.
The serial port and ethernet are essentially the only things we use. No disks,
no graphics, no USB, etc. which is why we tried to reduce the kernel
configuration to a bare minimum. We have no idea which disabled and/or
enabled options that are causing the s
config seems promising and we will continue to run tests during the
next couple of days. We will also try to adapt Iain's config to our Zynq board.
Many thanks for all suggestions, patches and configs so far!
Best regards,
Mattis Lorentzon
k driver state (full buffers etc.)?
Best regards,
Mattis Lorentzon
***
Consider the environment before printing this message.
To read Autoliv's Information and Confidentiality Notice, follow this link:
http://www.autoliv.com/disclaimer.html
***
config.
http://lkml.iu.edu/hypermail/linux/kernel/1408.1/03045/config.gz
(We have quite generously disabled a lot of sub-systems in our config.)
Best regards,
Mattis Lorentzon
***
Consider the environment before printing this message.
T
ests we have finally been able to trigger the exact same
stalls
on the Sabrelite board with a direct network connection (i.e. without the
switch).
Best regards,
Mattis Lorentzon
***
Consider the environment before printing this messa
he switch that allows us to run
many
cards simultaneously and thus trigger the problem more easily. :-)
What are your thoughts?
Best regards,
Mattis Lorentzon
***
Consider the environment before printing this message.
To read Autoliv
0 0 GIC 151 2188000.ethernet
Our device tree might still be slightly incorrect. We have noticed that our
RGMII_INT is connected to GPIO 19 (P5) which might be nonstandard (we are
a bit surprised that this works at all). We are not quite sure how to configure
this properly.
Be
s are happening.
Would you have any ideas on what to check next?
Best regards,
Mattis Lorentzon
***
Consider the environment before printing this message.
To read Autoliv's Information and Confidentiality Notice, follow t
le the ARM hardware to
get it back to a usable state. These stalls last at least several minutes,
perhaps indefinitely. It does not seem to recover properly, and is no longer
reachable via the network.
Best regards,
Mattis Lorentzon
***
C
o you use? Do you have pull-up in the MDIO line?
Our hardware has the KSZ9021RN PHY, so the MDIO line should be pull-up.
Do you know if there are debug options that could help us determine the
cause of the timeout?
Best regards,
Mattis
patches on top of v3.16-rc2 and are
currently running some stability tests.
During our first test round we triggered a timeout which caused the fec driver
to become unresponsive for several minutes. The attached backtrace was
shown when the hardware
Thank you for your reply,
> On Wed, Jun 25, 2014 at 01:55:05PM +0000, Mattis Lorentzon wrote:
> > I have a similar issue with v3.16-rc2 as previously reported by Waldemar
> Brodkorb for v3.15-rc4.
> > https://lkml.org/lkml/2014/5/9/330
>
> This URL returns no useful i
frequently when using perf.
Linux imx6-test0 3.16.0-rc2+ #1 SMP Wed Jun 25 15:04:16 CEST 2014 armv7l armv7l
armv7l GNU/Linux
Any help is greatly appreciated.
Best regards,
Mattis Lorentzon
Unable to handle kernel paging request at virtual address
pgd = 9e338000
[] *pgd=2fffd821
14 matches
Mail list logo