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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
