On 16-09-20, 13:50, Viresh Kumar wrote:
> On 16-09-20, 13:37, Viresh Kumar wrote:
> > On 16-09-20, 09:37, Ulf Hansson wrote:
> > > I have the board as well. If you need some help with testing, just let me
> > > know.
> > >
> > > In any case, I will try the revert and see how that changes things.
On 16-09-20, 13:37, Viresh Kumar wrote:
> On 16-09-20, 09:37, Ulf Hansson wrote:
> > I have the board as well. If you need some help with testing, just let me
> > know.
> >
> > In any case, I will try the revert and see how that changes things.
>
> I am testing this with help of Naresh currently
On 16-09-20, 09:37, Ulf Hansson wrote:
> I have the board as well. If you need some help with testing, just let me
> know.
>
> In any case, I will try the revert and see how that changes things.
I am testing this with help of Naresh currently, will try to update
back today itself.
--
viresh
On Wed, 16 Sep 2020 at 07:22, Viresh Kumar wrote:
>
> On 15-09-20, 23:39, Ulf Hansson wrote:
> > On Tue, 15 Sep 2020 at 16:33, Naresh Kamboju
> > wrote:
> > >
> > > arm64 dragonboard-410c boot failed while running linux next 2020915 due to
> > > the kernel crash.
> > >
> > > metadata:
> > > gi
On 15-09-20, 23:39, Ulf Hansson wrote:
> On Tue, 15 Sep 2020 at 16:33, Naresh Kamboju
> wrote:
> >
> > arm64 dragonboard-410c boot failed while running linux next 2020915 due to
> > the kernel crash.
> >
> > metadata:
> > git branch: master
> > git repo: https://gitlab.com/Linaro/lkft/mirrors
On Tue, 15 Sep 2020 at 16:33, Naresh Kamboju wrote:
>
> arm64 dragonboard-410c boot failed while running linux next 2020915 due to
> the kernel crash.
>
> metadata:
> git branch: master
> git repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next
> git describe: next-20200915
> make_
I think this problem is caused by the lirc_serial module, because if I
try to modprobe the lirc_serial module I get this error:
kobject_add failed for lirc_serial.0 with -EEXIST, don't try to
register things whith the same name in the same directory.
kobject_shadow_add
kobject_set_name
device_add
> It's hard to blindly guess because there's so little to go on.
> At the least, a complete list of the modules loaded, the EIP/RIP
> and the call trace. (This makes up 90% of the output, hence the
> suggestion to take a photograph).
Ok, I wrote down all the error:
===
On Fri, Aug 10, 2007 at 01:44:24AM +0200, shacky wrote:
> > You snipped the most important part. Even a digital photo of the
> > crash would be more useful than what we have above.
> > So far, there's not really much to go on.
>
> Could you tell me what is the most important part, so I try t
> You snipped the most important part. Even a digital photo of the
> crash would be more useful than what we have above.
> So far, there's not really much to go on.
Could you tell me what is the most important part, so I try to rewrite
it by hand?
I don't think a digital photo will be much useful
On Fri, Aug 10, 2007 at 01:17:14AM +0200, shacky wrote:
> [87.935473] BUG: unable to handle kernel paging request at virtual
> address 6d207972
> [...] printing eip:
> [...] 6d207972
> [...] *pde =
> [...] Oops: 000 [#2]
> [...] SMP
> [.
11 matches
Mail list logo