From: Tom Talpey <tmtalpey@rcn.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: arm kernel configurations
Date: Thu, 30 Oct 2008 16:10:46 -0400 [thread overview]
Message-ID: <MADEUP.15FE1A160A8047CE.13558@groups.io> (raw)
In-Reply-To: <1225393313.4235.451.camel@lenovo.internal.reciva.com>
At 03:01 PM 10/30/2008, Phil Blundell wrote:
>On Thu, 2008-10-30 at 14:37 -0400, Tom Talpey wrote:
>> Interesting. This time it booted all the way to GPE. But, hid2hci
>> faulted and the kernel trapped on it. Nothing strange at all about
>> that binary, and the same one works fine on the OABI kernel.
>
>That's very strange indeed. Does it do the same thing every time or is
>it more random than that?
Perfectly repeatable.
>> >Unable to handle kernel paging request at virtual address 560000b8
>
>This doesn't seem to have any obvious relation at all to the OABI
>setting. There's no reason why the kernel should be trying to access
>that memory address during a core dump. At a first appearance I would
>say that you have some kind of hardware problem (misconfigured memory or
>the like) but obviously in that case you would expect it to fail under
>OABI too. So, all in all, very weird.
I don't think it's hardware, because it works fine at all other times (i.e.
booting other kernels and no other changes). And, there's nothing really
to mess up on the H1940 configuration-wise.
The good news for me is that I'm having really good success running a
new 2.6.27 kernel. I've done a ton of stuff to it, but having the new
upstream s3c mci driver is a huge boon to making it work properly. I also
got sound working, by writing some code to use the uda1380 codec driver
already upstream, and turning on "alsa" in the oe machine.conf.
Except for a bootloader, reading the battery level and this OABI strangeness
(plus a couple of other kernel config glitches) I dare say it's a complete port.
Almost ready to share it...
Tom.
prev parent reply other threads:[~2008-10-30 20:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-29 15:26 arm kernel configurations Phil Blundell
2008-10-30 14:40 ` Tom Talpey
[not found] ` <E1KvYmj-0007s2-Og@linuxtogo.org>
2008-10-30 15:08 ` Phil Blundell
2008-10-30 16:45 ` Tom Talpey
[not found] ` <E1Kvahy-0001AR-Sj@linuxtogo.org>
2008-10-30 17:13 ` Phil Blundell
2008-10-30 18:09 ` Tom Talpey
[not found] ` <E1Kvc17-0001Gl-VY@linuxtogo.org>
2008-10-30 18:37 ` Tom Talpey
2008-10-30 18:42 ` Phil Blundell
[not found] ` <E1KvcSD-0007H7-V3@linuxtogo.org>
2008-10-30 19:01 ` Phil Blundell
2008-10-30 20:10 ` Tom Talpey [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=MADEUP.15FE1A160A8047CE.13558@groups.io \
--to=tmtalpey@rcn.com \
--cc=openembedded-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.