[fedora-arm] F19 install on mirabox
Jochen De Smet
jochen.arm at leahnim.org
Sun Jul 21 18:42:34 UTC 2013
And more information, with some kernel woes.
When I compile the 3.10 kernel with my config on F18, the first compilation
aborts with:
CC [M] fs/ubifs/budget.o
CC [M] fs/ubifs/find.o
fs/ubifs/find.c: In function ‘ubifs_save_dirty_idx_lnums’:
fs/ubifs/find.c:771:18: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugzilla.redhat.com/bugzilla> for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.
make[2]: *** [fs/ubifs/find.o] Error 1
make[1]: *** [fs/ubifs] Error 2
make: *** [fs] Error 2
Just re-running "make" after that successfully produces a kernel, and
the result
appears to work fine.
Compiling the same kernel and config on F19 does not give any errors and
produces a kernel, but it doesn't quite work. It appears to boot fine,
but soon
oopses with something like the below (don't think it's the same every boot):
Unable to handle kernel NULL pointer dereference at virtual address 0000001c
pgd = ee0b8000
[0000001c] *pgd=2e2c2831, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#1] ARM
Modules linked in: ipt_MASQUERADE iscsi_tcp libiscsi_tcp libiscsi
iptable_nat nf_nat_ipv4 nf_nat drbd lru_cache scsi_transport_iscsi
iptable_mangle ipt_REJECT xt_conntrack iptable_filter ip_tables ext3 jbd
autofs4 ext4 jbd2 mbcache sd_mod usb_storage mmc_block mvsdio mmc_core
ehci_orion
CPU: 0 PID: -1073560872 Comm: bash Not tainted 3.10.0-stock1 #23
task: ee1df440 ti: ee154000 task.ti: ee154000
PC is at __task_pid_nr_ns+0x40/0xa4
LR is at schedule_tail+0x44/0x64
pc : [<c0037c4c>] lr : [<c00439e0>] psr: 60000013
sp : ee155f88 ip : ee155f88 fp : ee155f94
r10: 00000000 r9 : 00000000 r8 : 00000000
r7 : 00000000 r6 : 00000000 r5 : bf000000 r4 : ee154000
r3 : ef181efc r2 : 00000000 r1 : 00000000 r0 : ee1df440
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 10c5387d Table: 2e0b8019 DAC: 00000015
Process bash (pid: -1073560872, stack limit = 0xee154230)
Stack: (0xee155f88 to 0xee156000)
5f80: ee155fac ee155f98 c00439e0 c0037c18 00000000
00000000
5fa0: 00000000 ee155fb0 c000df48 c00439a8 00000000 00000000 00000000
00000000
5fc0: b6fc3068 bed65f08 48a50000 00000078 000d6d64 b6fc3000 000d63cc
bed65f34
5fe0: b6fc34c0 bed65f08 00000a18 489aa0cc 60000010 01200011 00000000
00000000
Backtrace:
[<c0037c0c>] (__task_pid_nr_ns+0x0/0xa4) from [<c00439e0>]
(schedule_tail+0x44/0x64)
[<c004399c>] (schedule_tail+0x0/0x64) from [<c000df48>]
(ret_from_fork+0x4/0x3c)
r5:00000000 r4:00000000
Code: e0831101 e5913120 e3530000 0a00000c (e592101c)
---[ end trace 20369176bc42626e ]---
Unable to handle kernel paging request at virtual address 2e6f2e7a
pgd = c0004000
[2e6f2e7a] *pgd=00000000
Internal error: Oops: 15 [#2] ARM
Modules linked in: ipt_MASQUERADE iscsi_tcp libiscsi_tcp libiscsi
iptable_nat nf_nat_ipv4 nf_nat drbd lru_cache scsi_transport_iscsi
iptable_mangle ipt_REJECT xt_conntrack iptable_filter ip_tables ext3 jbd
autofs4 ext4 jbd2 mbcache sd_mod usb_storage mmc_block mvsdio mmc_core
ehci_orion
CPU: 0 PID: -1073560872 Comm: bash Tainted: G D 3.10.0-stock1 #23
task: ee1df440 ti: ee154000 task.ti: ee154000
PC is at acct_process+0x34/0x88
LR is at acct_process+0x20/0x88
pc : [<c005bb78>] lr : [<c005bb64>] psr: 20000013
sp : ee155d48 ip : ee155d48 fp : ee155d5c
r10: ef238080 r9 : ee1df440 r8 : 00000017
r7 : ee154000 r6 : c034afb0 r5 : e5911018 r4 : ee154020
r3 : 00000000 r2 : ee155d48 r1 : ef238080 r0 : 2e6f2e72
Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 10c5387d Table: 2f35c019 DAC: 00000015
Process bash (pid: -1073560872, stack limit = 0xee154230)
Stack: (0xee155d48 to 0xee156000)
5d40: ee154020 00000000 ee155d94 ee155d60 c0022070
c005bb50
5d60: c03c45f0 00000001 ef2380b8 00000017 ee1df440 c03e0ac0 ee155d94
ee155d88
5d80: c001decc ee154000 ee155dd4 ee155d98 c0011afc c00219f4 ee154230
0000000b
5da0: 60000113 ee154000 c0356054 0000001c 00000017 ef238080 ee155f40
ef238080
5dc0: ee1df440 00000028 ee155dec ee155dd8 c02bd6dc c0011984 ee155f40
0000001c
5de0: ee155e8c ee155df0 c02c3794 c02bd67c ee155e14 ee155e00 c004374c
c00435a4
5e00: ee7b1b80 00000000 00010000 00000000 ef2380b8 00000000 c03c9ea0
00000001
5e20: ee155e64 ee155e30 c00465a0 c03c9ed8 ee1dfb78 00000400 ee155e5c
ee155e48
5e40: ffffffff 00000000 ee155e7c ee155e58 c02c3a88 c0009038 ffffffff
ef18001c
5e60: ee1df440 00000017 c02c35b0 c03c5064 0000001c ee155f40 00000000
00000000
5e80: ee155f3c ee155e90 c0008428 c02c35bc c02c22b4 c02c3af8 ee155f44
ee155ea8
5ea0: c002dab0 c0022f58 00000011 c02c128c c03f6ab0 c03c00d0 c03e07c6
ee154018
5ec0: 00000000 00000000 ee155ef4 ee155ed8 c0042cbc c00465c4 00000000
ee1df440
5ee0: 00000001 ee1df440 ee155f14 ee155ef8 c0044cf8 c0042c98 00000000
ee1df440
5f00: 00000004 ee0bcb80 c03cb00c ee154000 00000000 ee1df534 ee1df438
c0037c4c
5f20: 60000013 ffffffff ee155f74 00000000 ee155f94 ee155f40 c02c1f18
c00083f4
5f40: ee1df440 00000000 00000000 ef181efc ee154000 bf000000 00000000
00000000
5f60: 00000000 00000000 00000000 ee155f94 ee155f88 ee155f88 c00439e0
c0037c4c
5f80: 60000013 ffffffff ee155fac ee155f98 c00439e0 c0037c18 00000000
00000000
5fa0: 00000000 ee155fb0 c000df48 c00439a8 00000000 00000000 00000000
00000000
5fc0: b6fc3068 bed65f08 48a50000 00000078 000d6d64 b6fc3000 000d63cc
bed65f34
5fe0: b6fc34c0 bed65f08 00000a18 489aa0cc 60000010 01200011 00000000
00000000
Backtrace:
[<c005bb44>] (acct_process+0x0/0x88) from [<c0022070>] (do_exit+0x688/0x87c)
r5:00000000 r4:ee154020
[<c00219e8>] (do_exit+0x0/0x87c) from [<c0011afc>] (die+0x184/0x238)
r7:ee154000
[<c0011978>] (die+0x0/0x238) from [<c02bd6dc>]
(__do_kernel_fault.part.9+0x6c/0x7c)
[<c02bd670>] (__do_kernel_fault.part.9+0x0/0x7c) from [<c02c3794>]
(do_page_fault+0x1e4/0x3e4)
r7:0000001c r3:ee155f40
[<c02c35b0>] (do_page_fault+0x0/0x3e4) from [<c0008428>]
(do_DataAbort+0x40/0xa0)
[<c00083e8>] (do_DataAbort+0x0/0xa0) from [<c02c1f18>]
(__dabt_svc+0x38/0x60)
Exception stack(0xee155f40 to 0xee155f88)
5f40: ee1df440 00000000 00000000 ef181efc ee154000 bf000000 00000000
00000000
5f60: 00000000 00000000 00000000 ee155f94 ee155f88 ee155f88 c00439e0
c0037c4c
5f80: 60000013 ffffffff
r8:00000000 r7:ee155f74 r6:ffffffff r5:60000013 r4:c0037c4c
[<c0037c0c>] (__task_pid_nr_ns+0x0/0xa4) from [<c00439e0>]
(schedule_tail+0x44/0x64)
[<c004399c>] (schedule_tail+0x0/0x64) from [<c000df48>]
(ret_from_fork+0x4/0x3c)
r5:00000000 r4:00000000
Code: 089da830 e595002c e3500000 0a00000f (e5903008)
---[ end trace 20369176bc42626f ]---
J.
On 7/21/2013 2:13, Jochen De Smet wrote:
> And some more progress.
>
> The network functions fine if and only if I use the network in U-boot,
> i.e. a
> simple "dhcp ; setenv ethact egiga1 ; dhcp" before booting from the sd
> makes everything work, at least temporarily. Bringing the interface up
> and
> down a few times appear to break things again, but as long as I just
> let it
> stay up it functions without any apparent issues.
>
> So I guess this means there might be some initialization missing in
> the kernel
> driver for the 370 NICs ?
>
> On a bright note, that means I now have both interfaces working on my F18
> box as well; the reason eth0 didn't work there but eth1 did, was
> because eth1
> is used there to network load the kernel/initrd.
>
> I did still have to add a file /etc/udev/rules.d/40-network.rules with
> contents
> like this:
>
> KERNELS=="d0070000.ethernet", RUN += "/sbin/ip link set dev eth0
> address F0:AD:4E:01:E1:D2"
> KERNELS=="d0074000.ethernet", RUN += "/sbin/ip link set dev eth1
> address F0:AD:4E:01:E1:D3"
>
> to make NetworkManager happy (replace those MACs with the ones on the
> mirabox label if you're
> doing this), since otherwise I still ended up with a new random MAC on
> every boot.
>
> I also re-learned that you do indeed have to copy your preferred
> kernel to uImage; you can't
> symlink it. Otherwise a kernel update through yum will happily
> overwrite your kernel. That also
> taught me that the updated F19 kernel (3.9.9-302) does not boot on the
> mirabox; it's worse
> than the 3.9.5-301 in the xz; no kernel output whatsoever.
>
> One last note is on the microSD performance, which appears to be very
> slow from u-boot. Loading
> the 10MB initrd takes over 45 seconds, as compared to maybe 2 or 3
> when loading from the
> network. Under linux, a copy of the same file also takes just a few
> seconds.
>
> J.
>
>
> On 7/20/2013 2:49, Jochen De Smet wrote:
>>
>> Some progress.
>>
>> Still can't get it to work with the fedora kernel, but I did manage
>> to get it booted
>> using the same kernel I use for F18 ; had to explicitly tell dracut
>> to include the usb
>> driver to be able to find the root partition.
>>
>> Also had to enable the serial getty. Is there any particular reason
>> why this isn't
>> enabled by default on arm ?
>>
>> So now I'm booted, but network-wise things are looking rather grim. I
>> can see both
>> interfaces, NetworkManager recognizes them, and ethtool confirms link
>> at the
>> expected speed. However that's as far as things get.
>>
>> On eth0, running tcpdump shows me all my outgoing packets (DHCP/ARP)
>> and even
>> RIP packets from the router it's attached to, but nothing else. No
>> DHCP reply from
>> the router. Putting on a static IP doesn't help either.
>>
>> On eth1, things are slightly worse. All the same problems as eth0,
>> but in addition
>> I'm seeing these when running tcpdump:
>> mvneta d0074000.ethernet eth1: bad rx status 0cc10000 (crc error),
>> size=129
>> mvneta d0074000.ethernet eth1: bad rx status 0cc10000 (crc error),
>> size=125
>> mvneta d0074000.ethernet eth1: bad rx status 0cc10000 (crc error),
>> size=151
>> mvneta d0074000.ethernet eth1: bad rx status 0cc10000 (crc error),
>> size=157
>> mvneta d0074000.ethernet eth1: bad rx status 0cc10000 (crc error),
>> size=158
>>
>> J.
>>
>>
>>
>> On 7/19/2013 16:23, Jochen De Smet wrote:
>>> On 7/19/2013 16:03, Jon wrote:
>>>> Here are my notes on MiraBox.
>>>> (These are adapted from Jon Masters)
>>> Thanks!
>>>
>>> Indeed, the SD reader is behind a usb bus so usb needs to be started
>>> in u-boot to get to the card.
>>>
>>> Using those instructions the kernel at least starts booting, makes it
>>> to the initrd but then appears to hang at this point:
>>>
>>> [ OK ] Mounted Configuration File System.
>>> Starting LVM2 metadata daemon...
>>> [ OK ] Started Apply Kernel Variables.
>>> [ OK ] Started Create static device nodes in /dev.
>>> Starting udev Kernel Device Manager...
>>> [ OK ] Started LVM2 metadata daemon.
>>> systemd-fsck[239]: _/: clean, 44920/397488 files, 338291/1586914 blocks
>>> [ OK ] Started File System Check on Root Device.
>>> Starting Remount Root and Kernel File Systems...
>>> [ OK ] Started udev Kernel Device Manager.
>>> [ 214.643245] systemd-udevd[250]: starting version 204
>>> [ 214.662018] EXT4-fs (sdb3): re-mounted. Opts: (null)
>>> [ OK ] Started udev Coldplug all Devices.
>>> Starting udev Wait for Complete Device Initialization...
>>> [ OK ] Started Remount Root and Kernel File Systems.
>>> [ OK ] Reached target Local File Systems (Pre).
>>> Starting Configure read-only root support...
>>> [ OK ] Started Monitoring of LVM2 mirrors, snapshots etc.
>>> u...ogress polling.
>>> [ OK ] Started Configure read-only root support.
>>> Starting Load Random Seed...
>>> [ OK ] Started Load Random Seed.
>>> [ OK ] Found device /dev/ttyS0.
>>> [ 215.468098] mvneta d0070000.ethernet eth0: mac: 06:a4:a7:49:fe:24
>>> [ 215.522508] libphy: orion_mdio_bus: probed
>>>
>>> I'll leave it alone for a while to see if it eventually makes it
>>> through. Should I expect some
>>> installer to start running at some point? Or is the root partition
>>> inside the image .xz really
>>> just the equivalent of the old FC18 root fs images with no more
>>> changes to it needed?
>>>
>>> J.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> arm mailing list
>>> arm at lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/arm
>>
>> _______________________________________________
>> arm mailing list
>> arm at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/arm
>
> _______________________________________________
> arm mailing list
> arm at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/arm
More information about the arm
mailing list