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(a)lists.fedoraproject.org
>>
https://admin.fedoraproject.org/mailman/listinfo/arm
>
> _______________________________________________
> arm mailing list
> arm(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/arm
_______________________________________________
arm mailing list
arm(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm