Re: linux-omap git tree updated to v2.6.32-rc1, important changes, please read

[Alexander Shishkin <virtuoso@slind.org>]

2009/9/29 Aguirre Rodriguez, Sergio Alberto <saaguirre@ti.com>:
> From: linux-omap-owner@vger.kernel.org [linux-omap-owner@vger.kernel.org] On Behalf Of Alexander Shishkin [virtuoso@slind.org]
> Sent: Tuesday, September 29, 2009 2:20 PM
>> 2009/9/29 Tony Lindgren <tony@atomide.com>:
>> > * Felipe Contreras <felipe.contreras@gmail.com> [090929 10:24]:
>> >> On Mon, Sep 28, 2009 at 10:04 PM, Tony Lindgren <tony@atomide.com> wrote:
>> >> > Hi all,
>> >> >
>> >> > I've updated our linux-omap tree to v2.6.32-rc1. I've also
>> >> > added a branch omap-2.6.31 for the old code.
>> >> >
>> >> > This time I also nuked the remaining omap legacy code we
>> >> > still had lurking around :) The commits at the end of this
>> >> > mail describe what I did first as commits, then I merged
>> >> > everything to be the same as the mainline v2.6.32-rc1.
>> >> >
>> >> > So currently the linux-omap master branch is:
>> >> >
>> >> > v2.6.32-rc1 + omap-fixes + ehci + cbus
>> >> >
>> >> > The new model is that I'll be resetting the linux-omap master
>> >> > branch to mainline at each -rc, then merge in our various
>> >> > upstream queues back in again.
>> >>
>> >> Excellent! I was wondering why this wasn't being done. I certainly
>> >> hope linus' 2.6.32 will work on omap right away.
>> >
>> > Yeah, let's hope Tomi gets in the DSS2 code too.
>> >
>> >> Anyway, I haven't been able to make 2.6.31 boot on beagleboard, and
>> >> other people report similar issues:
>> >> http://www.spinics.net/lists/linux-omap/msg17968.html
>> >>
>> >> Have you got 2.6.32-rc1 (+fixes) to boot?
>> >
>> > Hmm, looks like it's musb again. This is what I get on my
>> > overo after applying the DEBUG_LL hack from omap-debug branch:
>> >
>> > <3>musb_hdrc musb_hdrc: musb_init_controller failed with status -19
>> > <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
>> > <1>pgd = c0004000
>> > <1>[00000000] *pgd=00000000
>> > Internal error: Oops: 5 [#1]
>> > <d>Modules linked in:
>> > CPU: 0    Not tainted  (2.6.32-rc2-05967-gd350540-dirty #892)
>> > PC is at musb_free+0x68/0xb8
>> > LR is at musb_free+0x34/0xb8
>
> <snip>
>
>> >
>> > After disabling musb, it boots further but can't mount root on the MMC:
>> >
>> > ...
>> > <4>regulator_init_complete: incomplete constraints, leaving VUSB1V8 on
>> > regulator_init_complete: incomplete constraints, leaving VUSB1V8 on
>> > <4>regulator_init_complete: incomplete constraints, leaving VUSB1V5 on
>> > regulator_init_complete: incomplete constraints, leaving VUSB1V5 on
>> > <4>regulator_init_complete: incomplete constraints, leaving VMMC1 on
>> > regulator_init_complete: incomplete constraints, leaving VMMC1 on
>> > <6>twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00 UTC (94)
>> > twl4030_rtc twl4030_rtc: setting system clock to 2000-01-01 00:00:00 UTC (94668)
>> > <6>Waiting for root device /dev/mmcblk0p2...
>> > Waiting for root device /dev/mmcblk0p2...
>> >
>> > What are you getting with DEBUG_LL enabled and the associated patch applied
>> > from omap-debug branch?
>> MUSB enabled gives me the same backtrace. When I disable it, I get
>> (this is beagle B6):
>>
>> <1>Unable to handle kernel NULL pointer dereference at virtual address 00000000
>> <1>pgd = c0004000
>> <1>[00000000] *pgd=00000000
>
> <snip>
>
> Hi,
>
> Can you please try attached patch?

Yep, thanks! (provided it's actually the same patch that Toni referred to).
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html