* Re: Is this 32-bit NCM?y
From: Bjørn Mork @ 2014-12-04 10:02 UTC (permalink / raw)
To: Enrico Mioso
Cc: Kevin Zhu, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <alpine.LNX.2.03.1412041052310.3861@gmail.com>
Enrico Mioso <mrkiko.rs@gmail.com> writes:
> Guys!
> Don't forget I can test it - since I have a remote machine with 3.16
> kernel and the device, at least for now.
> So - Bjorn: do I need just to disable padding or do I need also to
> perform some other changes? I am sorry if I ask this a little bit
> stupidly, but I was alittle bit busy here.
I don't know. I just mentioned it because it is easy to test, although
the method isn't too obvious. Someone should document this somewhere.
Hey, wait... Someone did :-)
https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
Bjørn
^ permalink raw reply
* Re: Is this 32-bit NCM?y
From: Bjørn Mork @ 2014-12-04 9:55 UTC (permalink / raw)
To: Kevin Zhu
Cc: Enrico Mioso, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <548028A0.5000909@audiocodes.com>
Kevin Zhu <Mingying.Zhu@audiocodes.com> writes:
> I will find it out. And I don't have v3.16 and I'm not going to upgrade
> my OS to that. Sorry. So I would just stick to v3.13.
Ouch. well, OK. I certainly hope you are at v3.13.10 or newer at
least. Otherwise we know very well what the problem is...
One of the reasons for the series that went into v3.16 was making this
sort of debugging easier, enabling on-the-fly NCM aggregation parameter
tuning. I'd certainly recommend taking advantage of it instead of
rebulding the driver every time you want to test the effect of some
minor change to the aggregation scheme. And do feel free to add more
knobs if you need them.
Bjørn
^ permalink raw reply
* Re: Is this 32-bit NCM?y
From: Enrico Mioso @ 2014-12-04 9:53 UTC (permalink / raw)
To: Bjørn Mork
Cc: Kevin Zhu, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <874mtbojqo.fsf@nemi.mork.no>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1529 bytes --]
Guys!
Don't forget I can test it - since I have a remote machine with 3.16 kernel
and the device, at least for now.
So - Bjorn: do I need just to disable padding or do I need also to perform some
other changes? I am sorry if I ask this a little bit stupidly, but I was
alittle bit busy here.
On Thu, 4 Dec 2014, Bjørn Mork wrote:
> Date: Thu, 4 Dec 2014 10:19:11
> From: Bjørn Mork <bjorn@mork.no>
> To: Kevin Zhu <Mingying.Zhu@audiocodes.com>
> Cc: Enrico Mioso <mrkiko.rs@gmail.com>,
> Eli Britstein <Eli.Britstein@audiocodes.com>,
> Alex Strizhevsky <alexxst@gmail.com>,
> Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
> "youtux@gmail.com" <youtux@gmail.com>,
> "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
> "netdev@vger.kernel.org" <netdev@vger.kernel.org>
> Subject: Re: Is this 32-bit NCM?y
>
> Kevin Zhu <Mingying.Zhu@audiocodes.com> writes:
>
>> Guys,
>>
>> After rearranging the padding, putting NCM0 right after NTH, and disable
>> ARP (FLAG_NOARP) and handling the offset alignment issue, it seems it
>> begins to work, though there's still problem with DHCP.
>
> Great! But it would be good to know if _one_ of these changes is enough
> to make it work.
>
>> The DHCP packet's size becomes a large one after the TX function, which
>> is 16384, the maximum.
>
> You can now (from v3.16) disable the padding by setting min_tx_pkt >= tx_max.
> Something like this should do for a simple test:
>
> echo 16384 >/sys/class/net/wwan0/cdc_ncm/min_tx_pkt
>
>
> Bjørn
>
^ permalink raw reply
* Re: 3.12.33 - BUG xfrm_selector_match+0x25/0x2f6
From: Jiri Slaby @ 2014-12-04 9:44 UTC (permalink / raw)
To: f.wiessner, netdev, LKML, stable
In-Reply-To: <547F2462.6040405@smart-weblications.de>
On 12/03/2014, 03:55 PM, Smart Weblications GmbH - Florian Wiessner wrote:
> [16623.095403] BUG: unable to handle kernel paging request at 00000000010600d0
> [16623.095445] IP: [<ffffffff81547767>] xfrm_selector_match+0x25/0x2f6
> [16623.095480] PGD aeaea067 PUD 85d95067 PMD 0
> [16623.095513] Oops: 0000 [#1] SMP
> [16623.095543] Modules linked in: netconsole xt_nat xt_multiport veth ip_vs_rr
...
> [16623.096062] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.12.33 #1
> [16623.096091] Hardware name: Supermicro X9SCI/X9SCA/X9SCI/X9SCA, BIOS 1.1a
> 09/28/2011
> [16623.096137] task: ffffffff81804450 ti: ffffffff817f4000 task.ti: ffffffff817f4000
> [16623.096182] RIP: 0010:[<ffffffff81547767>] [<ffffffff81547767>]
> xfrm_selector_match+0x25/0x2f6
> [16623.096233] RSP: 0018:ffff88083fc03900 EFLAGS: 00010246
> [16623.096261] RAX: 0000000000000001 RBX: ffff88083fc03a20 RCX: ffff880787fb1200
> [16623.096292] RDX: 0000000000000002 RSI: ffff88083fc03a20 RDI: 00000000010600a6
> [16623.096323] RBP: 00000000010600a6 R08: 0000000000000000 R09: ffff88083fc039a0
> [16623.096353] R10: 0000000000000000 R11: 0000000000000001 R12: ffff88083fc03a20
> [16623.096383] R13: 0000000000000001 R14: ffffffff818a9700 R15: ffffffffa01c73e0
> [16623.096414] FS: 0000000000000000(0000) GS:ffff88083fc00000(0000)
> knlGS:0000000000000000
> [16623.096469] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [16623.096498] CR2: 00000000010600d0 CR3: 0000000085f0b000 CR4: 00000000000407f0
> [16623.096528] Stack:
> [16623.096550] 0000000000000000 0000000001060002 ffff880787fb1200 ffff88083fc03a20
> [16623.096602] 0000000000000001 ffffffff81547a7c 0000000000000000 ffff8800baad5480
> [16623.096655] ffffffff81804450 ffffffff818a9700 000000003c9041bc ffffffff81547ef7
> [16623.096721] Call Trace:
> [16623.096744] <IRQ>
> [16623.096749] [<ffffffff81547a7c>] ? xfrm_sk_policy_lookup+0x44/0x9b
> [16623.096802] [<ffffffff81547ef7>] ? xfrm_lookup+0x91/0x446
> [16623.096832] [<ffffffff81541316>] ? ip_route_me_harder+0x150/0x1b0
> [16623.096865] [<ffffffffa01b6457>] ? ip_vs_route_me_harder+0x86/0x91 [ip_vs]
> [16623.096899] [<ffffffffa01b797a>] ? ip_vs_out+0x2d3/0x5bc [ip_vs]
> [16623.096930] [<ffffffff81501420>] ? ip_rcv_finish+0x2b8/0x2b8
> [16623.096959] [<ffffffff814fc2d3>] ? nf_iterate+0x42/0x80
> [16623.096989] [<ffffffff814fc37a>] ? nf_hook_slow+0x69/0xff
> [16623.097017] [<ffffffff81501420>] ? ip_rcv_finish+0x2b8/0x2b8
> [16623.097047] [<ffffffff81501744>] ? ip_local_deliver+0x6f/0x7e
> [16623.097078] [<ffffffff814d82a6>] ? __netif_receive_skb_core+0x5f0/0x66c
> [16623.097108] [<ffffffff814d84b7>] ? process_backlog+0x13e/0x13e
> [16623.097140] [<ffffffffa04b4e09>] ? br_handle_frame_finish+0x382/0x382 [bridge]
> [16623.097187] [<ffffffff814d8503>] ? netif_receive_skb+0x4c/0x7d
> [16623.097218] [<ffffffffa04b4d95>] ? br_handle_frame_finish+0x30e/0x382 [bridge]
> [16623.097265] [<ffffffffa04b4fda>] ? br_handle_frame+0x1d1/0x217 [bridge]
> [16623.097297] [<ffffffffa048e4aa>] ? bond_handle_frame+0x86/0x1bd [bonding]
> [16623.097328] [<ffffffff814d8155>] ? __netif_receive_skb_core+0x49f/0x66c
> [16623.097358] [<ffffffff814d8503>] ? netif_receive_skb+0x4c/0x7d
> [16623.097388] [<ffffffff814d9091>] ? napi_gro_receive+0x35/0x76
> [16623.097418] [<ffffffff813eae17>] ? e1000_clean_rx_irq+0x26d/0x2f5
> [16623.097448] [<ffffffff813ef48e>] ? e1000e_poll+0x65/0x23d
> [16623.097477] [<ffffffff814d8709>] ? net_rx_action+0xa2/0x1c0
...
> This happens again and again with 3.12.33
>
>
> see also: http://www.spinics.net/lists/netdev/msg306283.html
>
> is this already fixed somehow?
Hi, I doubt so, as you are the first one letting me know. Could you
check whether 3.12.30 works OK for you?
thanks,
--
js
suse labs
^ permalink raw reply
* Re: Is this 32-bit NCM?y
From: Enrico Mioso @ 2014-12-04 9:28 UTC (permalink / raw)
To: Kevin Zhu
Cc: Bjørn Mork, Enrico Mioso, Eli Britstein, Alex Strizhevsky,
Midge Shaojun Tan, youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <548028A0.5000909-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2567 bytes --]
Ok - but... you can upgrade your OS to that without any effort - simply apt-get-installing the required linux-image-3.16 package plus the -extra package. It's nothing more in case.
thank you kevin, thank you Bjorn.
Enrico
On Thu, 4 Dec 2014, Kevin Zhu wrote:
> Date: Thu, 4 Dec 2014 10:26:20
> From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
> To: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
> Cc: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
> Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
> Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
> Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
> "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
> "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
> "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> Subject: Re: Is this 32-bit NCM?y
>
> I will find it out. And I don't have v3.16 and I'm not going to upgrade
> my OS to that. Sorry. So I would just stick to v3.13. Anyway, that size
> is wrong, it should be fixed.
>
> Regards,
> Kevin
>
> On 12/04/2014 05:19 PM, Bjørn Mork wrote:
>> Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> writes:
>>
>>> Guys,
>>>
>>> After rearranging the padding, putting NCM0 right after NTH, and disable
>>> ARP (FLAG_NOARP) and handling the offset alignment issue, it seems it
>>> begins to work, though there's still problem with DHCP.
>> Great! But it would be good to know if _one_ of these changes is enough
>> to make it work.
>>
>>> The DHCP packet's size becomes a large one after the TX function, which
>>> is 16384, the maximum.
>> You can now (from v3.16) disable the padding by setting min_tx_pkt >= tx_max.
>> Something like this should do for a simple test:
>>
>> echo 16384 >/sys/class/net/wwan0/cdc_ncm/min_tx_pkt
>>
>>
>> Bjørn
> This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
>
> If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
>
^ permalink raw reply
* Re: [PATCH net] gso: do GSO for local skb with size bigger than MTU
From: Thomas Graf @ 2014-12-04 9:26 UTC (permalink / raw)
To: Jesse Gross
Cc: Michael S. Tsirkin, Du, Fan, Jason Wang, netdev@vger.kernel.org,
davem@davemloft.net, fw@strlen.de, dev@openvswitch.org,
Pravin Shelar
In-Reply-To: <CAEP_g=8U_w+dxUHsTH2JQ9dGNHaJp-ai8pdmrfeYBin9NZ46jQ@mail.gmail.com>
On 12/03/14 at 05:51pm, Jesse Gross wrote:
> I think it depends on where you put the PMTU check. If routing is
> happening in OVS where it is decomposed in several discrete actions
> like set MAC and decrement TTL then perhaps there is another explicit
> action to check the MTU. If it is happening in the context of the IP
> stack, then ICMP generation occurs automatically and if you get that
> if you write a flow to send a packet there. In each case, it seems
> like a flow would be steering you by way of an action to do routing so
> you would have fine grained control. I don't see this as conflicting
> with L3 ACLs in an L2 context in the same way that you don't have to
> automatically decrement the TTL.
OK, I was under the impression that you would detect L3 behaviour
desire in OVS without an explicit action. Hence the worry on wrong
classification for L3 ACLs.
Whether we mark the packet and defer the MTU check or we check right
in the action is an implementation detail in the end. I think we
agree on concept level that we need an API to control behaviour.
^ permalink raw reply
* Re: [PATCH] x86: bpf_jit_comp: simplify trivial boolean return
From: Joe Perches @ 2014-12-04 9:26 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David Laight, Quentin Lambert, David S. Miller, Alexey Kuznetsov,
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, x86@kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1417114175.4305.3.camel@perches.com>
On Thu, 2014-11-27 at 10:49 -0800, Joe Perches wrote:
> On Thu, 2014-11-27 at 12:25 +0000, David Laight wrote:
> > Why the change in data?
>
> btw: without gcov and using -O2
>
> $ size arch/x86/net/bpf_jit_comp.o*
> text data bss dec hex filename
> 9671 4 0 9675 25cb arch/x86/net/bpf_jit_comp.o.new
> 10679 4 0 10683 29bb arch/x86/net/bpf_jit_comp.o.old
Alexei?
Is this 10% reduction in size a good reason to change the code?
^ permalink raw reply
* Re: Is this 32-bit NCM?y
From: Kevin Zhu @ 2014-12-04 9:26 UTC (permalink / raw)
To: Bjørn Mork
Cc: Enrico Mioso, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <874mtbojqo.fsf@nemi.mork.no>
I will find it out. And I don't have v3.16 and I'm not going to upgrade
my OS to that. Sorry. So I would just stick to v3.13. Anyway, that size
is wrong, it should be fixed.
Regards,
Kevin
On 12/04/2014 05:19 PM, Bjørn Mork wrote:
> Kevin Zhu <Mingying.Zhu@audiocodes.com> writes:
>
>> Guys,
>>
>> After rearranging the padding, putting NCM0 right after NTH, and disable
>> ARP (FLAG_NOARP) and handling the offset alignment issue, it seems it
>> begins to work, though there's still problem with DHCP.
> Great! But it would be good to know if _one_ of these changes is enough
> to make it work.
>
>> The DHCP packet's size becomes a large one after the TX function, which
>> is 16384, the maximum.
> You can now (from v3.16) disable the padding by setting min_tx_pkt >= tx_max.
> Something like this should do for a simple test:
>
> echo 16384 >/sys/class/net/wwan0/cdc_ncm/min_tx_pkt
>
>
> Bjørn
This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
^ permalink raw reply
* Re: Is this 32-bit NCM?y
From: Bjørn Mork @ 2014-12-04 9:19 UTC (permalink / raw)
To: Kevin Zhu
Cc: Enrico Mioso, Eli Britstein, Alex Strizhevsky, Midge Shaojun Tan,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <548020DD.3030705@audiocodes.com>
Kevin Zhu <Mingying.Zhu@audiocodes.com> writes:
> Guys,
>
> After rearranging the padding, putting NCM0 right after NTH, and disable
> ARP (FLAG_NOARP) and handling the offset alignment issue, it seems it
> begins to work, though there's still problem with DHCP.
Great! But it would be good to know if _one_ of these changes is enough
to make it work.
> The DHCP packet's size becomes a large one after the TX function, which
> is 16384, the maximum.
You can now (from v3.16) disable the padding by setting min_tx_pkt >= tx_max.
Something like this should do for a simple test:
echo 16384 >/sys/class/net/wwan0/cdc_ncm/min_tx_pkt
Bjørn
^ permalink raw reply
* Re: Is this 32-bit NCM?y
From: Kevin Zhu @ 2014-12-04 9:01 UTC (permalink / raw)
To: Enrico Mioso
Cc: Bjørn Mork, Eli Britstein, Alex Strizhevsky,
Midge Shaojun Tan, youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <alpine.LNX.2.03.1412040955140.3516-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
It looks windows disable it, so I just follow it. Maybe enabling it will
be also OK. I have not tried. I do not find it in hw_cdc_driver.
Regards,
Kevin
On 12/04/2014 04:56 PM, Enrico Mioso wrote:
> Hi Kevin.
> Thank you for your hints and work.
> Only a note - why disabling ARP? I think it could be a good iea... or
> does the hw_cdc_driver do that?
> thank you again,
> Enrico
>
>
>
> On Thu, 4 Dec 2014, Kevin Zhu wrote:
>
>> Date: Thu, 4 Dec 2014 09:52:49
>> From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
>> To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Cc: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>, Eli Britstein
>> <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
>> Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
>> Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
>> "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
>> "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
>> "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
>> Subject: Re: Is this 32-bit NCM?y
>>
>> Guys,
>>
>> After rearranging the padding, putting NCM0 right after NTH, and disable
>> ARP (FLAG_NOARP) and handling the offset alignment issue, it seems it
>> begins to work, though there's still problem with DHCP. It's able to
>> ping, though my Ubuntu network manage does not notice this network
>> interface. So no DNS.
>>
>> I have to specify the network interface and IP in the ping command.
>>
>> The DHCP packet's size becomes a large one after the TX function, which
>> is 16384, the maximum. And the dongle does not reply it in time. For
>> now, I just simple rearrange the code to meet Huawei's alignment
>> requirement. I think other devices may be different, regarding the
>> 'offset' definition. We may need to handle it. And also need to double
>> check if the code has bugs.
>>
>> Regards,
>> Kevin
>>
>> On 12/04/2014 02:31 PM, Enrico Mioso wrote:
>>> Hello guys!
>>> I am writing this message to hear if there is any progress,
>>> Enrico
>>>
>>>
>>> On Wed, 3 Dec 2014, Kevin Zhu wrote:
>>>
>>>> Date: Wed, 3 Dec 2014 07:05:37
>>>> From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
>>>> To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>> Cc: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>, Eli Britstein
>>>> <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
>>>> Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
>>>> Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
>>>> "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
>>>> "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
>>>> "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
>>>> Subject: Re: Is this 32-bit NCM?
>>>>
>>>> OK. I will. Thank you for everything!
>>>>
>>>> Regards,
>>>> Kevin
>>>>
>>>> On 12/03/2014 02:00 PM, Enrico Mioso wrote:
>>>>> Yes - I think this would be ok. You might try this with the 16-bit
>>>>> river first,
>>>>> and then with the 32-bit one to see how things work.
>>>>> I hope for the best.
>>>>> Let us all know,
>>>>> Enrico
>>>>>
>>>>>
>>>>> On Wed, 3 Dec 2014, Kevin Zhu wrote:
>>>>>
>>>>> ==Date: Wed, 3 Dec 2014 06:38:27
>>>>> ==From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
>>>>> ==To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>>> ==Cc: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>, Eli Britstein
>>>>> <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
>>>>> == Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
>>>>> == Midge Shaojun Tan <ShaojunMidge.Tan-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
>>>>> == "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
>>>>> == "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
>>>>> == "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
>>>>> ==Subject: Re: Is this 32-bit NCM?
>>>>> ==
>>>>> ==My dongle also works with the huawei driver. I think only the 32bit
>>>>> ==format and NDP location matter. We may modify the TX function to
>>>>> put NTH
>>>>> ==and NDP at the beginning of a NTB and see if it will work with the
>>>>> ==driver cdc_ncm.
>>>>> ==
>>>>> ==Regards,
>>>>> ==Kevin
>>>>> ==
>>>>> ==On 12/02/2014 11:28 PM, Enrico Mioso wrote:
>>>>> ==> ... And what do you think about the source code of their ndis
>>>>> driver?
>>>>> ==> We at least know now the device work with it, so we have
>>>>> something to mimic :D
>>>>> ==> thank you for your work and patience Kevin.
>>>>> ==>
>>>>> ==> On Tue, 2 Dec 2014, Kevin Zhu wrote:
>>>>> ==>
>>>>> ==> ==Date: Tue, 2 Dec 2014 16:04:25
>>>>> ==> ==From: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
>>>>> ==> ==To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Bjørn Mork
>>>>> <bjorn-yOkvZcmFvRU@public.gmane.org>
>>>>> ==> ==Cc: Eli Britstein <Eli.Britstein-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
>>>>> ==> == Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
>>>>> ==> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
>>>>> ==> == "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
>>>>> ==> == "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb-u79uwXL29TY@public.gmane.orgnel.org>,
>>>>> ==> == "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TaqPxH82wqD4g@public.gmane.orgg>
>>>>> ==> ==Subject: Re: Is this 32-bit NCM?
>>>>> ==> ==
>>>>> ==> ==I do not understand why the wSequence matters. By the way, I
>>>>> think I see some NDPs are right after NTH headers in the windows
>>>>> capture.
>>>>> ==> ==
>>>>> ==> ==________________________________________
>>>>> ==> ==From: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>>> ==> ==Sent: Tuesday, December 2, 2014 21:53
>>>>> ==> ==To: Bjørn Mork
>>>>> ==> ==Cc: Kevin Zhu; Eli Britstein; Alex Strizhevsky; Midge Shaojun
>>>>> Tan; youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
>>>>> netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>>>> ==> ==Subject: Re: Is this 32-bit NCM?
>>>>> ==> ==
>>>>> ==> ==Thank you very much Bjorn.
>>>>> ==> ==
>>>>> ==> ==
>>>>> ==> ==On Tue, 2 Dec 2014, Bjørn Mork wrote:
>>>>> ==> ==
>>>>> ==> ====Date: Tue, 2 Dec 2014 14:37:03
>>>>> ==> ====From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
>>>>> ==> ====To: Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>>> ==> ====Cc: Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>,
>>>>> ==> ==== Eli Britstein <Eli.Britstein@audiocodes.com>,
>>>>> ==> ==== Alex Strizhevsky <alexxst-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
>>>>> ==> ==== Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
>>>>> ==> ==== "youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
>>>>> ==> ==== "linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-usb@vger.kernel.org>,
>>>>> ==> ==== "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <netdev-u79uwXL29TY@public.gmane.orgnel.org>
>>>>> ==> ====Subject: Re: Is this 32-bit NCM?
>>>>> ==> ====
>>>>> ==> ====Enrico Mioso <mrkiko.rs-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>>>>> ==> ====
>>>>> ==> ====> ... but out of curiosity: are NCM specs allowing to change
>>>>> order of things in
>>>>> ==> ====> the package or not?
>>>>> ==> ====> This is not to start philosofical falames or something,
>>>>> but to understand
>>>>> ==> ====> better how things work. And, if they do: how much
>>>>> arbitrarily?
>>>>> ==> ====
>>>>> ==> ====Only the NTB header has a fixed location. The rest can be
>>>>> anywhere and
>>>>> ==> ====in any order. Quoting from section 3 Data Transport:
>>>>> ==> ====
>>>>> ==> ==== "Within any given NTB, the NTH always must be first; but
>>>>> the other
>>>>> ==> ==== items may occur in arbitrary order."
>>>>> ==> ====
>>>>> ==> ====
>>>>> ==> ====Bjørn
>>>>> ==> ====
>>>>> ==> ==This email and any files transmitted with it are confidential
>>>>> material. They are intended solely for the use of the designated
>>>>> individual or entity to whom they are addressed. If the reader of
>>>>> this message is not the intended recipient, you are hereby notified
>>>>> that any dissemination, use, distribution or copying of this
>>>>> communication is strictly prohibited and may be unlawful.
>>>>> ==> ==
>>>>> ==> ==If you have received this email in error please immediately
>>>>> notify the sender and delete or destroy any copy of this message
>>>>> ==> ==
>>>>> ==This email and any files transmitted with it are confidential
>>>>> material. They are intended solely for the use of the designated
>>>>> individual or entity to whom they are addressed. If the reader of
>>>>> this message is not the intended recipient, you are hereby notified
>>>>> that any dissemination, use, distribution or copying of this
>>>>> communication is strictly prohibited and may be unlawful.
>>>>> ==
>>>>> ==If you have received this email in error please immediately notify
>>>>> the sender and delete or destroy any copy of this message
>>>>> ==
>>>> This email and any files transmitted with it are confidential
>>>> material. They are intended solely for the use of the designated
>>>> individual or entity to whom they are addressed. If the reader of
>>>> this message is not the intended recipient, you are hereby notified
>>>> that any dissemination, use, distribution or copying of this
>>>> communication is strictly prohibited and may be unlawful.
>>>>
>>>> If you have received this email in error please immediately notify
>>>> the sender and delete or destroy any copy of this message
>>>>
>> This email and any files transmitted with it are confidential
>> material. They are intended solely for the use of the designated
>> individual or entity to whom they are addressed. If the reader of
>> this message is not the intended recipient, you are hereby notified
>> that any dissemination, use, distribution or copying of this
>> communication is strictly prohibited and may be unlawful.
>>
>> If you have received this email in error please immediately notify
>> the sender and delete or destroy any copy of this message
>>
This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [patch iproute2 6/6] bridge/link: add learning_sync policy flag
From: Jiri Pirko @ 2014-12-04 8:57 UTC (permalink / raw)
To: netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl, hemal
In-Reply-To: <1417683438-10935-1-git-send-email-jiri@resnulli.us>
From: Scott Feldman <sfeldma@gmail.com>
Add 'learned_sync' flag to turn on/off syncing of learned FDB entries from
offload device to bridge's FDB. Flag would be set/cleared in on SELF using
hwmode qualifier 'swdev'. E.g.:
$ sudo bridge link set dev swp1 hwmode swdev learning_sync on
$ bridge -d link show dev swp1
2: swp1 state UNKNOWN : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 2
hairpin off guard off root_block off fastleave off learning off flood off
2: swp1 state UNKNOWN : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0
learning on learning_sync on hwmode swdev
Adds new IFLA_BRPORT_LEARNING_SYNC attribute for IFLA_PROTINFO on the SELF
brport.
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
bridge/link.c | 11 +++++++++++
include/linux/if_link.h | 1 +
man/man8/bridge.8 | 6 ++++++
3 files changed, 18 insertions(+)
diff --git a/bridge/link.c b/bridge/link.c
index efe0b8c..0f8649f 100644
--- a/bridge/link.c
+++ b/bridge/link.c
@@ -188,6 +188,9 @@ int print_linkinfo(const struct sockaddr_nl *who,
if (prtb[IFLA_BRPORT_LEARNING])
print_onoff(fp, "learning",
rta_getattr_u8(prtb[IFLA_BRPORT_LEARNING]));
+ if (prtb[IFLA_BRPORT_LEARNING_SYNC])
+ print_onoff(fp, "learning_sync",
+ rta_getattr_u8(prtb[IFLA_BRPORT_LEARNING_SYNC]));
if (prtb[IFLA_BRPORT_UNICAST_FLOOD])
print_onoff(fp, "flood",
rta_getattr_u8(prtb[IFLA_BRPORT_UNICAST_FLOOD]));
@@ -221,6 +224,7 @@ static void usage(void)
fprintf(stderr, " [ fastleave {on | off} ]\n");
fprintf(stderr, " [ root_block {on | off} ]\n");
fprintf(stderr, " [ learning {on | off} ]\n");
+ fprintf(stderr, " [ learning_sync {on | off} ]\n");
fprintf(stderr, " [ flood {on | off} ]\n");
fprintf(stderr, " [ hwmode {vepa | veb} ]\n");
fprintf(stderr, " bridge link show [dev DEV]\n");
@@ -252,6 +256,7 @@ static int brlink_modify(int argc, char **argv)
} req;
char *d = NULL;
__s8 learning = -1;
+ __s8 learning_sync = -1;
__s8 flood = -1;
__s8 hairpin = -1;
__s8 bpdu_guard = -1;
@@ -295,6 +300,10 @@ static int brlink_modify(int argc, char **argv)
NEXT_ARG();
if (!on_off("learning", &learning, *argv))
exit(-1);
+ } else if (strcmp(*argv, "learning_sync") == 0) {
+ NEXT_ARG();
+ if (!on_off("learning_sync", &learning_sync, *argv))
+ exit(-1);
} else if (strcmp(*argv, "flood") == 0) {
NEXT_ARG();
if (!on_off("flood", &flood, *argv))
@@ -359,6 +368,8 @@ static int brlink_modify(int argc, char **argv)
addattr8(&req.n, sizeof(req), IFLA_BRPORT_UNICAST_FLOOD, flood);
if (learning >= 0)
addattr8(&req.n, sizeof(req), IFLA_BRPORT_LEARNING, learning);
+ if (learning_sync >= 0)
+ addattr8(&req.n, sizeof(req), IFLA_BRPORT_LEARNING_SYNC, learning_sync);
if (cost > 0)
addattr32(&req.n, sizeof(req), IFLA_BRPORT_COST, cost);
diff --git a/include/linux/if_link.h b/include/linux/if_link.h
index 06efa2d..9947f1b 100644
--- a/include/linux/if_link.h
+++ b/include/linux/if_link.h
@@ -243,6 +243,7 @@ enum {
IFLA_BRPORT_LEARNING, /* mac learning */
IFLA_BRPORT_UNICAST_FLOOD, /* flood unicast traffic */
IFLA_BRPORT_PROXYARP, /* proxy ARP */
+ IFLA_BRPORT_LEARNING_SYNC, /* mac learning sync from device */
__IFLA_BRPORT_MAX
};
#define IFLA_BRPORT_MAX (__IFLA_BRPORT_MAX - 1)
diff --git a/man/man8/bridge.8 b/man/man8/bridge.8
index d3d64d1..83c049a 100644
--- a/man/man8/bridge.8
+++ b/man/man8/bridge.8
@@ -37,6 +37,7 @@ bridge \- show / manipulate bridge addresses and devices
.BR fastleave " { " on " | " off " } ] [ "
.BR root_block " { " on " | " off " } ] [ "
.BR learning " { " on " | " off " } ] [ "
+.BR learning_sync " { " on " | " off " } ] [ "
.BR flood " { " on " | " off " } ] [ "
.BR hwmode " { " vepa " | " veb " | " swdev " } ] "
@@ -242,6 +243,11 @@ not. If learning if off, the bridge will end up flooding any traffic for which
it has no FDB entry. By default this flag is on.
.TP
+.BR "learning_sync on " or " learning_sync off "
+Controls whether a given port will sync MAC addresses learned on device port
+to bridge FDB. This flags applies to device ports in "swdev" hwmode.
+
+.TP
.BR "flooding on " or " flooding off "
Controls whether a given port will flood unicast traffic for which there is no FDB entry. By default this flag is on.
--
1.9.3
^ permalink raw reply related
* [patch iproute2 4/6] bridge/link: add new offload hwmode swdev
From: Jiri Pirko @ 2014-12-04 8:57 UTC (permalink / raw)
To: netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl, hemal
In-Reply-To: <1417683438-10935-1-git-send-email-jiri@resnulli.us>
From: Scott Feldman <sfeldma@gmail.com>
To support full-featured switch devices offloading bridge funtionality,
add new hwmode 'swdev'. Like 'vepa' and 'veb', 'swdev' indicated bridge
port functionality is being offloaded to hardware.
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
bridge/link.c | 6 ++++--
include/linux/if_bridge.h | 1 +
man/man8/bridge.8 | 13 ++++++++-----
3 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/bridge/link.c b/bridge/link.c
index 90d9e7f..efe0b8c 100644
--- a/bridge/link.c
+++ b/bridge/link.c
@@ -65,7 +65,7 @@ static const char *oper_states[] = {
"TESTING", "DORMANT", "UP"
};
-static const char *hw_mode[] = {"VEB", "VEPA"};
+static const char *hw_mode[] = {"VEB", "VEPA", "swdev"};
static void print_operstate(FILE *f, __u8 state)
{
@@ -315,10 +315,12 @@ static int brlink_modify(int argc, char **argv)
mode = BRIDGE_MODE_VEPA;
else if (strcmp(*argv, "veb") == 0)
mode = BRIDGE_MODE_VEB;
+ else if (strcmp(*argv, "swdev") == 0)
+ mode = BRIDGE_MODE_SWDEV;
else {
fprintf(stderr,
"Mode argument must be \"vepa\" or "
- "\"veb\".\n");
+ "\"veb\" or \"swdev\".\n");
exit(-1);
}
} else {
diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
index ed6868e..6b4eb66 100644
--- a/include/linux/if_bridge.h
+++ b/include/linux/if_bridge.h
@@ -105,6 +105,7 @@ struct __fdb_entry {
#define BRIDGE_MODE_VEB 0 /* Default loopback mode */
#define BRIDGE_MODE_VEPA 1 /* 802.1Qbg defined VEPA mode */
+#define BRIDGE_MODE_SWDEV 2 /* Full switch device offload */
/* Bridge management nested attributes
* [IFLA_AF_SPEC] = {
diff --git a/man/man8/bridge.8 b/man/man8/bridge.8
index af31d41..d3d64d1 100644
--- a/man/man8/bridge.8
+++ b/man/man8/bridge.8
@@ -38,7 +38,7 @@ bridge \- show / manipulate bridge addresses and devices
.BR root_block " { " on " | " off " } ] [ "
.BR learning " { " on " | " off " } ] [ "
.BR flood " { " on " | " off " } ] [ "
-.BR hwmode " { " vepa " | " veb " } ] "
+.BR hwmode " { " vepa " | " veb " | " swdev " } ] "
.ti -8
.BR "bridge link" " [ " show " ] [ "
@@ -247,15 +247,18 @@ Controls whether a given port will flood unicast traffic for which there is no F
.TP
.BI hwmode
-Some network interface cards support HW bridge functionality and they may be
+Some port devices support HW bridge functionality and they may be
configured in different modes. Currently support modes are:
.B vepa
-- Data sent between HW ports is sent on the wire to the external
-switch.
+- NIC interface supports VEPA: data sent between HW ports is sent on
+the wire to the external switch.
.B veb
-- bridging happens in hardware.
+- NIC interface supports VEB: bridging happens in hardware.
+
+.B swdev
+- Full Ethernet switch offload device: bridging happens in hardware.
.SS bridge link show - list bridge port configuration.
--
1.9.3
^ permalink raw reply related
* [patch iproute2 5/6] link: add missing IFLA_BRPORT_PROXYARP
From: Jiri Pirko @ 2014-12-04 8:57 UTC (permalink / raw)
To: netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl, hemal
In-Reply-To: <1417683438-10935-1-git-send-email-jiri@resnulli.us>
From: Scott Feldman <sfeldma@gmail.com>
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
include/linux/if_link.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/if_link.h b/include/linux/if_link.h
index a6e2594..06efa2d 100644
--- a/include/linux/if_link.h
+++ b/include/linux/if_link.h
@@ -242,6 +242,7 @@ enum {
IFLA_BRPORT_FAST_LEAVE, /* multicast fast leave */
IFLA_BRPORT_LEARNING, /* mac learning */
IFLA_BRPORT_UNICAST_FLOOD, /* flood unicast traffic */
+ IFLA_BRPORT_PROXYARP, /* proxy ARP */
__IFLA_BRPORT_MAX
};
#define IFLA_BRPORT_MAX (__IFLA_BRPORT_MAX - 1)
--
1.9.3
^ permalink raw reply related
* [patch iproute2 3/6] bridge/fdb: add flag/indication for FDB entry synced from offload device
From: Jiri Pirko @ 2014-12-04 8:57 UTC (permalink / raw)
To: netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl, hemal
In-Reply-To: <1417683438-10935-1-git-send-email-jiri@resnulli.us>
From: Scott Feldman <sfeldma@gmail.com>
Add NTF_EXT_LEARNED flag to neigh flags to indicate FDB entry learned by
device has been learned externally to bridge FDB. For these entries,
add "external" annotation in bridge fdb show output:
00:02:00:00:03:00 dev swp2 used 2/2 master br0 external
00:02:00:00:03:00 dev swp2 self permanent
In the example above, 00:02:00:00:03:00 is shown twice on dev swp2. The
first entry if from the bridge (master) and is marked as "external" by
the offload device. The second entry is from the brport offload device (self),
and was learned by the device.
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
bridge/fdb.c | 2 ++
include/linux/neighbour.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/bridge/fdb.c b/bridge/fdb.c
index d678342..c01a502 100644
--- a/bridge/fdb.c
+++ b/bridge/fdb.c
@@ -154,6 +154,8 @@ int print_fdb(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
fprintf(fp, "master ");
if (r->ndm_flags & NTF_ROUTER)
fprintf(fp, "router ");
+ if (r->ndm_flags & NTF_EXT_LEARNED)
+ fprintf(fp, "external ");
fprintf(fp, "%s\n", state_n2a(r->ndm_state));
return 0;
diff --git a/include/linux/neighbour.h b/include/linux/neighbour.h
index 4a1d7e9..3a9b0df 100644
--- a/include/linux/neighbour.h
+++ b/include/linux/neighbour.h
@@ -40,6 +40,7 @@ enum {
#define NTF_SELF 0x02
#define NTF_MASTER 0x04
+#define NTF_EXT_LEARNED 0x10
/*
* Neighbor Cache Entry States.
--
1.9.3
^ permalink raw reply related
* [patch iproute2 2/6] bridge/fdb: fix statistics output spacing
From: Jiri Pirko @ 2014-12-04 8:57 UTC (permalink / raw)
To: netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl, hemal
In-Reply-To: <1417683438-10935-1-git-send-email-jiri@resnulli.us>
From: Scott Feldman <sfeldma@gmail.com>
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
bridge/fdb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bridge/fdb.c b/bridge/fdb.c
index a55fac1..d678342 100644
--- a/bridge/fdb.c
+++ b/bridge/fdb.c
@@ -142,7 +142,7 @@ int print_fdb(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
struct nda_cacheinfo *ci = RTA_DATA(tb[NDA_CACHEINFO]);
int hz = get_user_hz();
- fprintf(fp, " used %d/%d", ci->ndm_used/hz,
+ fprintf(fp, "used %d/%d ", ci->ndm_used/hz,
ci->ndm_updated/hz);
}
if (r->ndm_flags & NTF_SELF)
--
1.9.3
^ permalink raw reply related
* [patch iproute2 1/6] iproute2: ipa: show switch id
From: Jiri Pirko @ 2014-12-04 8:57 UTC (permalink / raw)
To: netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl, hemal
In-Reply-To: <1417683438-10935-1-git-send-email-jiri@resnulli.us>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
---
include/linux/if_link.h | 1 +
ip/ipaddress.c | 8 ++++++++
2 files changed, 9 insertions(+)
diff --git a/include/linux/if_link.h b/include/linux/if_link.h
index 4732063..a6e2594 100644
--- a/include/linux/if_link.h
+++ b/include/linux/if_link.h
@@ -145,6 +145,7 @@ enum {
IFLA_CARRIER,
IFLA_PHYS_PORT_ID,
IFLA_CARRIER_CHANGES,
+ IFLA_PHYS_SWITCH_ID,
__IFLA_MAX
};
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index 4d99324..bd36a07 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -589,6 +589,14 @@ int print_linkinfo(const struct sockaddr_nl *who,
b1, sizeof(b1)));
}
+ if (tb[IFLA_PHYS_SWITCH_ID]) {
+ SPRINT_BUF(b1);
+ fprintf(fp, "switchid %s ",
+ hexstring_n2a(RTA_DATA(tb[IFLA_PHYS_SWITCH_ID]),
+ RTA_PAYLOAD(tb[IFLA_PHYS_SWITCH_ID]),
+ b1, sizeof(b1)));
+ }
+
if (tb[IFLA_OPERSTATE])
print_operstate(fp, rta_getattr_u8(tb[IFLA_OPERSTATE]));
--
1.9.3
^ permalink raw reply related
* [patch iproute2 0/6] iproute2: add changes for switchdev
From: Jiri Pirko @ 2014-12-04 8:57 UTC (permalink / raw)
To: netdev
Cc: davem, nhorman, andy, tgraf, dborkman, ogerlitz, jesse, pshelar,
azhou, ben, stephen, jeffrey.t.kirsher, vyasevic, xiyou.wangcong,
john.r.fastabend, edumazet, jhs, sfeldma, f.fainelli, roopa,
linville, jasowang, ebiederm, nicolas.dichtel, ryazanov.s.a,
buytenh, aviadr, nbd, alexei.starovoitov, Neil.Jerram, ronye,
simon.horman, alexander.h.duyck, john.ronciak, mleitner, shrijeet,
gospo, bcrl, hemal
Jiri Pirko (1):
iproute2: ipa: show switch id
Scott Feldman (5):
bridge/fdb: fix statistics output spacing
bridge/fdb: add flag/indication for FDB entry synced from offload
device
bridge/link: add new offload hwmode swdev
link: add missing IFLA_BRPORT_PROXYARP
bridge/link: add learning_sync policy flag
bridge/fdb.c | 4 +++-
bridge/link.c | 17 +++++++++++++++--
include/linux/if_bridge.h | 1 +
include/linux/if_link.h | 3 +++
include/linux/neighbour.h | 1 +
ip/ipaddress.c | 8 ++++++++
man/man8/bridge.8 | 19 ++++++++++++++-----
7 files changed, 45 insertions(+), 8 deletions(-)
--
1.9.3
^ permalink raw reply
* Re: ipip6 - integer underrun when handlince icmpv4 unreachable messages
From: Steffen Klassert @ 2014-12-04 8:56 UTC (permalink / raw)
To: Alexander Wetzel; +Cc: netdev, roque, kuznet, r.venning, nate
In-Reply-To: <546A6E04.30603@web.de>
On Mon, Nov 17, 2014 at 10:52:04PM +0100, Alexander Wetzel wrote:
> Hello netdev,
>
> the current code to translate icmpv4 "destination unreachable" packets
> to icmpv6 is later generating an integer underrun when calling
> icmpv6_send, by later calling skb_network_header_len and subtracting a
> bigger number from a lower one.
I'd guess the call to skb_network_header_len() in _decode_session6()
is the problematic one, right?
>
> The issue is not visible for vanilla kernels and works correctly from
> a user perspective, but a kernel with the PAX patches and enabled
> "size overflow protection" will panic immediately when it's getting an
> icmpv4 destination unreachable packet back for an encapsulated ipv6
> packet. (Remote tunnel endpoint not reachable.)
>
> I think I've tracked the issue down and can show you the problem with
> the code... as I understand it as non-programmer greping the sources
> and googeling functions. I was even able to find a fix which passes
> the functionality test, but I'm unqualified to rate the correctness of
> it and so are reaching out to you for that.
>
> What happens (output of printk's) with transport_header and
> network_header around "skb_reset_network_header" is described below
> the function.
>
> Near the end of the mail there are two links to the gentoo bug tracker
> and pax forum, suggesting to put this forward to the lkml/netdev for
> review, also including more details on the panics.
>
> So here the function "ipip6_err_gen_icmpv6_unreach" from
> net/ipv6/sit.c with some remarks and one new line which seems to fix
> the problem:
>
> ************************************************************************
> static int ipip6_err_gen_icmpv6_unreach(struct sk_buff *skb)
> {
> int ihl = ((const struct iphdr *)skb->data)->ihl*4;
> struct rt6_info *rt;
> struct sk_buff *skb2;
>
> if (!pskb_may_pull(skb, ihl + sizeof(struct ipv6hdr) + 8))
> return 1;
>
> // we clone the ipv4 skb in skb2 to prepare the icmpv6 packet
> skb2 = skb_clone(skb, GFP_ATOMIC);
>
> if (!skb2)
> return 1;
>
> // we clean up the cloned skb2
> skb_dst_drop(skb2);
> skb_pull(skb2, ihl);
> // The network header is reset
> skb_reset_network_header(skb2);
>
> //THE PROPOSED FIX: The following line is NOT in the current code
> skb_reset_transport_header(skb2);
This will make your panic with PAX go away, but the offset to
the transport header is still wrong. Also, it is not just the
sit tunnel that has this problem. All ipv6 tunnels are affected.
I think the easiest is to fix it in _decode_session6().
Could you please try the patch below?
Subject: [PATCH] xfrm6: Fix transport header offset in _decode_session6.
skb->transport_header might not be valid when we do a reverse
decode because the ipv6 tunnel error handlers don't update it
to the inner transport header. This leads to a wrong offset
calculation and to wrong layer 4 informations. We fix this
by using the size of the ipv6 header as the first offset.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/ipv6/xfrm6_policy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/xfrm6_policy.c b/net/ipv6/xfrm6_policy.c
index ac49f84..576fc42 100644
--- a/net/ipv6/xfrm6_policy.c
+++ b/net/ipv6/xfrm6_policy.c
@@ -130,8 +130,8 @@ _decode_session6(struct sk_buff *skb, struct flowi *fl, int reverse)
{
struct flowi6 *fl6 = &fl->u.ip6;
int onlyproto = 0;
- u16 offset = skb_network_header_len(skb);
const struct ipv6hdr *hdr = ipv6_hdr(skb);
+ u16 offset = sizeof(*hdr);
struct ipv6_opt_hdr *exthdr;
const unsigned char *nh = skb_network_header(skb);
u8 nexthdr = nh[IP6CB(skb)->nhoff];
--
1.9.1
^ permalink raw reply related
* Re: Is this 32-bit NCM?y
From: Enrico Mioso @ 2014-12-04 8:56 UTC (permalink / raw)
To: Kevin Zhu
Cc: Bjørn Mork, Eli Britstein, Alex Strizhevsky,
Midge Shaojun Tan, youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <548020DD.3030705@audiocodes.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 8746 bytes --]
Hi Kevin.
Thank you for your hints and work.
Only a note - why disabling ARP? I think it could be a good iea... or does the hw_cdc_driver do that?
thank you again,
Enrico
On Thu, 4 Dec 2014, Kevin Zhu wrote:
> Date: Thu, 4 Dec 2014 09:52:49
> From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
> To: Enrico Mioso <mrkiko.rs@gmail.com>
> Cc: Bjørn Mork <bjorn@mork.no>, Eli Britstein <Eli.Britstein@audiocodes.com>,
> Alex Strizhevsky <alexxst@gmail.com>,
> Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
> "youtux@gmail.com" <youtux@gmail.com>,
> "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
> "netdev@vger.kernel.org" <netdev@vger.kernel.org>
> Subject: Re: Is this 32-bit NCM?y
>
> Guys,
>
> After rearranging the padding, putting NCM0 right after NTH, and disable
> ARP (FLAG_NOARP) and handling the offset alignment issue, it seems it
> begins to work, though there's still problem with DHCP. It's able to
> ping, though my Ubuntu network manage does not notice this network
> interface. So no DNS.
>
> I have to specify the network interface and IP in the ping command.
>
> The DHCP packet's size becomes a large one after the TX function, which
> is 16384, the maximum. And the dongle does not reply it in time. For
> now, I just simple rearrange the code to meet Huawei's alignment
> requirement. I think other devices may be different, regarding the
> 'offset' definition. We may need to handle it. And also need to double
> check if the code has bugs.
>
> Regards,
> Kevin
>
> On 12/04/2014 02:31 PM, Enrico Mioso wrote:
>> Hello guys!
>> I am writing this message to hear if there is any progress,
>> Enrico
>>
>>
>> On Wed, 3 Dec 2014, Kevin Zhu wrote:
>>
>>> Date: Wed, 3 Dec 2014 07:05:37
>>> From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
>>> To: Enrico Mioso <mrkiko.rs@gmail.com>
>>> Cc: Bjørn Mork <bjorn@mork.no>, Eli Britstein
>>> <Eli.Britstein@audiocodes.com>,
>>> Alex Strizhevsky <alexxst@gmail.com>,
>>> Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
>>> "youtux@gmail.com" <youtux@gmail.com>,
>>> "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
>>> "netdev@vger.kernel.org" <netdev@vger.kernel.org>
>>> Subject: Re: Is this 32-bit NCM?
>>>
>>> OK. I will. Thank you for everything!
>>>
>>> Regards,
>>> Kevin
>>>
>>> On 12/03/2014 02:00 PM, Enrico Mioso wrote:
>>>> Yes - I think this would be ok. You might try this with the 16-bit
>>>> river first,
>>>> and then with the 32-bit one to see how things work.
>>>> I hope for the best.
>>>> Let us all know,
>>>> Enrico
>>>>
>>>>
>>>> On Wed, 3 Dec 2014, Kevin Zhu wrote:
>>>>
>>>> ==Date: Wed, 3 Dec 2014 06:38:27
>>>> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
>>>> ==To: Enrico Mioso <mrkiko.rs@gmail.com>
>>>> ==Cc: Bjørn Mork <bjorn@mork.no>, Eli Britstein
>>>> <Eli.Britstein@audiocodes.com>,
>>>> == Alex Strizhevsky <alexxst@gmail.com>,
>>>> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
>>>> == "youtux@gmail.com" <youtux@gmail.com>,
>>>> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
>>>> == "netdev@vger.kernel.org" <netdev@vger.kernel.org>
>>>> ==Subject: Re: Is this 32-bit NCM?
>>>> ==
>>>> ==My dongle also works with the huawei driver. I think only the 32bit
>>>> ==format and NDP location matter. We may modify the TX function to
>>>> put NTH
>>>> ==and NDP at the beginning of a NTB and see if it will work with the
>>>> ==driver cdc_ncm.
>>>> ==
>>>> ==Regards,
>>>> ==Kevin
>>>> ==
>>>> ==On 12/02/2014 11:28 PM, Enrico Mioso wrote:
>>>> ==> ... And what do you think about the source code of their ndis
>>>> driver?
>>>> ==> We at least know now the device work with it, so we have
>>>> something to mimic :D
>>>> ==> thank you for your work and patience Kevin.
>>>> ==>
>>>> ==> On Tue, 2 Dec 2014, Kevin Zhu wrote:
>>>> ==>
>>>> ==> ==Date: Tue, 2 Dec 2014 16:04:25
>>>> ==> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
>>>> ==> ==To: Enrico Mioso <mrkiko.rs@gmail.com>, Bjørn Mork
>>>> <bjorn@mork.no>
>>>> ==> ==Cc: Eli Britstein <Eli.Britstein@audiocodes.com>,
>>>> ==> == Alex Strizhevsky <alexxst@gmail.com>,
>>>> ==> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
>>>> ==> == "youtux@gmail.com" <youtux@gmail.com>,
>>>> ==> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
>>>> ==> == "netdev@vger.kernel.org" <netdev@vger.kernel.org>
>>>> ==> ==Subject: Re: Is this 32-bit NCM?
>>>> ==> ==
>>>> ==> ==I do not understand why the wSequence matters. By the way, I
>>>> think I see some NDPs are right after NTH headers in the windows
>>>> capture.
>>>> ==> ==
>>>> ==> ==________________________________________
>>>> ==> ==From: Enrico Mioso <mrkiko.rs@gmail.com>
>>>> ==> ==Sent: Tuesday, December 2, 2014 21:53
>>>> ==> ==To: Bjørn Mork
>>>> ==> ==Cc: Kevin Zhu; Eli Britstein; Alex Strizhevsky; Midge Shaojun
>>>> Tan; youtux@gmail.com; linux-usb@vger.kernel.org;
>>>> netdev@vger.kernel.org
>>>> ==> ==Subject: Re: Is this 32-bit NCM?
>>>> ==> ==
>>>> ==> ==Thank you very much Bjorn.
>>>> ==> ==
>>>> ==> ==
>>>> ==> ==On Tue, 2 Dec 2014, Bjørn Mork wrote:
>>>> ==> ==
>>>> ==> ====Date: Tue, 2 Dec 2014 14:37:03
>>>> ==> ====From: Bjørn Mork <bjorn@mork.no>
>>>> ==> ====To: Enrico Mioso <mrkiko.rs@gmail.com>
>>>> ==> ====Cc: Kevin Zhu <Mingying.Zhu@audiocodes.com>,
>>>> ==> ==== Eli Britstein <Eli.Britstein@audiocodes.com>,
>>>> ==> ==== Alex Strizhevsky <alexxst@gmail.com>,
>>>> ==> ==== Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
>>>> ==> ==== "youtux@gmail.com" <youtux@gmail.com>,
>>>> ==> ==== "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
>>>> ==> ==== "netdev@vger.kernel.org" <netdev@vger.kernel.org>
>>>> ==> ====Subject: Re: Is this 32-bit NCM?
>>>> ==> ====
>>>> ==> ====Enrico Mioso <mrkiko.rs@gmail.com> writes:
>>>> ==> ====
>>>> ==> ====> ... but out of curiosity: are NCM specs allowing to change
>>>> order of things in
>>>> ==> ====> the package or not?
>>>> ==> ====> This is not to start philosofical falames or something,
>>>> but to understand
>>>> ==> ====> better how things work. And, if they do: how much
>>>> arbitrarily?
>>>> ==> ====
>>>> ==> ====Only the NTB header has a fixed location. The rest can be
>>>> anywhere and
>>>> ==> ====in any order. Quoting from section 3 Data Transport:
>>>> ==> ====
>>>> ==> ==== "Within any given NTB, the NTH always must be first; but
>>>> the other
>>>> ==> ==== items may occur in arbitrary order."
>>>> ==> ====
>>>> ==> ====
>>>> ==> ====Bjørn
>>>> ==> ====
>>>> ==> ==This email and any files transmitted with it are confidential
>>>> material. They are intended solely for the use of the designated
>>>> individual or entity to whom they are addressed. If the reader of
>>>> this message is not the intended recipient, you are hereby notified
>>>> that any dissemination, use, distribution or copying of this
>>>> communication is strictly prohibited and may be unlawful.
>>>> ==> ==
>>>> ==> ==If you have received this email in error please immediately
>>>> notify the sender and delete or destroy any copy of this message
>>>> ==> ==
>>>> ==This email and any files transmitted with it are confidential
>>>> material. They are intended solely for the use of the designated
>>>> individual or entity to whom they are addressed. If the reader of
>>>> this message is not the intended recipient, you are hereby notified
>>>> that any dissemination, use, distribution or copying of this
>>>> communication is strictly prohibited and may be unlawful.
>>>> ==
>>>> ==If you have received this email in error please immediately notify
>>>> the sender and delete or destroy any copy of this message
>>>> ==
>>> This email and any files transmitted with it are confidential
>>> material. They are intended solely for the use of the designated
>>> individual or entity to whom they are addressed. If the reader of
>>> this message is not the intended recipient, you are hereby notified
>>> that any dissemination, use, distribution or copying of this
>>> communication is strictly prohibited and may be unlawful.
>>>
>>> If you have received this email in error please immediately notify
>>> the sender and delete or destroy any copy of this message
>>>
> This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
>
> If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
>
^ permalink raw reply
* Re: Is this 32-bit NCM?y
From: Kevin Zhu @ 2014-12-04 8:52 UTC (permalink / raw)
To: Enrico Mioso
Cc: Bjørn Mork, Eli Britstein, Alex Strizhevsky,
Midge Shaojun Tan, youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <alpine.LNX.2.03.1412040730480.1320@gmail.com>
Guys,
After rearranging the padding, putting NCM0 right after NTH, and disable
ARP (FLAG_NOARP) and handling the offset alignment issue, it seems it
begins to work, though there's still problem with DHCP. It's able to
ping, though my Ubuntu network manage does not notice this network
interface. So no DNS.
I have to specify the network interface and IP in the ping command.
The DHCP packet's size becomes a large one after the TX function, which
is 16384, the maximum. And the dongle does not reply it in time. For
now, I just simple rearrange the code to meet Huawei's alignment
requirement. I think other devices may be different, regarding the
'offset' definition. We may need to handle it. And also need to double
check if the code has bugs.
Regards,
Kevin
On 12/04/2014 02:31 PM, Enrico Mioso wrote:
> Hello guys!
> I am writing this message to hear if there is any progress,
> Enrico
>
>
> On Wed, 3 Dec 2014, Kevin Zhu wrote:
>
>> Date: Wed, 3 Dec 2014 07:05:37
>> From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
>> To: Enrico Mioso <mrkiko.rs@gmail.com>
>> Cc: Bjørn Mork <bjorn@mork.no>, Eli Britstein
>> <Eli.Britstein@audiocodes.com>,
>> Alex Strizhevsky <alexxst@gmail.com>,
>> Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
>> "youtux@gmail.com" <youtux@gmail.com>,
>> "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
>> "netdev@vger.kernel.org" <netdev@vger.kernel.org>
>> Subject: Re: Is this 32-bit NCM?
>>
>> OK. I will. Thank you for everything!
>>
>> Regards,
>> Kevin
>>
>> On 12/03/2014 02:00 PM, Enrico Mioso wrote:
>>> Yes - I think this would be ok. You might try this with the 16-bit
>>> river first,
>>> and then with the 32-bit one to see how things work.
>>> I hope for the best.
>>> Let us all know,
>>> Enrico
>>>
>>>
>>> On Wed, 3 Dec 2014, Kevin Zhu wrote:
>>>
>>> ==Date: Wed, 3 Dec 2014 06:38:27
>>> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
>>> ==To: Enrico Mioso <mrkiko.rs@gmail.com>
>>> ==Cc: Bjørn Mork <bjorn@mork.no>, Eli Britstein
>>> <Eli.Britstein@audiocodes.com>,
>>> == Alex Strizhevsky <alexxst@gmail.com>,
>>> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
>>> == "youtux@gmail.com" <youtux@gmail.com>,
>>> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
>>> == "netdev@vger.kernel.org" <netdev@vger.kernel.org>
>>> ==Subject: Re: Is this 32-bit NCM?
>>> ==
>>> ==My dongle also works with the huawei driver. I think only the 32bit
>>> ==format and NDP location matter. We may modify the TX function to
>>> put NTH
>>> ==and NDP at the beginning of a NTB and see if it will work with the
>>> ==driver cdc_ncm.
>>> ==
>>> ==Regards,
>>> ==Kevin
>>> ==
>>> ==On 12/02/2014 11:28 PM, Enrico Mioso wrote:
>>> ==> ... And what do you think about the source code of their ndis
>>> driver?
>>> ==> We at least know now the device work with it, so we have
>>> something to mimic :D
>>> ==> thank you for your work and patience Kevin.
>>> ==>
>>> ==> On Tue, 2 Dec 2014, Kevin Zhu wrote:
>>> ==>
>>> ==> ==Date: Tue, 2 Dec 2014 16:04:25
>>> ==> ==From: Kevin Zhu <Mingying.Zhu@audiocodes.com>
>>> ==> ==To: Enrico Mioso <mrkiko.rs@gmail.com>, Bjørn Mork
>>> <bjorn@mork.no>
>>> ==> ==Cc: Eli Britstein <Eli.Britstein@audiocodes.com>,
>>> ==> == Alex Strizhevsky <alexxst@gmail.com>,
>>> ==> == Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
>>> ==> == "youtux@gmail.com" <youtux@gmail.com>,
>>> ==> == "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
>>> ==> == "netdev@vger.kernel.org" <netdev@vger.kernel.org>
>>> ==> ==Subject: Re: Is this 32-bit NCM?
>>> ==> ==
>>> ==> ==I do not understand why the wSequence matters. By the way, I
>>> think I see some NDPs are right after NTH headers in the windows
>>> capture.
>>> ==> ==
>>> ==> ==________________________________________
>>> ==> ==From: Enrico Mioso <mrkiko.rs@gmail.com>
>>> ==> ==Sent: Tuesday, December 2, 2014 21:53
>>> ==> ==To: Bjørn Mork
>>> ==> ==Cc: Kevin Zhu; Eli Britstein; Alex Strizhevsky; Midge Shaojun
>>> Tan; youtux@gmail.com; linux-usb@vger.kernel.org;
>>> netdev@vger.kernel.org
>>> ==> ==Subject: Re: Is this 32-bit NCM?
>>> ==> ==
>>> ==> ==Thank you very much Bjorn.
>>> ==> ==
>>> ==> ==
>>> ==> ==On Tue, 2 Dec 2014, Bjørn Mork wrote:
>>> ==> ==
>>> ==> ====Date: Tue, 2 Dec 2014 14:37:03
>>> ==> ====From: Bjørn Mork <bjorn@mork.no>
>>> ==> ====To: Enrico Mioso <mrkiko.rs@gmail.com>
>>> ==> ====Cc: Kevin Zhu <Mingying.Zhu@audiocodes.com>,
>>> ==> ==== Eli Britstein <Eli.Britstein@audiocodes.com>,
>>> ==> ==== Alex Strizhevsky <alexxst@gmail.com>,
>>> ==> ==== Midge Shaojun Tan <ShaojunMidge.Tan@audiocodes.com>,
>>> ==> ==== "youtux@gmail.com" <youtux@gmail.com>,
>>> ==> ==== "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
>>> ==> ==== "netdev@vger.kernel.org" <netdev@vger.kernel.org>
>>> ==> ====Subject: Re: Is this 32-bit NCM?
>>> ==> ====
>>> ==> ====Enrico Mioso <mrkiko.rs@gmail.com> writes:
>>> ==> ====
>>> ==> ====> ... but out of curiosity: are NCM specs allowing to change
>>> order of things in
>>> ==> ====> the package or not?
>>> ==> ====> This is not to start philosofical falames or something,
>>> but to understand
>>> ==> ====> better how things work. And, if they do: how much
>>> arbitrarily?
>>> ==> ====
>>> ==> ====Only the NTB header has a fixed location. The rest can be
>>> anywhere and
>>> ==> ====in any order. Quoting from section 3 Data Transport:
>>> ==> ====
>>> ==> ==== "Within any given NTB, the NTH always must be first; but
>>> the other
>>> ==> ==== items may occur in arbitrary order."
>>> ==> ====
>>> ==> ====
>>> ==> ====Bjørn
>>> ==> ====
>>> ==> ==This email and any files transmitted with it are confidential
>>> material. They are intended solely for the use of the designated
>>> individual or entity to whom they are addressed. If the reader of
>>> this message is not the intended recipient, you are hereby notified
>>> that any dissemination, use, distribution or copying of this
>>> communication is strictly prohibited and may be unlawful.
>>> ==> ==
>>> ==> ==If you have received this email in error please immediately
>>> notify the sender and delete or destroy any copy of this message
>>> ==> ==
>>> ==This email and any files transmitted with it are confidential
>>> material. They are intended solely for the use of the designated
>>> individual or entity to whom they are addressed. If the reader of
>>> this message is not the intended recipient, you are hereby notified
>>> that any dissemination, use, distribution or copying of this
>>> communication is strictly prohibited and may be unlawful.
>>> ==
>>> ==If you have received this email in error please immediately notify
>>> the sender and delete or destroy any copy of this message
>>> ==
>> This email and any files transmitted with it are confidential
>> material. They are intended solely for the use of the designated
>> individual or entity to whom they are addressed. If the reader of
>> this message is not the intended recipient, you are hereby notified
>> that any dissemination, use, distribution or copying of this
>> communication is strictly prohibited and may be unlawful.
>>
>> If you have received this email in error please immediately notify
>> the sender and delete or destroy any copy of this message
>>
This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.
If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message
^ permalink raw reply
* Re: [PATCH] uapi: fix to export linux/vm_sockets.h
From: Masahiro Yamada @ 2014-12-04 8:15 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Stephen Hemminger, David S. Miller,
Greg Kroah-Hartman, Alexei Starovoitov, Piotr Krol, Andrew Morton,
Sakari Ailus, linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1417396577-32499-1-git-send-email-yamada.m-NAum8xwdG0+S7A1Ibl2khg@public.gmane.org>
Hi.
Is there a chance to fix this by the Linux 3.18 release?
Thanks.
On Mon, 1 Dec 2014 10:16:17 +0900
Masahiro Yamada <yamada.m-NAum8xwdG0+S7A1Ibl2khg@public.gmane.org> wrote:
> A typo "header=y" was introduced by commit 7071cf7fc435
> (uapi: add missing network related headers to kbuild).
>
> Signed-off-by: Masahiro Yamada <yamada.m-NAum8xwdG0+S7A1Ibl2khg@public.gmane.org>
> Cc: Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
> ---
>
> include/uapi/linux/Kbuild | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
> index 4c94f31..8523f9b 100644
> --- a/include/uapi/linux/Kbuild
> +++ b/include/uapi/linux/Kbuild
> @@ -427,7 +427,7 @@ header-y += virtio_net.h
> header-y += virtio_pci.h
> header-y += virtio_ring.h
> header-y += virtio_rng.h
> -header=y += vm_sockets.h
> +header-y += vm_sockets.h
> header-y += vt.h
> header-y += wait.h
> header-y += wanrouter.h
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Where exactly will arch_fast_hash be used
From: Herbert Xu @ 2014-12-04 8:11 UTC (permalink / raw)
To: Thomas Graf, Daniel Borkmann, David S. Miller, Theodore Ts'o,
netdev, Linux Kernel Mailing List
Hi:
While working on rhashtable it came to me that this whole concept
of arch_fast_hash is flawed. CRCs are linear functions so it's
fairly easy for an attacker to identify collisions or at least
eliminate a large amount of search space (e.g., controlling the
last bit of the hash result is almost trivial, even when you add
a random seed).
So what exactly are we going to use arch_fast_hash for? Presumably
it's places where security is never goint to be an issue, right?
Even if security wasn't an issue, straight CRC32 has really poor
lower-order bit distribution, which makes it a terrible choice for
a hash table that simply uses the lower-order bits.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: 3.12.33 - BUG xfrm_selector_match+0x25/0x2f6
From: Steffen Klassert @ 2014-12-04 7:56 UTC (permalink / raw)
To: Smart Weblications GmbH - Florian Wiessner; +Cc: netdev, LKML, stable
In-Reply-To: <547F2462.6040405@smart-weblications.de>
On Wed, Dec 03, 2014 at 03:55:30PM +0100, Smart Weblications GmbH - Florian Wiessner wrote:
> Hi list,
>
>
>
> [16623.095403] BUG: unable to handle kernel paging request at 00000000010600d0
> [16623.095445] IP: [<ffffffff81547767>] xfrm_selector_match+0x25/0x2f6
> [16623.095480] PGD aeaea067 PUD 85d95067 PMD 0
> [16623.095513] Oops: 0000 [#1] SMP
> [16623.095543] Modules linked in: netconsole xt_nat xt_multiport veth ip_vs_rr
> nfsd lockd nfs_acl auth_rpcgss sunrpc oid_registry iptable_mangle xt_mark
> nf_conntrack_netlink nfnetlink ipt_MASQUERADE iptable_nat nf_nat_ipv4
> nf_conntrack_ipv4 nf_defrag_ipv4 ipt_REJECT xt_tcpudp iptable_filter ip_tables
> cpufreq_ondemand cpufreq_powersave cpufreq_conservative cpufreq_userspace
> ocfs2_stack_o2cb ocfs2_dlm bridge stp llc bonding fuse nf_conntrack_ftp 8021q
> openvswitch gre vxlan xt_conntrack x_tables ocfs2_dlmfs dlm sctp ocfs2
> ocfs2_nodemanager ocfs2_stackglue configfs rbd kvm_intel kvm coretemp ip_vs_ftp
> ip_vs nf_nat nf_conntrack ctr twofish_generic twofish_x86_64 twofish_common
> camellia_generic serpent_generic blowfish_generic blowfish_common cast5_generic
> cast_common xcbc sha512_generic crypto_null af_key xfrm_algo psmouse serio_raw
> i2c_i801 lpc_ich mfd_core evdev btrfs lzo_decompress lzo_compress
> [16623.096062] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.12.33 #1
> [16623.096091] Hardware name: Supermicro X9SCI/X9SCA/X9SCI/X9SCA, BIOS 1.1a
> 09/28/2011
> [16623.096137] task: ffffffff81804450 ti: ffffffff817f4000 task.ti: ffffffff817f4000
> [16623.096182] RIP: 0010:[<ffffffff81547767>] [<ffffffff81547767>]
> xfrm_selector_match+0x25/0x2f6
> [16623.096233] RSP: 0018:ffff88083fc03900 EFLAGS: 00010246
> [16623.096261] RAX: 0000000000000001 RBX: ffff88083fc03a20 RCX: ffff880787fb1200
> [16623.096292] RDX: 0000000000000002 RSI: ffff88083fc03a20 RDI: 00000000010600a6
> [16623.096323] RBP: 00000000010600a6 R08: 0000000000000000 R09: ffff88083fc039a0
> [16623.096353] R10: 0000000000000000 R11: 0000000000000001 R12: ffff88083fc03a20
> [16623.096383] R13: 0000000000000001 R14: ffffffff818a9700 R15: ffffffffa01c73e0
> [16623.096414] FS: 0000000000000000(0000) GS:ffff88083fc00000(0000)
> knlGS:0000000000000000
> [16623.096469] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [16623.096498] CR2: 00000000010600d0 CR3: 0000000085f0b000 CR4: 00000000000407f0
> [16623.096528] Stack:
> [16623.096550] 0000000000000000 0000000001060002 ffff880787fb1200 ffff88083fc03a20
> [16623.096602] 0000000000000001 ffffffff81547a7c 0000000000000000 ffff8800baad5480
> [16623.096655] ffffffff81804450 ffffffff818a9700 000000003c9041bc ffffffff81547ef7
> [16623.096721] Call Trace:
> [16623.096744] <IRQ>
> [16623.096749] [<ffffffff81547a7c>] ? xfrm_sk_policy_lookup+0x44/0x9b
> [16623.096802] [<ffffffff81547ef7>] ? xfrm_lookup+0x91/0x446
> [16623.096832] [<ffffffff81541316>] ? ip_route_me_harder+0x150/0x1b0
> [16623.096865] [<ffffffffa01b6457>] ? ip_vs_route_me_harder+0x86/0x91 [ip_vs]
> [16623.096899] [<ffffffffa01b797a>] ? ip_vs_out+0x2d3/0x5bc [ip_vs]
> [16623.096930] [<ffffffff81501420>] ? ip_rcv_finish+0x2b8/0x2b8
I really wonder why the xfrm_sk_policy_lookup codepath is taken here.
It looks like this is the processing of an inbound ipv4 packet that
is going to be rerouted to the output path by ipvs, so this packet
should not have socket context at all.
xfrm_sk_policy_lookup is called just if the packet has socket context
and the socket has an IPsec output policy configured. Do you use IPsec
socket policies?
>
> This happens again and again with 3.12.33
>
>
> see also: http://www.spinics.net/lists/netdev/msg306283.html
>
> is this already fixed somehow?
>
You mentioned in the tread above that it does not happen with
3.17.4, so it should be fixed somehow. But I have no idea how
it was fixed.
^ permalink raw reply
* Re: [PATCH net] gso: do GSO for local skb with size bigger than MTU
From: Du Fan @ 2014-12-04 7:48 UTC (permalink / raw)
To: Jesse Gross, Pravin Shelar
Cc: Thomas Graf, Michael S. Tsirkin, Du, Fan, Jason Wang,
netdev@vger.kernel.org, davem@davemloft.net, fw@strlen.de,
dev@openvswitch.org
In-Reply-To: <CAEP_g=90nC2HhmBNKh-hKJ5MJ85Z-_ER14roDxMsZAKog+dFhw@mail.gmail.com>
于 2014年12月04日 06:51, Jesse Gross 写道:
> My proposal would be something like this:
> * For L2, reduce the VM MTU to the lowest common denominator on the segment.
> * For L3, use path MTU discovery or fragment inner packet (i.e.
> normal routing behavior).
> * As a last resort (such as if using an old version of virtio in the
> guest), fragment the tunnel packet.
After some investigation on OpenvSwitch package, it seems before this
commit: 06021dcb "datapath: compat: Fix compilation 3.11" OpenvSwitch
package is doing GSO on its own.
rpl_ip_local_out
-> tnl_skb_gso_segment
^^^^^^^^^^^^^^^
Perform GSO in above function
-> ip_local_out
.
.
-> ip_finish_output
Which means, when over-MTU-sized skb enter ip_local_out, it's not a gso
type skb, so the stack perform ip fragmentation, and send them out.
So, over-MTU-sized skb did travel through stack into outside.
Why not dropping such OpenvSwitch level GSO operation after 3.10?
--
No zuo no die but I have to try.
^ permalink raw reply
* linux-next: regression: Unable to mount NFS_ROOT since next-20141201
From: Romain Perier @ 2014-12-04 7:39 UTC (permalink / raw)
To: netdev, linux-next
[-- Attachment #1: Type: text/plain, Size: 364 bytes --]
Hi,
I mount my rootfs over the network using NFS_ROOT and a NFSv4 server.
Everything worked fine until next-20141201 (it works fine with next-20141128).
I was wondering if people had the same issue.
1. I did not change my network settings
2. I did not change my nfs server settings
3. I did not changes my hw
See my logs in attachment (look at the end)
Romain
[-- Attachment #2: wtf.log --]
[-- Type: text/x-log, Size: 147839 bytes --]
DDR Version 1.04 20140217
In
DDR3
300MHz
Bus Width=32 Col=10 Bank=8 Row=15 CS=2 Die Bus-Width=16 Size=2048MB
Memory OK
OUT
BUILD=====2
No.1 FLASH ID:2c 64 44 4b a9 0
OK! 282763
unsigned!
SecureBootEn = 0 0
Boot ver: 2014-03-03#2.13
start_linux=====287564
1511766 Starting kernel...@0x60408000
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.16.0-rc1 (ubuntu@radxa) (gcc version 4.8.2 (GCC) ) #2 SMP Fri Jul 18 19:10:51 UTC 2014
CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine model: Radxa Rock
bootconsole [earlycon0] enabled
Memory policy: Data cache writealloc
PERCPU: Embedded 7 pages/cpu @ee7c1000 s7680 r8192 d12800 u32768
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 522768
Kernel command line: console=ttyS2,115200 earlyprintk init=/sbin/init root=/dev/mmcblk0p1 rootwait
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 2071440K/2097152K available (4279K kernel code, 196K rwdata, 1340K rodata, 2151K init, 308K bss, 25712K reserved, 1318912K highmem)
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xffc00000 - 0xffe00000 (2048 kB)
vmalloc : 0xf0000000 - 0xff000000 ( 240 MB)
lowmem : 0xc0000000 - 0xef800000 ( 760 MB)
pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
.text : 0xc0008000 - 0xc0584f0c (5620 kB)
.init : 0xc0585000 - 0xc079ee00 (2152 kB)
.data : 0xc07a0000 - 0xc07d1300 ( 197 kB)
.bss : 0xc07d1308 - 0xc081e660 ( 309 kB)
Hierarchical RCU implementation.
NR_IRQS:16 nr_irqs:16 16
L2C-310 enabling early BRESP for Cortex-A9
L2C-310: enabling full line of zeros but not enabled in Cortex-A9
L2C-310 ID prefetch enabled, offset 15 lines
L2C-310 dynamic clock gating enabled, standby mode enabled
L2C-310 cache controller enabled, 16 ways, 512 kB
L2C-310: CACHE_ID 0x4100c0c8, AUX_CTRL 0x76050001
Rockchip-ID: 0x33313042 0x32303132 0x31313330 0x56313030
Rockchip SoC RK3188
sched_clock: 64 bits at 150MHz, resolution 6ns, wraps every 1832519401472ns
Console: colour dummy device 80x30
Calibrating delay loop... 1196.85 BogoMIPS (lpj=5984256)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
Setting up static identity map for 0x604337c8 - 0x60433820
CPU1: Booted secondary processor
CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
CPU2: Booted secondary processor
CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
CPU3: Booted secondary processor
CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
Brought up 4 CPUs
SMP: Total of 4 processors activated.
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
pinctrl core: initialized pinctrl subsystem
regulator-dummy: no parameters
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
cpuidle: using governor ladder
cpuidle: using governor menu
rockchip_clocks_apply_init_table: applying initial clock settings
rockchip_clk_init_from_table: setting rate of gpll to 891000000
rockchip_clk_init_from_table: setting rate of cpll to 600000000
rockchip_clk_init_from_table: setting rate of aclk_cpu to 300000000
rockchip_clk_init_from_table: setting rate of hclk_cpu to 150000000
rockchip_clk_init_from_table: setting rate of pclk_cpu to 75000000
rockchip_clk_init_from_table: setting rate of hclk_ahb2apb to 75000000
rockchip_clk_init_from_table: setting parent of aclk_peri_pre to cpll
rockchip_clk_init_from_table: setting rate of aclk_peri_pre to 150000000
rockchip_clk_init_from_table: setting rate of hclk_peri to 150000000
rockchip_clk_init_from_table: setting rate of pclk_peri to 75000000
rockchip_clk_init_from_table: setting rate of sclk_sdmmc to 75000000
rockchip_clk_init_from_table: setting rate of sclk_macref to 50000000
rockchip_clk_init_from_table: enabling sclk_mac_lbtest
syscon: pmu regmap [mem 0x20004000-0x200040ff] registered
syscon: grf regmap [mem 0x20008000-0x200081ff] registered
No ATAGs?
hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
hw-breakpoint: maximum watchpoint size is 4 bytes.
sdmmc-supply: 3300 mV
reg-fixed-voltage regulators:fixed-regulator@0: Failed to find supply vin
reg-fixed-voltage regulators:fixed-regulator@0: Failed to register regulator: -517
platform regulators:fixed-regulator@0: Driver reg-fixed-voltage requests probe deferral
otg-vbus: 5000 mV
usb-vbus: 5000 mV
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
i2c-gpio soc:i2c@0: using pins 58 (SDA) and 59 (SCL)
cfg80211: Calling CRDA to update world regulatory domain
Switched to clocksource arm_global_timer
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 3, 32768 bytes)
TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
futex hash table entries: 1024 (order: 4, 65536 bytes)
msgmni has been set to 1469
bounce: pool size: 64 pages
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
io scheduler noop registered
io scheduler deadline registered (default)
dma-pl330 20078000.dma: Loaded driver for PL330 DMAC-2364208
dma-pl330 20078000.dma: DBUFF-64x8bytes Num_Chans-7 Num_Peri-20 Num_Events-14
VCC_DDR: 1200 mV
VDD_LOG: 1000 mV
VDD_ARM: 875 <--> 1300 mV at 1000 mV
VCC_IO: 3300 mV
VDD_10: 1000 mV
VDD_HDMI: 2500 mV
VCC_18: 1800 mV
VCCA_33: 3300 mV
VCC_RMII: 3300 mV
VCCIO_WL: 3300 mV
VCC18_IO: 1800 mV
VCC_28: 2800 mV
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
10124000.serial: ttyS0 at MMIO 0x10124000 (irq = 66, base_baud = 1500000) is a 16550A
dw-apb-uart 10126000.serial: Couldn't set LCR to 0
dw-apb-uart 10126000.serial: Couldn't set LCR to 0
10126000.serial: ttyS1 at MMIO 0x10126000 (irq = 67, base_baud = 1500000) is a 16550A
console [ttyS2] disabled
20064000.serial: ttyS2 at MMIO 0x20064000 (irq = 68, base_baud = 1500000) is a 16550A
console [ttyS2] enabled
console [ttyS2] enabled
bootconsole [earlycon0] disabled
bootconsole [earlycon0] disabled
dw-apb-uart 20068000.serial: Couldn't set LCR to 0
dw-apb-uart 20068000.serial: Couldn't set LCR to 0
20068000.serial: ttyS3 at MMIO 0x20068000 (irq = 69, base_baud = 1500000) is a 16550A
[drm] Initialized drm 1.1.0 20060810
brd: module loaded
arc_emac 10204000.emac: ARC EMAC detected with id: 0x7fd02
arc_emac 10204000.emac: IRQ is 51
arc_emac 10204000.emac: MAC address is now c6:ef:91:8e:60:4b
libphy: Synopsys MII Bus: probed
arc_emac 10204000.emac: connected to SMSC LAN8710/LAN8720 phy with id 0x7c0f1
dwc2 10180000.dwc2: DWC OTG Controller
dwc2 10180000.dwc2: new USB bus registered, assigned bus number 1
dwc2 10180000.dwc2: irq 48, io mem 0x00000000
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: DWC OTG Controller
usb usb1: Manufacturer: Linux 3.16.0-rc1 dwc2_hsotg
usb usb1: SerialNumber: 10180000.dwc2
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
dwc2 101c0000.dwc2: DWC OTG Controller
dwc2 101c0000.dwc2: new USB bus registered, assigned bus number 2
dwc2 101c0000.dwc2: irq 49, io mem 0x00000000
usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: DWC OTG Controller
usb usb2: Manufacturer: Linux 3.16.0-rc1 dwc2_hsotg
usb usb2: SerialNumber: 101c0000.dwc2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected
mousedev: PS/2 mouse device common for all mice
rtc-hym8563 0-0051: no valid clock/calendar values available
rtc-hym8563 0-0051: rtc core: registered hym8563 as rtc0
softdog: Software Watchdog Timer: 0.08 initialized. soft_noboot=0 soft_margin=60 sec soft_panic=0 (nowayout=0)
Synopsys Designware Multimedia Card Interface Driver
dw_mmc 10214000.dwmmc: fifo-depth property not found, using value of FIFOTH register as default
platform 10214000.dwmmc: Driver dw_mmc requests probe deferral
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
usbcore: registered new interface driver r8188eu
usbcore: registered new interface driver rtl8723au
TCP: cubic registered
NET: Registered protocol family 17
sdmmc-supply: 3300 mV
sdmmc-supply: supplied by VCC_IO
dw_mmc 10214000.dwmmc: fifo-depth property not found, using value of FIFOTH register as default
dw_mmc 10214000.dwmmc: Using PIO mode.
dw_mmc 10214000.dwmmc: Version ID is 240a
dw_mmc 10214000.dwmmc: DW MMC controller at irq 55, 32 bit host data width, 256 deep fifo
dw_mmc 10214000.dwmmc: 1 slots initialized
input: soc:gpio-keys as /devices/soc/soc:gpio-keys/input/input0
rtc-hym8563 0-0051: no valid clock/calendar values available
rtc-hym8563 0-0051: hctosys: unable to read the hardware clock
usb-vbus: disabling
otg-vbus: disabling
Freeing unused kernel memory: 2148K (c0585000 - c079e000)
usb 2-1: new high-speed USB device number 2 using dwc2
usb 2-1: New USB device found, idVendor=05e3, idProduct=0608
usb 2-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
usb 2-1: Product: USB2.0 Hub
hub 2-1:1.0: USB hub found
hub 2-1:1.0: 4 ports detected
usb 2-1.1: new high-speed USB device number 3 using dwc2
usb 2-1.1: device v0bda p0724 is not supported
usb 2-1-port1: unable to enumerate USB device
Do you want to kexec a kernel over the network ? [y/n] y
* Starting DHCP on eth0
udhcpc (v1.22.1) started
Sending discover...
arc_emac 10204000.emac eth0: Link is Down
arc_emac 10204000.emac eth0: Link is Up - 100Mbps/Full - flow control off
Sending discover...
Sending select for 192.168.0.98...
Lease of 192.168.0.98 obtained, lease time 43200
/etc/udhcpc.d/50default: Adding DNS 192.168.0.20
random: nonblocking pool is initialized
* Found zImage on 192.168.0.20
Do you want to reboot to the new kernel on the fly ? [y/n] yarc_emac 10204000.emac eth0: Link is Down
Modified cmdline: root=/dev/block/mtd/by-name/linuxroot
Unable to find /proc/device-tree//chosen/linux,stdout-path, printing from purgatory is diabled
Starting new kernel
Disabling non-boot CPUs ...
CPU1: shutdown
CPU2: shutdown
CPU3: shutdown
Bye!
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.18.0-rc7-next-20141203 (ubuntu@radxa) (gcc version 4.9.1 (GCC) ) #7 SMP Thu Dec 4 07:25:45 UTC 2014
CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine model: Radxa Rock
bootconsole [earlycon0] enabled
Memory policy: Data cache writealloc
PERCPU: Embedded 9 pages/cpu @ee7ba000 s7744 r8192 d20928 u36864
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 522768
Kernel command line: console=ttyS2,115200 earlyprintk root=/dev/nfs nfsroot=192.168.0.20:/var/lib/lxc/radxa/rootfs/home/ubuntu/yocto/build/tmp/rootfs,vers=4,tcp nfsrootdebug
rw ip=dhcp
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 2072880K/2097152K available (4507K kernel code, 231K rwdata, 1488K rodata, 248K init, 316K bss, 24272K reserved, 0K cma-reserved, 1318912K highmem)
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
vmalloc : 0xf0000000 - 0xff000000 ( 240 MB)
lowmem : 0xc0000000 - 0xef800000 ( 760 MB)
pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
.text : 0xc0008000 - 0xc05e300c (5997 kB)
.init : 0xc05e4000 - 0xc0622000 ( 248 kB)
.data : 0xc0622000 - 0xc065be50 ( 232 kB)
.bss : 0xc065be50 - 0xc06aae80 ( 317 kB)
Hierarchical RCU implementation.
NR_IRQS:16 nr_irqs:16 16
L2C-310 enabling early BRESP for Cortex-A9
L2C-310: enabling full line of zeros but not enabled in Cortex-A9
L2C-310 ID prefetch enabled, offset 15 lines
L2C-310 dynamic clock gating enabled, standby mode enabled
L2C-310 cache controller enabled, 16 ways, 512 kB
L2C-310: CACHE_ID 0x4100c0c8, AUX_CTRL 0x76050001
sched_clock: 64 bits at 150MHz, resolution 6ns, wraps every 1832519401472ns
Console: colour dummy device 80x30
Calibrating delay loop... 1196.85 BogoMIPS (lpj=5984256)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
rockchip_smp_prepare_cpus: ncores 4
Setting up static identity map for 0x6046c7f8 - 0x6046c850
CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
Brought up 4 CPUs
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
cpuidle: using governor ladder
cpuidle: using governor menu
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmapped irq 26
rockchip-pinctrl pinctrl: unmDDR Version 1.04 20140217
In
DDR3
300MHz
Bus Width=32 Col=10 Bank=8 Row=15 CS=2 Die Bus-Width=16 Size=2048MB
Memory OK
OUT
BUILD=====2
No.1 FLASH ID:2c 64 44 4b a9 0
OK! 282838
unsigned!
SecureBootEn = 0 0
Boot ver: 2014-03-03#2.13
start_linux=====287656
1509827 Starting kernel...@0x60408000
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.16.0-rc1 (ubuntu@radxa) (gcc version 4.8.2 (GCC) ) #2 SMP Fri Jul 18 19:10:51 UTC 2014
CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine model: Radxa Rock
bootconsole [earlycon0] enabled
Memory policy: Data cache writealloc
PERCPU: Embedded 7 pages/cpu @ee7c1000 s7680 r8192 d12800 u32768
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 522768
Kernel command line: console=ttyS2,115200 earlyprintk init=/sbin/init root=/dev/mmcblk0p1 rootwait
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 2071440K/2097152K available (4279K kernel code, 196K rwdata, 1340K rodata, 2151K init, 308K bss, 25712K reserved, 1318912K highmem)
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xffc00000 - 0xffe00000 (2048 kB)
vmalloc : 0xf0000000 - 0xff000000 ( 240 MB)
lowmem : 0xc0000000 - 0xef800000 ( 760 MB)
pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
.text : 0xc0008000 - 0xc0584f0c (5620 kB)
.init : 0xc0585000 - 0xc079ee00 (2152 kB)
.data : 0xc07a0000 - 0xc07d1300 ( 197 kB)
.bss : 0xc07d1308 - 0xc081e660 ( 309 kB)
Hierarchical RCU implementation.
NR_IRQS:16 nr_irqs:16 16
L2C-310 enabling early BRESP for Cortex-A9
L2C-310: enabling full line of zeros but not enabled in Cortex-A9
L2C-310 ID prefetch enabled, offset 15 lines
L2C-310 dynamic clock gating enabled, standby mode enabled
L2C-310 cache controller enabled, 16 ways, 512 kB
L2C-310: CACHE_ID 0x4100c0c8, AUX_CTRL 0x76050001
Rockchip-ID: 0x33313042 0x32303132 0x31313330 0x56313030
Rockchip SoC RK3188
sched_clock: 64 bits at 150MHz, resolution 6ns, wraps every 1832519401472ns
Console: colour dummy device 80x30
Calibrating delay loop... 1196.85 BogoMIPS (lpj=5984256)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
Setting up static identity map for 0x604337c8 - 0x60433820
CPU1: Booted secondary processor
CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
CPU2: Booted secondary processor
CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
CPU3: Booted secondary processor
CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
Brought up 4 CPUs
SMP: Total of 4 processors activated.
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
pinctrl core: initialized pinctrl subsystem
regulator-dummy: no parameters
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
cpuidle: using governor ladder
cpuidle: using governor menu
rockchip_clocks_apply_init_table: applying initial clock settings
rockchip_clk_init_from_table: setting rate of gpll to 891000000
rockchip_clk_init_from_table: setting rate of cpll to 600000000
rockchip_clk_init_from_table: setting rate of aclk_cpu to 300000000
rockchip_clk_init_from_table: setting rate of hclk_cpu to 150000000
rockchip_clk_init_from_table: setting rate of pclk_cpu to 75000000
rockchip_clk_init_from_table: setting rate of hclk_ahb2apb to 75000000
rockchip_clk_init_from_table: setting parent of aclk_peri_pre to cpll
rockchip_clk_init_from_table: setting rate of aclk_peri_pre to 150000000
rockchip_clk_init_from_table: setting rate of hclk_peri to 150000000
rockchip_clk_init_from_table: setting rate of pclk_peri to 75000000
rockchip_clk_init_from_table: setting rate of sclk_sdmmc to 75000000
rockchip_clk_init_from_table: setting rate of sclk_macref to 50000000
rockchip_clk_init_from_table: enabling sclk_mac_lbtest
syscon: pmu regmap [mem 0x20004000-0x200040ff] registered
syscon: grf regmap [mem 0x20008000-0x200081ff] registered
No ATAGs?
hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
hw-breakpoint: maximum watchpoint size is 4 bytes.
sdmmc-supply: 3300 mV
reg-fixed-voltage regulators:fixed-regulator@0: Failed to find supply vin
reg-fixed-voltage regulators:fixed-regulator@0: Failed to register regulator: -517
platform regulators:fixed-regulator@0: Driver reg-fixed-voltage requests probe deferral
otg-vbus: 5000 mV
usb-vbus: 5000 mV
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
i2c-gpio soc:i2c@0: using pins 58 (SDA) and 59 (SCL)
cfg80211: Calling CRDA to update world regulatory domain
Switched to clocksource arm_global_timer
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 3, 32768 bytes)
TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
futex hash table entries: 1024 (order: 4, 65536 bytes)
msgmni has been set to 1469
bounce: pool size: 64 pages
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
io scheduler noop registered
io scheduler deadline registered (default)
dma-pl330 20078000.dma: Loaded driver for PL330 DMAC-2364208
dma-pl330 20078000.dma: DBUFF-64x8bytes Num_Chans-7 Num_Peri-20 Num_Events-14
VCC_DDR: 1200 mV
VDD_LOG: 1000 mV
VDD_ARM: 875 <--> 1300 mV at 1000 mV
VCC_IO: 3300 mV
VDD_10: 1000 mV
VDD_HDMI: 2500 mV
VCC_18: 1800 mV
VCCA_33: 3300 mV
VCC_RMII: 3300 mV
VCCIO_WL: 3300 mV
VCC18_IO: 1800 mV
VCC_28: 2800 mV
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
10124000.serial: ttyS0 at MMIO 0x10124000 (irq = 66, base_baud = 1500000) is a 16550A
dw-apb-uart 10126000.serial: Couldn't set LCR to 0
dw-apb-uart 10126000.serial: Couldn't set LCR to 0
10126000.serial: ttyS1 at MMIO 0x10126000 (irq = 67, base_baud = 1500000) is a 16550A
console [ttyS2] disabled
20064000.serial: ttyS2 at MMIO 0x20064000 (irq = 68, base_baud = 1500000) is a 16550A
console [ttyS2] enabled
console [ttyS2] enabled
bootconsole [earlycon0] disabled
bootconsole [earlycon0] disabled
dw-apb-uart 20068000.serial: Couldn't set LCR to 0
dw-apb-uart 20068000.serial: Couldn't set LCR to 0
20068000.serial: ttyS3 at MMIO 0x20068000 (irq = 69, base_baud = 1500000) is a 16550A
[drm] Initialized drm 1.1.0 20060810
brd: module loaded
arc_emac 10204000.emac: ARC EMAC detected with id: 0x7fd02
arc_emac 10204000.emac: IRQ is 51
arc_emac 10204000.emac: MAC address is now c6:ef:91:8e:60:4b
libphy: Synopsys MII Bus: probed
arc_emac 10204000.emac: connected to SMSC LAN8710/LAN8720 phy with id 0x7c0f1
dwc2 10180000.dwc2: DWC OTG Controller
dwc2 10180000.dwc2: new USB bus registered, assigned bus number 1
dwc2 10180000.dwc2: irq 48, io mem 0x00000000
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: DWC OTG Controller
usb usb1: Manufacturer: Linux 3.16.0-rc1 dwc2_hsotg
usb usb1: SerialNumber: 10180000.dwc2
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
dwc2 101c0000.dwc2: DWC OTG Controller
dwc2 101c0000.dwc2: new USB bus registered, assigned bus number 2
dwc2 101c0000.dwc2: irq 49, io mem 0x00000000
usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: DWC OTG Controller
usb usb2: Manufacturer: Linux 3.16.0-rc1 dwc2_hsotg
usb usb2: SerialNumber: 101c0000.dwc2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected
mousedev: PS/2 mouse device common for all mice
rtc-hym8563 0-0051: no valid clock/calendar values available
rtc-hym8563 0-0051: rtc core: registered hym8563 as rtc0
softdog: Software Watchdog Timer: 0.08 initialized. soft_noboot=0 soft_margin=60 sec soft_panic=0 (nowayout=0)
Synopsys Designware Multimedia Card Interface Driver
dw_mmc 10214000.dwmmc: fifo-depth property not found, using value of FIFOTH register as default
platform 10214000.dwmmc: Driver dw_mmc requests probe deferral
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
usbcore: registered new interface driver r8188eu
usbcore: registered new interface driver rtl8723au
TCP: cubic registered
NET: Registered protocol family 17
sdmmc-supply: 3300 mV
sdmmc-supply: supplied by VCC_IO
dw_mmc 10214000.dwmmc: fifo-depth property not found, using value of FIFOTH register as default
dw_mmc 10214000.dwmmc: Using PIO mode.
dw_mmc 10214000.dwmmc: Version ID is 240a
dw_mmc 10214000.dwmmc: DW MMC controller at irq 55, 32 bit host data width, 256 deep fifo
dw_mmc 10214000.dwmmc: 1 slots initialized
input: soc:gpio-keys as /devices/soc/soc:gpio-keys/input/input0
rtc-hym8563 0-0051: no valid clock/calendar values available
rtc-hym8563 0-0051: hctosys: unable to read the hardware clock
usb-vbus: disabling
otg-vbus: disabling
Freeing unused kernel memory: 2148K (c0585000 - c079e000)
usb 2-1: new high-speed USB device number 2 using dwc2
usb 2-1: New USB device found, idVendor=05e3, idProduct=0608
usb 2-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
usb 2-1: Product: USB2.0 Hub
hub 2-1:1.0: USB hub found
hub 2-1:1.0: 4 ports detected
usb 2-1.1: new high-speed USB device number 3 using dwc2
usb 2-1.1: device v0bda p0724 is not supported
usb 2-1-port1: unable to enumerate USB device
Do you want to kexec a kernel over the network ? [y/n] y
* Starting DHCP on eth0
udhcpc (v1.22.1) started
Sending discover...
arc_emac 10204000.emac eth0: Link is Down
arc_emac 10204000.emac eth0: Link is Up - 100Mbps/Full - flow control off
Sending discover...
Sending select for 192.168.0.98...
Lease of 192.168.0.98 obtained, lease time 43200
/etc/udhcpc.d/50default: Adding DNS 192.168.0.20
random: nonblocking pool is initialized
* Found zImage on 192.168.0.20
Do you want to reboot to the new kernel on the fly ? [y/n] y
Modified cmdline: root=/dev/block/mtd/by-name/linuxroot
Unable to find /proc/device-tree//chosen/linux,stdout-path, printing from purgatory is diabled
Starting new kernel
Disabling non-boot CPUs ...
CPU1: shutdown
CPU2: shutdown
CPU3: shutdown
Bye!
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.18.0-rc7-next-20141203 (ubuntu@radxa) (gcc version 4.9.1 (GCC) ) #7 SMP Thu Dec 4 07:25:45 UTC 2014
CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine model: Radxa Rock
bootconsole [earlycon0] enabled
Memory policy: Data cache writealloc
PERCPU: Embedded 9 pages/cpu @ee7ba000 s7744 r8192 d20928 u36864
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 522768
Kernel command line: console=ttyS2,115200 earlyprintk root=/dev/nfs nfsroot=192.168.0.20:/var/lib/lxc/radxa/rootfs/home/ubuntu/yocto/build/tmp/rootfs,vers=4,tcp nfsrootdebug
rw ip=dhcp
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 2072880K/2097152K available (4507K kernel code, 231K rwdata, 1488K rodata, 248K init, 316K bss, 24272K reserved, 0K cma-reserved, 1318912K highmem)
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
vmalloc : 0xf0000000 - 0xff000000 ( 240 MB)
lowmem : 0xc0000000 - 0xef800000 ( 760 MB)
pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
.text : 0xc0008000 - 0xc05e300c (5997 kB)
.init : 0xc05e4000 - 0xc0622000 ( 248 kB)
.data : 0xc0622000 - 0xc065be50 ( 232 kB)
.bss : 0xc065be50 - 0xc06aae80 ( 317 kB)
Hierarchical RCU implementation.
NR_IRQS:16 nr_irqs:16 16
L2C-310 enabling early BRESP for Cortex-A9
L2C-310: enabling full line of zeros but not enabled in Cortex-A9
L2C-310 ID prefetch enabled, offset 15 lines
L2C-310 dynamic clock gating enabled, standby mode enabled
L2C-310 cache controller enabled, 16 ways, 512 kB
L2C-310: CACHE_ID 0x4100c0c8, AUX_CTRL 0x76050001
sched_clock: 64 bits at 150MHz, resolution 6ns, wraps every 1832519401472ns
Console: colour dummy device 80x30
Calibrating delay loop... 1196.85 BogoMIPS (lpj=5984256)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
rockchip_smp_prepare_cpus: ncores 4
Setting up static identity map for 0x6046c7f8 - 0x6046c850
CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
Brought up 4 CPUs
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
cpuidle: using governor ladder
cpuidle: using governor menu
No ATAGs?
hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
hw-breakpoint: maximum watchpoint size is 4 bytes.
reg-fixed-voltage sdmmc-regulator: Failed to find supply vin
reg-fixed-voltage sdmmc-regulator: Failed to register regulator: -517
platform sdmmc-regulator: Driver reg-fixed-voltage requests probe deferral
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
cfg80211: Calling CRDA to update world regulatory domain
Switched to clocksource arm_global_timer
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 3, 32768 bytes)
TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
futex hash table entries: 1024 (order: 4, 65536 bytes)
NFS: Registering the id_resolver key type
Key type id_resolver registered
Key type id_legacy registered
bounce: pool size: 64 pages
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
io scheduler noop registered
io scheduler deadline registered (default)
dma-pl330 20018000.dma-controller: Loaded driver for PL330 DMAC-241330
dma-pl330 20018000.dma-controller: DBUFF-32x8bytes Num_Chans-6 Num_Peri-12 Num_Events-12
dma-pl330 20078000.dma-controller: Loaded driver for PL330 DMAC-241330
dma-pl330 20078000.dma-controller: DBUFF-64x8bytes Num_Chans-7 Num_Peri-20 Num_Events-14
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
dw-apb-uart 10124000.serial: ttyS0 at MMIO 0x10124000 (irq = 22, base_baud = 1500000) is a 16550A
dw-apb-uart 10126000.serial: Couldn't set LCR to 191
dw-apb-uart 10126000.serial: Couldn't set LCR to 0
dw-apb-uart 10126000.serial: Couldn't set LCR to 191
dw-apb-uart 10126000.serial: Couldn't set LCR to 0
dw-apb-uart 10126000.serial: Couldn't set LCR to 0
dw-apb-uart 10126000.serial: Couldn't set LCR to 0
dw-apb-uart 10126000.serial: Couldn't set LCR to 0
dw-apb-uart 10126000.serial: Couldn't set LCR to 0
dw-apb-uart 10126000.serial: ttyS1 at MMIO 0x10126000 (irq = 23, base_baud = 1500000) is a XScale
console [ttyS2] disabled
dw-apb-uart 20064000.serial: ttyS2 at MMIO 0x20064000 (irq = 30, base_baud = 1500000) is a 16550A
console [ttyS2] enabled
console [ttyS2] enabled
bootconsole [earlycon0] disabled
bootconsole [earlycon0] disabled
dw-apb-uart 20068000.serial: Couldn't set LCR to 191
dw-apb-uart 20068000.serial: Couldn't set LCR to 0
dw-apb-uart 20068000.serial: Couldn't set LCR to 191
dw-apb-uart 20068000.serial: Couldn't set LCR to 0
dw-apb-uart 20068000.serial: Couldn't set LCR to 0
dw-apb-uart 20068000.serial: Couldn't set LCR to 0
dw-apb-uart 20068000.serial: Couldn't set LCR to 0
dw-apb-uart 20068000.serial: Couldn't set LCR to 0
dw-apb-uart 20068000.serial: ttyS3 at MMIO 0x20068000 (irq = 31, base_baud = 1500000) is a XScale
[drm] Initialized drm 1.1.0 20060810
brd: module loaded
platform 10204000.ethernet: Driver rockchip_emac requests probe deferral
dwc2 10180000.usb: Mode Mismatch Interrupt: currently in Device mode
Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc7-next-20141203 #7
Hardware name: Rockchip Cortex-A9 (Device Tree)
task: ee057b40 ti: ee058000 task.ti: ee058000
PC is at usb_create_shared_hcd+0x118/0x1e8
LR is at usb_create_shared_hcd+0x100/0x1e8
pc : [<c0286320>] lr : [<c0286308>] psr: 40000113
sp : ee059cc0 ip : 00000000 fp : ee059ce4
r10: 00000018 r9 : 00000000 r8 : ee106240
r7 : c06418b8 r6 : ee109c10 r5 : 00000000 r4 : ee0dfa00
r3 : ffffffff r2 : 00000000 r1 : ffffffd0 r0 : ee0dfa38
Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c5387d Table: 6000404a DAC: 00000015
Process swapper/0 (pid: 1, stack limit = 0xee058238)
Stack: (0xee059cc0 to 0xee05a000)
9cc0: 00000000 ee0d1410 ee109d30 c0693fb8 00000000 ffffffff ee059cf4 ee059ce8
9ce0: c0286404 c0286214 ee059d34 ee059cf8 c029e02c c02863fc ee0d1410 ee109c00
9d00: ee059d34 ee059d10 c02b42fc ee0d1410 ee109c00 ee109c10 c0493b7c c0659690
9d20: 00000018 ee106280 ee059ddc ee059d38 c02a2970 c029dea0 00000080 ee106240
9d40: ee0d1410 ee059d50 c03885d4 c02f95ac c011bfcc c011bdd0 00000004 ee1084e8
9d60: ee059d84 ee059d70 c011bdb8 ee0e1358 ee0e13f8 ee1084e8 ee059da4 ee0e1358
9d80: ee0e13f8 c056841a ee1084e8 00000001 00000000 00000000 ee059dcc ee059da8
9da0: c011e27c c011af48 00000001 ee109c10 00000000 ffffffed ee109c10 c064197c
9dc0: 00000000 c0657278 00000000 00000000 ee059dfc ee059de0 c024a994 c02a27d4
9de0: c024a944 ee109c10 c064197c c069f02c ee059e2c ee059e00 c0248f78 c024a950
9e00: ee059e2c ee059e10 ee109c10 ee109c44 c064197c c063f428 c062cda0 c065be80
9e20: ee059e4c ee059e30 c024923c c0248e44 00000001 00000000 c064197c c02491cc
9e40: ee059e74 ee059e50 c0247378 c02491d8 ee02f95c ee090234 ee02f970 c064197c
9e60: 00000000 ee0e4e80 ee059e84 ee059e78 c02489a4 c0247310 ee059eac ee059e88
9e80: c02485dc c0248990 c0493c44 ee059e98 c064197c c05fcf54 00000000 c062cda0
9ea0: ee059ec4 ee059eb0 c02498f8 c02484dc ee0e5d00 c05fcf54 ee059ed4 ee059ec8
9ec0: c024a8c8 c0249860 ee059ee4 ee059ed8 c05fcf6c c024a884 ee059f5c ee059ee8
9ee0: c0008a4c c05fcf60 80070013 ffffffff ee059f14 ee059f00 c05e4600 c01d62ec
9f00: ef7fcc5c ef7fcc5f ee059f5c ee059f18 c0038dbc c05e4608 00000000 c01d50cc
9f20: 000000d2 00000006 00000006 000000d3 00000000 00000006 00000006 000000d3
9f40: c0612bc4 c061fb5c c065be80 c065be80 ee059f94 ee059f60 c05e4e10 c000893c
9f60: 00000006 00000006 c05e45fc ee059f68 00000000 c0465f98 00000000 00000000
9f80: 00000000 00000000 ee059fac ee059f98 c0465fa8 c05e4d00 ee058000 00000000
9fa0: 00000000 ee059fb0 c000ea58 c0465fa4 00000000 00000000 00000000 00000000
9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff
Backtrace:
[<c0286208>] (usb_create_shared_hcd) from [<c0286404>] (usb_create_hcd+0x14/0x18)
r8:ffffffff r7:00000000 r6:c0693fb8 r5:ee109d30 r4:ee0d1410 r3:00000000
[<c02863f0>] (usb_create_hcd) from [<c029e02c>] (dwc2_hcd_init+0x198/0x504)
[<c029de94>] (dwc2_hcd_init) from [<c02a2970>] (dwc2_driver_probe+0x1a8/0x1e4)
r10:ee106280 r9:00000018 r8:c0659690 r7:c0493b7c r6:ee109c10 r5:ee109c00
r4:ee0d1410
[<c02a27c8>] (dwc2_driver_probe) from [<c024a994>] (platform_drv_probe+0x50/0xa0)
r10:00000000 r9:00000000 r8:c0657278 r7:00000000 r6:c064197c r5:ee109c10
r4:ffffffed
[<c024a944>] (platform_drv_probe) from [<c0248f78>] (driver_probe_device+0x140/0x348)
r6:c069f02c r5:c064197c r4:ee109c10 r3:c024a944
[<c0248e38>] (driver_probe_device) from [<c024923c>] (__driver_attach+0x70/0x94)
r9:c065be80 r8:c062cda0 r7:c063f428 r6:c064197c r5:ee109c44 r4:ee109c10
[<c02491cc>] (__driver_attach) from [<c0247378>] (bus_for_each_dev+0x74/0x98)
r6:c02491cc r5:c064197c r4:00000000 r3:00000001
[<c0247304>] (bus_for_each_dev) from [<c02489a4>] (driver_attach+0x20/0x28)
r6:ee0e4e80 r5:00000000 r4:c064197c
[<c0248984>] (driver_attach) from [<c02485dc>] (bus_add_driver+0x10c/0x1fc)
[<c02484d0>] (bus_add_driver) from [<c02498f8>] (driver_register+0xa4/0xe8)
r7:c062cda0 r6:00000000 r5:c05fcf54 r4:c064197c
[<c0249854>] (driver_register) from [<c024a8c8>] (__platform_driver_register+0x50/0x64)
r5:c05fcf54 r4:ee0e5d00
[<c024a878>] (__platform_driver_register) from [<c05fcf6c>] (dwc2_platform_driver_init+0x18/0x20)
[<c05fcf54>] (dwc2_platform_driver_init) from [<c0008a4c>] (do_one_initcall+0x11c/0x1d0)
[<c0008930>] (do_one_initcall) from [<c05e4e10>] (kernel_init_freeable+0x11c/0x1e4)
r9:c065be80 r8:c065be80 r7:c061fb5c r6:c0612bc4 r5:000000d3 r4:00000006
[<c05e4cf4>] (kernel_init_freeable) from [<c0465fa8>] (kernel_init+0x10/0xec)
r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c0465f98 r4:00000000
[<c0465f98>] (kernel_init) from [<c000ea58>] (ret_from_fork+0x14/0x3c)
r4:00000000 r3:ee058000
Code: e3a05000 e5843004 e2840038 e5845028 (57de7c38)
---[ end trace 378ac5bc0a7db82d ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
CPU3: stopping
CPU: 3 PID: 0 Comm: swapper/3 Tainted: G D 3.18.0-rc7-next-20141203 #7
Hardware name: Rockchip Cortex-A9 (Device Tree)
Backtrace:
[<c0011d0c>] (dump_backtrace) from [<c0011f2c>] (show_stack+0x18/0x1c)
r6:00000000 r5:00000003 r4:00000000 r3:00200040
[<c0011f14>] (show_stack) from [<c0467cd8>] (dump_stack+0x78/0x94)
[<c0467c60>] (dump_stack) from [<c0013f10>] (handle_IPI+0xd0/0x168)
r4:c065c158 r3:ee07a000
[<c0013e40>] (handle_IPI) from [<c000866c>] (gic_handle_irq+0x5c/0x64)
r6:ee07bf68 r5:c062b190 r4:f0002100 r3:00000405
[<c0008610>] (gic_handle_irq) from [<c0012a40>] (__irq_svc+0x40/0x54)
Exception stack(0xee07bf68 to 0xee07bfb0)
bf60: ffffffed 00000000 ffffffed c001da00 ee07a000 00000000
bf80: 00000000 ee07bfc0 c0620b48 413fc090 00000000 ee07bfbc ee07bfc0 ee07bfb0
bfa0: c000f5b8 c000f5bc 60000113 ffffffff
r6:ffffffff r5:60000113 r4:c000f5bc r3:c000f5b8
[<c000f588>] (arch_cpu_idle) from [<c004ccec>] (cpu_startup_entry+0xc0/0x208)
[<c004cc2c>] (cpu_startup_entry) from [<c0013c0c>] (secondary_start_kernel+0x124/0x148)
r7:c065c184
[<c0013ae8>] (secondary_start_kernel) from [<60008704>] (0x60008704)
r4:8e05c06a r3:c00086ec
CPU2: stopping
CPU: 2 PID: 0 Comm: swapper/2 Tainted: G D 3.18.0-rc7-next-20141203 #7
Hardware name: Rockchip Cortex-A9 (Device Tree)
Backtrace:
[<c0011d0c>] (dump_backtrace) from [<c0011f2c>] (show_stack+0x18/0x1c)
r6:00000000 r5:00000002 r4:00000000 r3:00200040
[<c0011f14>] (show_stack) from [<c0467cd8>] (dump_stack+0x78/0x94)
[<c0467c60>] (dump_stack) from [<c0013f10>] (handle_IPI+0xd0/0x168)
r4:c065c158 r3:ee078000
[<c0013e40>] (handle_IPI) from [<c000866c>] (gic_handle_irq+0x5c/0x64)
r6:ee079f68 r5:c062b190 r4:f0002100 r3:00000405
[<c0008610>] (gic_handle_irq) from [<c0012a40>] (__irq_svc+0x40/0x54)
Exception stack(0xee079f68 to 0xee079fb0)
9f60: ffffffed 00000000 ffffffed c001da00 ee078000 00000000
9f80: 00000000 ee079fc0 c0620b48 413fc090 00000000 ee079fbc ee079fc0 ee079fb0
9fa0: c000f5b8 c000f5bc 60000113 ffffffff
r6:ffffffff r5:60000113 r4:c000f5bc r3:c000f5b8
[<c000f588>] (arch_cpu_idle) from [<c004ccec>] (cpu_startup_entry+0xc0/0x208)
[<c004cc2c>] (cpu_startup_entry) from [<c0013c0c>] (secondary_start_kernel+0x124/0x148)
r7:c065c184
[<c0013ae8>] (secondary_start_kernel) from [<60008704>] (0x60008704)
r4:8e05c06a r3:c00086ec
CPU0: stopping
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G D 3.18.0-rc7-next-20141203 #7
Hardware name: Rockchip Cortex-A9 (Device Tree)
Backtrace:
[<c0011d0c>] (dump_backtrace) from [<c0011f2c>] (show_stack+0x18/0x1c)
r6:00000000 r5:00000000 r4:00000000 r3:00200000
[<c0011f14>] (show_stack) from [<c0467cd8>] (dump_stack+0x78/0x94)
[<c0467c60>] (dump_stack) from [<c0013f10>] (handle_IPI+0xd0/0x168)
r4:c065c158 r3:c06313b0
[<c0013e40>] (handle_IPI) from [<c000866c>] (gic_handle_irq+0x5c/0x64)
r6:c0623f30 r5:c062b190 r4:f0002100 r3:00000405
[<c0008610>] (gic_handle_irq) from [<c0012a40>] (__irq_svc+0x40/0x54)
Exception stack(0xc0623f30 to 0xc0623f78)
3f20: ffffffed 00000000 ffffffed c001da00
3f40: c0622000 00000000 00000000 c0623f88 c0620b48 ef7fcb00 00000000 c0623f84
3f60: c0623f88 c0623f78 c000f5b8 c000f5bc 60070013 ffffffff
r6:ffffffff r5:60070013 r4:c000f5bc r3:c000f5b8
[<c000f588>] (arch_cpu_idle) from [<c004ccec>] (cpu_startup_entry+0xc0/0x208)
[<c004cc2c>] (cpu_startup_entry) from [<c0465f80>] (rest_init+0x68/0x80)
r7:c062a400
[<c0465f18>] (rest_init) from [<c05e4c88>] (start_kernel+0x338/0x3a4)
[<c05e4950>] (start_kernel) from [<60008074>] (0x60008074)
r9:413fc090 r8:6000406a r7:c062e04c r6:c0612dbc r5:c062a480 r4:c065c114
---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
DDR Version 1.04 20140217
In
DDR3
300MHz
Bus Width=32 Col=10 Bank=8 Row=15 CS=2 Die Bus-Width=16 Size=2048MB
Memory OK
OUT
BUILD=====2
No.1 FLASH ID:2c 64 44 4b a9 0
OK! 282986
unsigned!
SecureBootEn = 0 0
Boot ver: 2014-03-03#2.13
start_linux=====287912
1521535 Starting kernel...@0x60408000
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.16.0-rc1 (ubuntu@radxa) (gcc version 4.8.2 (GCC) ) #2 SMP Fri Jul 18 19:10:51 UTC 2014
CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine model: Radxa Rock
bootconsole [earlycon0] enabled
Memory policy: Data cache writealloc
PERCPU: Embedded 7 pages/cpu @ee7c1000 s7680 r8192 d12800 u32768
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 522768
Kernel command line: console=ttyS2,115200 earlyprintk init=/sbin/init root=/dev/mmcblk0p1 rootwait
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 2071440K/2097152K available (4279K kernel code, 196K rwdata, 1340K rodata, 2151K init, 308K bss, 25712K reserved, 1318912K highmem)
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xffc00000 - 0xffe00000 (2048 kB)
vmalloc : 0xf0000000 - 0xff000000 ( 240 MB)
lowmem : 0xc0000000 - 0xef800000 ( 760 MB)
pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
.text : 0xc0008000 - 0xc0584f0c (5620 kB)
.init : 0xc0585000 - 0xc079ee00 (2152 kB)
.data : 0xc07a0000 - 0xc07d1300 ( 197 kB)
.bss : 0xc07d1308 - 0xc081e660 ( 309 kB)
Hierarchical RCU implementation.
NR_IRQS:16 nr_irqs:16 16
L2C-310 enabling early BRESP for Cortex-A9
L2C-310: enabling full line of zeros but not enabled in Cortex-A9
L2C-310 ID prefetch enabled, offset 15 lines
L2C-310 dynamic clock gating enabled, standby mode enabled
L2C-310 cache controller enabled, 16 ways, 512 kB
L2C-310: CACHE_ID 0x4100c0c8, AUX_CTRL 0x76050001
Rockchip-ID: 0x33313042 0x32303132 0x31313330 0x56313030
Rockchip SoC RK3188
sched_clock: 64 bits at 150MHz, resolution 6ns, wraps every 1832519401472ns
Console: colour dummy device 80x30
Calibrating delay loop... 1196.85 BogoMIPS (lpj=5984256)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
Setting up static identity map for 0x604337c8 - 0x60433820
CPU1: Booted secondary processor
CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
CPU2: Booted secondary processor
CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
CPU3: Booted secondary processor
CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
Brought up 4 CPUs
SMP: Total of 4 processors activated.
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
pinctrl core: initialized pinctrl subsystem
regulator-dummy: no parameters
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
cpuidle: using governor ladder
cpuidle: using governor menu
rockchip_clocks_apply_init_table: applying initial clock settings
rockchip_clk_init_from_table: setting rate of gpll to 891000000
rockchip_clk_init_from_table: setting rate of cpll to 600000000
rockchip_clk_init_from_table: setting rate of aclk_cpu to 300000000
rockchip_clk_init_from_table: setting rate of hclk_cpu to 150000000
rockchip_clk_init_from_table: setting rate of pclk_cpu to 75000000
rockchip_clk_init_from_table: setting rate of hclk_ahb2apb to 75000000
rockchip_clk_init_from_table: setting parent of aclk_peri_pre to cpll
rockchip_clk_init_from_table: setting rate of aclk_peri_pre to 150000000
rockchip_clk_init_from_table: setting rate of hclk_peri to 150000000
rockchip_clk_init_from_table: setting rate of pclk_peri to 75000000
rockchip_clk_init_from_table: setting rate of sclk_sdmmc to 75000000
rockchip_clk_init_from_table: setting rate of sclk_macref to 50000000
rockchip_clk_init_from_table: enabling sclk_mac_lbtest
syscon: pmu regmap [mem 0x20004000-0x200040ff] registered
syscon: grf regmap [mem 0x20008000-0x200081ff] registered
No ATAGs?
hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
hw-breakpoint: maximum watchpoint size is 4 bytes.
sdmmc-supply: 3300 mV
reg-fixed-voltage regulators:fixed-regulator@0: Failed to find supply vin
reg-fixed-voltage regulators:fixed-regulator@0: Failed to register regulator: -517
platform regulators:fixed-regulator@0: Driver reg-fixed-voltage requests probe deferral
otg-vbus: 5000 mV
usb-vbus: 5000 mV
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
i2c-gpio soc:i2c@0: using pins 58 (SDA) and 59 (SCL)
cfg80211: Calling CRDA to update world regulatory domain
Switched to clocksource arm_global_timer
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 3, 32768 bytes)
TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
futex hash table entries: 1024 (order: 4, 65536 bytes)
msgmni has been set to 1469
bounce: pool size: 64 pages
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
io scheduler noop registered
io scheduler deadline registered (default)
dma-pl330 20078000.dma: Loaded driver for PL330 DMAC-2364208
dma-pl330 20078000.dma: DBUFF-64x8bytes Num_Chans-7 Num_Peri-20 Num_Events-14
VCC_DDR: 1200 mV
VDD_LOG: 1000 mV
VDD_ARM: 875 <--> 1300 mV at 1000 mV
VCC_IO: 3300 mV
VDD_10: 1000 mV
VDD_HDMI: 2500 mV
VCC_18: 1800 mV
VCCA_33: 3300 mV
VCC_RMII: 3300 mV
VCCIO_WL: 3300 mV
VCC18_IO: 1800 mV
VCC_28: 2800 mV
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
10124000.serial: ttyS0 at MMIO 0x10124000 (irq = 66, base_baud = 1500000) is a 16550A
dw-apb-uart 10126000.serial: Couldn't set LCR to 0
dw-apb-uart 10126000.serial: Couldn't set LCR to 0
10126000.serial: ttyS1 at MMIO 0x10126000 (irq = 67, base_baud = 1500000) is a 16550A
console [ttyS2] disabled
20064000.serial: ttyS2 at MMIO 0x20064000 (irq = 68, base_baud = 1500000) is a 16550A
console [ttyS2] enabled
console [ttyS2] enabled
bootconsole [earlycon0] disabled
bootconsole [earlycon0] disabled
dw-apb-uart 20068000.serial: Couldn't set LCR to 0
dw-apb-uart 20068000.serial: Couldn't set LCR to 0
20068000.serial: ttyS3 at MMIO 0x20068000 (irq = 69, base_baud = 1500000) is a 16550A
[drm] Initialized drm 1.1.0 20060810
brd: module loaded
arc_emac 10204000.emac: ARC EMAC detected with id: 0x7fd02
arc_emac 10204000.emac: IRQ is 51
arc_emac 10204000.emac: MAC address is now c6:ef:91:8e:60:4b
libphy: Synopsys MII Bus: probed
arc_emac 10204000.emac: connected to SMSC LAN8710/LAN8720 phy with id 0x7c0f1
dwc2 10180000.dwc2: DWC OTG Controller
dwc2 10180000.dwc2: new USB bus registered, assigned bus number 1
dwc2 10180000.dwc2: irq 48, io mem 0x00000000
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: DWC OTG Controller
usb usb1: Manufacturer: Linux 3.16.0-rc1 dwc2_hsotg
usb usb1: SerialNumber: 10180000.dwc2
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
dwc2 101c0000.dwc2: DWC OTG Controller
dwc2 101c0000.dwc2: new USB bus registered, assigned bus number 2
dwc2 101c0000.dwc2: irq 49, io mem 0x00000000
usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: DWC OTG Controller
usb usb2: Manufacturer: Linux 3.16.0-rc1 dwc2_hsotg
usb usb2: SerialNumber: 101c0000.dwc2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected
mousedev: PS/2 mouse device common for all mice
rtc-hym8563 0-0051: no valid clock/calendar values available
rtc-hym8563 0-0051: rtc core: registered hym8563 as rtc0
softdog: Software Watchdog Timer: 0.08 initialized. soft_noboot=0 soft_margin=60 sec soft_panic=0 (nowayout=0)
Synopsys Designware Multimedia Card Interface Driver
dw_mmc 10214000.dwmmc: fifo-depth property not found, using value of FIFOTH register as default
platform 10214000.dwmmc: Driver dw_mmc requests probe deferral
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
usbcore: registered new interface driver r8188eu
usbcore: registered new interface driver rtl8723au
TCP: cubic registered
NET: Registered protocol family 17
sdmmc-supply: 3300 mV
sdmmc-supply: supplied by VCC_IO
dw_mmc 10214000.dwmmc: fifo-depth property not found, using value of FIFOTH register as default
dw_mmc 10214000.dwmmc: Using PIO mode.
dw_mmc 10214000.dwmmc: Version ID is 240a
dw_mmc 10214000.dwmmc: DW MMC controller at irq 55, 32 bit host data width, 256 deep fifo
dw_mmc 10214000.dwmmc: 1 slots initialized
input: soc:gpio-keys as /devices/soc/soc:gpio-keys/input/input0
rtc-hym8563 0-0051: no valid clock/calendar values available
rtc-hym8563 0-0051: hctosys: unable to read the hardware clock
usb-vbus: disabling
otg-vbus: disabling
Freeing unused kernel memory: 2148K (c0585000 - c079e000)
usb 2-1: new high-speed USB device number 2 using dwc2
usb 2-1: New USB device found, idVendor=05e3, idProduct=0608
usb 2-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
usb 2-1: Product: USB2.0 Hub
hub 2-1:1.0: USB hub found
hub 2-1:1.0: 4 ports detected
usb 2-1.1: new high-speed USB device number 3 using dwc2
usb 2-1.1: device v0bda p0724 is not supported
usb 2-1-port1: unable to enumerate USB device
Do you want to kexec a kernel over the network ? [y/n] y
* Starting DHCP on eth0
udhcpc (v1.22.1) started
Sending discover...
arc_emac 10204000.emac eth0: Link is Down
arc_emac 10204000.emac eth0: Link is Up - 100Mbps/Full - flow control off
Sending discover...
Sending select for 192.168.0.98...
Lease of 192.168.0.98 obtained, lease time 43200
/etc/udhcpc.d/50default: Adding DNS 192.168.0.20
random: nonblocking pool is initialized
* Found zImage on 192.168.0.20
Do you want to reboot to the new kernel on the fly ? [y/n] y
Modified cmdline: root=/dev/block/mtd/by-name/linuxroot
Unable to find /proc/device-tree//chosen/linux,stdout-path, printing from purgatory is diabled
Starting new kernel
Disabling non-boot CPUs ...
CPU1: shutdown
CPU2: shutdown
CPU3: shutdown
Bye!
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.18.0-rc7-next-20141203 (ubuntu@radxa) (gcc version 4.9.1 (GCC) ) #7 SMP Thu Dec 4 07:25:45 UTC 2014
CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine model: Radxa Rock
bootconsole [earlycon0] enabled
Memory policy: Data cache writealloc
PERCPU: Embedded 9 pages/cpu @ee7ba000 s7744 r8192 d20928 u36864
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 522768
Kernel command line: console=ttyS2,115200 earlyprintk root=/dev/nfs nfsroot=192.168.0.20:/var/lib/lxc/radxa/rootfs/home/ubuntu/yocto/build/tmp/rootfs,vers=4,tcp nfsrootdebug
rw ip=dhcp
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 2072880K/2097152K available (4507K kernel code, 231K rwdata, 1488K rodata, 248K init, 316K bss, 24272K reserved, 0K cma-reserved, 1318912K highmem)
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
vmalloc : 0xf0000000 - 0xff000000 ( 240 MB)
lowmem : 0xc0000000 - 0xef800000 ( 760 MB)
pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
.text : 0xc0008000 - 0xc05e300c (5997 kB)
.init : 0xc05e4000 - 0xc0622000 ( 248 kB)
.data : 0xc0622000 - 0xc065be50 ( 232 kB)
.bss : 0xc065be50 - 0xc06aae80 ( 317 kB)
Hierarchical RCU implementation.
NR_IRQS:16 nr_irqs:16 16
L2C-310 enabling early BRESP for Cortex-A9
L2C-310: enabling full line of zeros but not enabled in Cortex-A9
L2C-310 ID prefetch enabled, offset 15 lines
L2C-310 dynamic clock gating enabled, standby mode enabled
L2C-310 cache controller enabled, 16 ways, 512 kB
L2C-310: CACHE_ID 0x4100c0c8, AUX_CTRL 0x76050001
sched_clock: 64 bits at 150MHz, resolution 6ns, wraps every 1832519401472ns
Console: colour dummy device 80x30
Calibrating delay loop... 1196.85 BogoMIPS (lpj=5984256)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
rockchip_smp_prepare_cpus: ncores 4
Setting up static identity map for 0x6046c7f8 - 0x6046c850
CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
Brought up 4 CPUs
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
cpuidle: using governor ladder
cpuidle: using governor menu
No ATAGs?
hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
hw-breakpoint: maximum watchpoint size is 4 bytes.
reg-fixed-voltage sdmmc-regulator: Failed to find supply vin
reg-fixed-voltage sdmmc-regulator: Failed to register regulator: -517
platform sdmmc-regulator: Driver reg-fixed-voltage requests probe deferral
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
cfg80211: Calling CRDA to update world regulatory domain
Switched to clocksource arm_global_timer
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 3, 32768 bytes)
TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
futex hash table entries: 1024 (order: 4, 65536 bytes)
NFS: Registering the id_resolver key type
Key type id_resolver registered
Key type id_legacy registered
bounce: pool size: 64 pages
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
io scheduler noop registered
io scheduler deadline registered (default)
dma-pl330 20018000.dma-controller: Loaded driver for PL330 DMAC-241330
dma-pl330 20018000.dma-controller: DBUFF-32x8bytes Num_Chans-6 Num_Peri-12 Num_Events-12
dma-pl330 20078000.dma-controller: Loaded driver for PL330 DMAC-241330
dma-pl330 20078000.dma-controller: DBUFF-64x8bytes Num_Chans-7 Num_Peri-20 Num_Events-14
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
dw-apb-uart 10124000.serial: ttyS0 at MMIO 0x10124000 (irq = 22, base_baud = 1500000) is a 16550A
dw-apb-uart 10126000.serial: Couldn't set LCR to 191
dw-apb-uart 10126000.serial: Couldn't set LCR to 0
dw-apb-uart 10126000.serial: Couldn't set LCR to 191
dw-apb-uart 10126000.serial: Couldn't set LCR to 0
dw-apb-uart 10126000.serial: Couldn't set LCR to 0
dw-apb-uart 10126000.serial: Couldn't set LCR to 0
dw-apb-uart 10126000.serial: Couldn't set LCR to 0
dw-apb-uart 10126000.serial: Couldn't set LCR to 0
dw-apb-uart 10126000.serial: ttyS1 at MMIO 0x10126000 (irq = 23, base_baud = 1500000) is a XScale
console [ttyS2] disabled
dw-apb-uart 20064000.serial: ttyS2 at MMIO 0x20064000 (irq = 30, base_baud = 1500000) is a 16550A
console [ttyS2] enabled
console [ttyS2] enabled
bootconsole [earlycon0] disabled
bootconsole [earlycon0] disabled
dw-apb-uart 20068000.serial: Couldn't set LCR to 191
dw-apb-uart 20068000.serial: Couldn't set LCR to 0
dw-apb-uart 20068000.serial: Couldn't set LCR to 191
dw-apb-uart 20068000.serial: Couldn't set LCR to 0
dw-apb-uart 20068000.serial: Couldn't set LCR to 0
dw-apb-uart 20068000.serial: Couldn't set LCR to 0
dw-apb-uart 20068000.serial: Couldn't set LCR to 0
dw-apb-uart 20068000.serial: Couldn't set LCR to 0
dw-apb-uart 20068000.serial: ttyS3 at MMIO 0x20068000 (irq = 31, base_baud = 1500000) is a XScale
[drm] Initialized drm 1.1.0 20060810
brd: module loaded
platform 10204000.ethernet: Driver rockchip_emac requests probe deferral
dwc2 10180000.usb: Mode Mismatch Interrupt: currently in Device mode
dwc2 10180000.usb: DWC OTG Controller
dwc2 10180000.usb: new USB bus registered, assigned bus number 1
dwc2 10180000.usb: irq 24, io mem 0x00000000
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: DWC OTG Controller
usb usb1: Manufacturer: Linux 3.18.0-rc7-next-20141203 dwc2_hsotg
usb usb1: SerialNumber: 10180000.usb
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
dwc2 101c0000.usb: DWC OTG Controller
dwc2 101c0000.usb: new USB bus registered, assigned bus number 2
dwc2 101c0000.usb: irq 25, io mem 0x00000000
usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: DWC OTG Controller
usb usb2: Manufacturer: Linux 3.18.0-rc7-next-20141203 dwc2_hsotg
usb usb2: SerialNumber: 101c0000.usb
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
usbcore: registered new interface driver usb-storage
mousedev: PS/2 mouse device common for all mice
rtc-hym8563 1-0051: no valid clock/calendar values available
rtc (null): read_time: fail to read
rtc-hym8563 1-0051: rtc core: registered hym8563 as rtc0
rk3x-i2c 2002f000.i2c: Initialized RK3xxx I2C bus at f0098000
softdog: Software Watchdog Timer: 0.08 initialized. soft_noboot=0 soft_margin=60 sec soft_panic=0 (nowayout=0)
Driver 'mmcblk' needs updating - please use bus_type methods
Synopsys Designware Multimedia Card Interface Driver
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
usbcore: registered new interface driver r8188eu
usbcore: registered new interface driver rtl8723au
TCP: cubic registered
NET: Registered protocol family 17
Key type dns_resolver registered
Registering SWP/SWPB emulation handler
sdmmc-supply: supplied by VCC_IO
rockchip_emac 10204000.ethernet: ARC EMAC detected with id: 0x7fd02
rockchip_emac 10204000.ethernet: IRQ is 26
rockchip_emac 10204000.ethernet: MAC address is now 56:ed:3c:e8:59:f4
libphy: Synopsys MII Bus: probed
usb 2-1: new high-speed USB device number 2 using dwc2
rockchip_emac 10204000.ethernet: connected to SMSC LAN8710/LAN8720 phy with id 0x7c0f1
input: gpio-keys as /devices/platform/gpio-keys/input/input0
rtc-hym8563 1-0051: no valid clock/calendar values available
rtc rtc0: read_time: fail to read
rtc-hym8563 1-0051: hctosys: unable to read the hardware clock
usb 2-1: New USB device found, idVendor=05e3, idProduct=0608
usb 2-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
usb 2-1: Product: USB2.0 Hub
hub 2-1:1.0: USB hub found
hub 2-1:1.0: 4 ports detected
Sending DHCP requests .
usb 2-1.1: new high-speed USB device number 3 using dwc2
usb 2-1.1: New USB device found, idVendor=0bda, idProduct=0724
usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 2-1.1: Product: 802.11n WLAN Adapter
usb 2-1.1: Manufacturer: Realtek
usb 2-1.1: SerialNumber: 00e04c000001
random: nonblocking pool is initialized
rockchip_emac 10204000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off
., OK
IP-Config: Got DHCP answer from 192.168.0.20, my address is 192.168.0.75
IP-Config: Complete:
device=eth0, hwaddr=56:ed:3c:e8:59:f4, ipaddr=192.168.0.75, mask=255.255.255.0, gw=192.168.0.20
host=192.168.0.75, domain=, nis-domain=(none)
bootserver=192.168.0.20, rootserver=192.168.0.20, rootpath=
nameserver0=192.168.0.20
sdmmc-supply: disabling
Root-NFS: nfsroot=/var/lib/lxc/radxa/rootfs/home/ubuntu/yocto/build/tmp/rootfs,vers=4,tcp
NFS: nfs mount opts='vers=2,udp,rsize=4096,wsize=4096,vers=4,tcp,nolock,addr=192.168.0.20'
NFS: parsing nfs mount option 'vers=2'
NFS: parsing nfs mount option 'udp'
NFS: parsing nfs mount option 'rsize=4096'
NFS: parsing nfs mount option 'wsize=4096'
NFS: parsing nfs mount option 'vers=4'
NFS: parsing nfs mount option 'tcp'
NFS: parsing nfs mount option 'nolock'
NFS: parsing nfs mount option 'addr=192.168.0.20'
NFS: MNTPATH: '/var/lib/lxc/radxa/rootfs/home/ubuntu/yocto/build/tmp/rootfs'
--> nfs4_try_mount()
<-- nfs4_try_mount() = -113 [error]
NFS: nfs mount opts='vers=2,udp,rsize=4096,wsize=4096,vers=4,tcp,nolock,addr=192.168.0.20'
NFS: parsing nfs mount option 'vers=2'
NFS: parsing nfs mount option 'udp'
NFS: parsing nfs mount option 'rsize=4096'
NFS: parsing nfs mount option 'wsize=4096'
NFS: parsing nfs mount option 'vers=4'
NFS: parsing nfs mount option 'tcp'
NFS: parsing nfs mount option 'nolock'
NFS: parsing nfs mount option 'addr=192.168.0.20'
NFS: MNTPATH: '/var/lib/lxc/radxa/rootfs/home/ubuntu/yocto/build/tmp/rootfs'
--> nfs4_try_mount()
<-- nfs4_try_mount() = -113 [error]
NFS: nfs mount opts='vers=2,udp,rsize=4096,wsize=4096,vers=4,tcp,nolock,addr=192.168.0.20'
NFS: parsing nfs mount option 'vers=2'
NFS: parsing nfs mount option 'udp'
NFS: parsing nfs mount option 'rsize=4096'
NFS: parsing nfs mount option 'wsize=4096'
NFS: parsing nfs mount option 'vers=4'
NFS: parsing nfs mount option 'tcp'
NFS: parsing nfs mount option 'nolock'
NFS: parsing nfs mount option 'addr=192.168.0.20'
NFS: MNTPATH: '/var/lib/lxc/radxa/rootfs/home/ubuntu/yocto/build/tmp/rootfs'
--> nfs4_try_mount()
<-- nfs4_try_mount() = -113 [error]
NFS: nfs mount opts='vers=2,udp,rsize=4096,wsize=4096,vers=4,tcp,nolock,addr=192.168.0.20'
NFS: parsing nfs mount option 'vers=2'
NFS: parsing nfs mount option 'udp'
NFS: parsing nfs mount option 'rsize=4096'
NFS: parsing nfs mount option 'wsize=4096'
NFS: parsing nfs mount option 'vers=4'
NFS: parsing nfs mount option 'tcp'
NFS: parsing nfs mount option 'nolock'
NFS: parsing nfs mount option 'addr=192.168.0.20'
NFS: MNTPATH: '/var/lib/lxc/radxa/rootfs/home/ubuntu/yocto/build/tmp/rootfs'
--> nfs4_try_mount()
<-- nfs4_try_mount() = -113 [error]
NFS: nfs mount opts='vers=2,udp,rsize=4096,wsize=4096,vers=4,tcp,nolock,addr=192.168.0.20'
NFS: parsing nfs mount option 'vers=2'
NFS: parsing nfs mount option 'udp'
NFS: parsing nfs mount option 'rsize=4096'
NFS: parsing nfs mount option 'wsize=4096'
NFS: parsing nfs mount option 'vers=4'
NFS: parsing nfs mount option 'tcp'
NFS: parsing nfs mount option 'nolock'
NFS: parsing nfs mount option 'addr=192.168.0.20'
NFS: MNTPATH: '/var/lib/lxc/radxa/rootfs/home/ubuntu/yocto/build/tmp/rootfs'
--> nfs4_try_mount()
<-- nfs4_try_mount() = -113 [error]
NFS: nfs mount opts='vers=2,udp,rsize=4096,wsize=4096,vers=4,tcp,nolock,addr=192.168.0.20'
NFS: parsing nfs mount option 'vers=2'
NFS: parsing nfs mount option 'udp'
NFS: parsing nfs mount option 'rsize=4096'
NFS: parsing nfs mount option 'wsize=4096'
NFS: parsing nfs mount option 'vers=4'
NFS: parsing nfs mount option 'tcp'
NFS: parsing nfs mount option 'nolock'
NFS: parsing nfs mount option 'addr=192.168.0.20'
NFS: MNTPATH: '/var/lib/lxc/radxa/rootfs/home/ubuntu/yocto/build/tmp/rootfs'
--> nfs4_try_mount()
<-- nfs4_try_mount() = -113 [error]
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "nfs" or unknown-block(2,0): error -6
Please append a correct "root=" boot option; here are the available partitions:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc7-next-20141203 #7
Hardware name: Rockchip Cortex-A9 (Device Tree)
Backtrace:
[<c0011d0c>] (dump_backtrace) from [<c0011f2c>] (show_stack+0x18/0x1c)
r6:ed801000 r5:fffffffa r4:00000000 r3:00200140
[<c0011f14>] (show_stack) from [<c0467cd8>] (dump_stack+0x78/0x94)
[<c0467c60>] (dump_stack) from [<c0466c78>] (panic+0x90/0x204)
r4:c065c370 r3:00000001
[<c0466bec>] (panic) from [<c05e52c0>] (mount_block_root+0x1ec/0x22c)
r3:00000030 r2:ee10355c r1:ee059eb8 r0:c053b5fe
r7:c0612bec
[<c05e50d4>] (mount_block_root) from [<c05e54d0>] (mount_root+0xe8/0x10c)
r10:00000000 r9:c065be80 r8:c065be80 r7:00000000 r6:c065bea4 r5:c062cf40
r4:00200000
[<c05e53e8>] (mount_root) from [<c05e5658>] (prepare_namespace+0x164/0x1c4)
r7:c061fc70 r6:c0612c01 r5:c065bea4 r4:c0612bec
[<c05e54f4>] (prepare_namespace) from [<c05e4e8c>] (kernel_init_freeable+0x198/0x1e4)
r6:c0612bc8 r5:000000d3 r4:00000008
[<c05e4cf4>] (kernel_init_freeable) from [<c0465fa8>] (kernel_init+0x10/0xec)
r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c0465f98 r4:00000000
[<c0465f98>] (kernel_init) from [<c000ea58>] (ret_from_fork+0x14/0x3c)
r4:00000000 r3:ee058000
CPU2: stopping
CPU: 2 PID: 0 Comm: swapper/2 Not tainted 3.18.0-rc7-next-20141203 #7
Hardware name: Rockchip Cortex-A9 (Device Tree)
Backtrace:
[<c0011d0c>] (dump_backtrace) from [<c0011f2c>] (show_stack+0x18/0x1c)
r6:00000000 r5:00000002 r4:00000000 r3:00200040
[<c0011f14>] (show_stack) from [<c0467cd8>] (dump_stack+0x78/0x94)
[<c0467c60>] (dump_stack) from [<c0013f10>] (handle_IPI+0xd0/0x168)
r4:c065c158 r3:c06313b0
[<c0013e40>] (handle_IPI) from [<c000866c>] (gic_handle_irq+0x5c/0x64)
r6:ee079f68 r5:c062b190 r4:f0002100 r3:00000005
[<c0008610>] (gic_handle_irq) from [<c0012a40>] (__irq_svc+0x40/0x54)
Exception stack(0xee079f68 to 0xee079fb0)
9f60: ffffffed 00000000 ffffffed c001da00 ee078000 00000000
9f80: 00000000 ee079fc0 c0620b48 413fc090 00000000 ee079fbc ee079fc0 ee079fb0
9fa0: c000f5b8 c000f5bc 60000113 ffffffff
r6:ffffffff r5:60000113 r4:c000f5bc r3:c000f5b8
[<c000f588>] (arch_cpu_idle) from [<c004ccec>] (cpu_startup_entry+0xc0/0x208)
[<c004cc2c>] (cpu_startup_entry) from [<c0013c0c>] (secondary_start_kernel+0x124/0x148)
r7:c065c184
[<c0013ae8>] (secondary_start_kernel) from [<60008704>] (0x60008704)
r4:8e05c06a r3:c00086ec
CPU3: stopping
CPU: 3 PID: 0 Comm: swapper/3 Not tainted 3.18.0-rc7-next-20141203 #7
Hardware name: Rockchip Cortex-A9 (Device Tree)
Backtrace:
[<c0011d0c>] (dump_backtrace) from [<c0011f2c>] (show_stack+0x18/0x1c)
r6:00000000 r5:00000003 r4:00000000 r3:00200040
[<c0011f14>] (show_stack) from [<c0467cd8>] (dump_stack+0x78/0x94)
[<c0467c60>] (dump_stack) from [<c0013f10>] (handle_IPI+0xd0/0x168)
r4:c065c158 r3:c06313b0
[<c0013e40>] (handle_IPI) from [<c000866c>] (gic_handle_irq+0x5c/0x64)
r6:ee07bf68 r5:c062b190 r4:f0002100 r3:00000005
[<c0008610>] (gic_handle_irq) from [<c0012a40>] (__irq_svc+0x40/0x54)
Exception stack(0xee07bf68 to 0xee07bfb0)
bf60: ffffffed 00000000 ffffffed c001da00 ee07a000 00000000
bf80: 00000000 ee07bfc0 c0620b48 413fc090 00000000 ee07bfbc ee07bfc0 ee07bfb0
bfa0: c000f5b8 c000f5bc 60000113 ffffffff
r6:ffffffff r5:60000113 r4:c000f5bc r3:c000f5b8
[<c000f588>] (arch_cpu_idle) from [<c004ccec>] (cpu_startup_entry+0xc0/0x208)
[<c004cc2c>] (cpu_startup_entry) from [<c0013c0c>] (secondary_start_kernel+0x124/0x148)
r7:c065c184
[<c0013ae8>] (secondary_start_kernel) from [<60008704>] (0x60008704)
r4:8e05c06a r3:c00086ec
CPU1: stopping
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.18.0-rc7-next-20141203 #7
Hardware name: Rockchip Cortex-A9 (Device Tree)
Backtrace:
[<c0011d0c>] (dump_backtrace) from [<c0011f2c>] (show_stack+0x18/0x1c)
r6:00000000 r5:00000001 r4:00000000 r3:00200040
[<c0011f14>] (show_stack) from [<c0467cd8>] (dump_stack+0x78/0x94)
[<c0467c60>] (dump_stack) from [<c0013f10>] (handle_IPI+0xd0/0x168)
r4:c065c158 r3:c06313b0
[<c0013e40>] (handle_IPI) from [<c000866c>] (gic_handle_irq+0x5c/0x64)
r6:ee077f68 r5:c062b190 r4:f0002100 r3:00000005
[<c0008610>] (gic_handle_irq) from [<c0012a40>] (__irq_svc+0x40/0x54)
Exception stack(0xee077f68 to 0xee077fb0)
7f60: ffffffed 00000000 ffffffed c001da00 ee076000 00000000
7f80: 00000000 ee077fc0 c0620b48 413fc090 00000000 ee077fbc ee077fc0 ee077fb0
7fa0: c000f5b8 c000f5bc 60000113 ffffffff
r6:ffffffff r5:60000113 r4:c000f5bc r3:c000f5b8
[<c000f588>] (arch_cpu_idle) from [<c004ccec>] (cpu_startup_entry+0xc0/0x208)
[<c004cc2c>] (cpu_startup_entry) from [<c0013c0c>] (secondary_start_kernel+0x124/0x148)
r7:c065c184
[<c0013ae8>] (secondary_start_kernel) from [<60008704>] (0x60008704)
r4:8e05c06a r3:c00086ec
---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox