Hi All,
I'm assuming since you've all been so quiet that the 3.7 kernel works perfectly for the intended platforms (versatile/highbank to date) and that we don't need to do anything what so ever moving forward (ROTFLOL here!) or else no one other than Paul has bothered to test it (Calxeda I am glaring at you). I would like to get this bolted down sooner rather than later as I really don't want another repeat of 3.6.
Looking at post 3.7 I'm already starting to poke around and prep things. Similar to x86-32 I'm aiming to basically have an armv7 and an armv7-PAE kernel. The PAE kernel will support LPAE and the various virt things that are starting to land in the kernel now so it will be solely for A15 chipsets. I presume the Exynos5 supports those features.
So with that I'd like some feedback from the mainline kernels guys or anyone else that is a kernelly dev sort of person with for/against suggestions and thoughts.
Peter
On 11/15/2012 03:59 AM, Peter Robinson wrote:
Looking at post 3.7 I'm already starting to poke around and prep things. Similar to x86-32 I'm aiming to basically have an armv7 and an armv7-PAE kernel. The PAE kernel will support LPAE and the various virt things that are starting to land in the kernel now so it will be solely for A15 chipsets. I presume the Exynos5 supports those features.
Nitpick: Let's call it LPAE just because it's not Intel's PAE. The primary A15 target today should be Exynos IMO, while we can build a Calxeda "highbank" (they're still calling it that upstream, but I believe they've announced the actual name, though I won't quote it just in case that isn't the case) A15 kernel once that's upstream. I looked at the patches Rob posted and it seemed pretty straightforward.
As you know, I'll have A15 hardware soon to poke also.
Jon.
On Thu, Nov 15, 2012 at 10:10 AM, Jon Masters jcm@redhat.com wrote:
On 11/15/2012 03:59 AM, Peter Robinson wrote:
Looking at post 3.7 I'm already starting to poke around and prep things. Similar to x86-32 I'm aiming to basically have an armv7 and an armv7-PAE kernel. The PAE kernel will support LPAE and the various virt things that are starting to land in the kernel now so it will be solely for A15 chipsets. I presume the Exynos5 supports those features.
Nitpick: Let's call it LPAE just because it's not Intel's PAE. The
That was actually the plan.... I'm not after the colour of the bikeshed here!
primary A15 target today should be Exynos IMO, while we can build a Calxeda "highbank" (they're still calling it that upstream, but I believe they've announced the actual name, though I won't quote it just in case that isn't the case) A15 kernel once that's upstream. I looked at the patches Rob posted and it seemed pretty straightforward.
It will be what ever is supported in the mainline kernel. Hence the reason I'm looking at 3.8 as I believe that is when the HW will start to land. There's already OMAP5 support in 3.7 to some degree so it might be that one first. Ultimately it will only ever be a unified kernel as I refuse to go backwards here so SoC specific vendor is irrelevant in the discussion :-)
As you know, I'll have A15 hardware soon to poke also.
Don't rub it in, you need to get me the HW too!
P
Is the 3.7 suitable for testing? Last time I tried, it was still in bad shape.
If it's good for testing, I'll throw it on a node tomorrow and send some results.
--Mark Langsdorf Calxeda, Inc.
________________________________________ From: arm-bounces@lists.fedoraproject.org [arm-bounces@lists.fedoraproject.org] On Behalf Of Peter Robinson [pbrobinson@gmail.com] Sent: Thursday, November 15, 2012 2:59 AM To: arm@lists.fedoraproject.org Subject: [fedora-arm] ARM kernel moving forward 3.7+
Hi All,
I'm assuming since you've all been so quiet that the 3.7 kernel works perfectly for the intended platforms (versatile/highbank to date) and that we don't need to do anything what so ever moving forward (ROTFLOL here!) or else no one other than Paul has bothered to test it (Calxeda I am glaring at you). I would like to get this bolted down sooner rather than later as I really don't want another repeat of 3.6.
Looking at post 3.7 I'm already starting to poke around and prep things. Similar to x86-32 I'm aiming to basically have an armv7 and an armv7-PAE kernel. The PAE kernel will support LPAE and the various virt things that are starting to land in the kernel now so it will be solely for A15 chipsets. I presume the Exynos5 supports those features.
So with that I'd like some feedback from the mainline kernels guys or anyone else that is a kernelly dev sort of person with for/against suggestions and thoughts.
Peter _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Hi Mark,
There is a new 3.7 rc3 kernel build here - http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=99888
The kernel suffered from the same memory overlap, here is the boot output - http://fpaste.org/7oDZ/
The memory overlap issue seems to occur specifically with Kernel RC's with debug enabled. I did not try changing the addresses used by default.
Paul
----- Original Message -----
Is the 3.7 suitable for testing? Last time I tried, it was still in bad shape.
If it's good for testing, I'll throw it on a node tomorrow and send some results.
--Mark Langsdorf Calxeda, Inc.
From: arm-bounces@lists.fedoraproject.org [arm-bounces@lists.fedoraproject.org] On Behalf Of Peter Robinson [pbrobinson@gmail.com] Sent: Thursday, November 15, 2012 2:59 AM To: arm@lists.fedoraproject.org Subject: [fedora-arm] ARM kernel moving forward 3.7+
Hi All,
I'm assuming since you've all been so quiet that the 3.7 kernel works perfectly for the intended platforms (versatile/highbank to date) and that we don't need to do anything what so ever moving forward (ROTFLOL here!) or else no one other than Paul has bothered to test it (Calxeda I am glaring at you). I would like to get this bolted down sooner rather than later as I really don't want another repeat of 3.6.
Looking at post 3.7 I'm already starting to poke around and prep things. Similar to x86-32 I'm aiming to basically have an armv7 and an armv7-PAE kernel. The PAE kernel will support LPAE and the various virt things that are starting to land in the kernel now so it will be solely for A15 chipsets. I presume the Exynos5 supports those features.
So with that I'd like some feedback from the mainline kernels guys or anyone else that is a kernelly dev sort of person with for/against suggestions and thoughts.
Peter _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
On Tue, Nov 20, 2012 at 3:14 AM, Mark Langsdorf mark.langsdorf@calxeda.com wrote:
Is the 3.7 suitable for testing? Last time I tried, it was still in bad shape.
If it's good for testing, I'll throw it on a node tomorrow and send some results.
It's good for testing as we've had a versatile qemu instance boot the unified kernel but it doesn't boot on highbank so I need feedback so we can move forward with that too. I'm working to get rc6 built too.
Peter
--Mark Langsdorf Calxeda, Inc.
From: arm-bounces@lists.fedoraproject.org [arm-bounces@lists.fedoraproject.org] On Behalf Of Peter Robinson [pbrobinson@gmail.com] Sent: Thursday, November 15, 2012 2:59 AM To: arm@lists.fedoraproject.org Subject: [fedora-arm] ARM kernel moving forward 3.7+
Hi All,
I'm assuming since you've all been so quiet that the 3.7 kernel works perfectly for the intended platforms (versatile/highbank to date) and that we don't need to do anything what so ever moving forward (ROTFLOL here!) or else no one other than Paul has bothered to test it (Calxeda I am glaring at you). I would like to get this bolted down sooner rather than later as I really don't want another repeat of 3.6.
Looking at post 3.7 I'm already starting to poke around and prep things. Similar to x86-32 I'm aiming to basically have an armv7 and an armv7-PAE kernel. The PAE kernel will support LPAE and the various virt things that are starting to land in the kernel now so it will be solely for A15 chipsets. I presume the Exynos5 supports those features.
So with that I'd like some feedback from the mainline kernels guys or anyone else that is a kernelly dev sort of person with for/against suggestions and thoughts.
Peter _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Hi Mark,
Would love feedback on the 3.7-rc7 unified kernel on Calxeda HW.
http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=102860
Cheers, Peter
On Tue, Nov 20, 2012 at 3:14 AM, Mark Langsdorf mark.langsdorf@calxeda.com wrote:
Is the 3.7 suitable for testing? Last time I tried, it was still in bad shape.
If it's good for testing, I'll throw it on a node tomorrow and send some results.
--Mark Langsdorf Calxeda, Inc.
From: arm-bounces@lists.fedoraproject.org [arm-bounces@lists.fedoraproject.org] On Behalf Of Peter Robinson [pbrobinson@gmail.com] Sent: Thursday, November 15, 2012 2:59 AM To: arm@lists.fedoraproject.org Subject: [fedora-arm] ARM kernel moving forward 3.7+
Hi All,
I'm assuming since you've all been so quiet that the 3.7 kernel works perfectly for the intended platforms (versatile/highbank to date) and that we don't need to do anything what so ever moving forward (ROTFLOL here!) or else no one other than Paul has bothered to test it (Calxeda I am glaring at you). I would like to get this bolted down sooner rather than later as I really don't want another repeat of 3.6.
Looking at post 3.7 I'm already starting to poke around and prep things. Similar to x86-32 I'm aiming to basically have an armv7 and an armv7-PAE kernel. The PAE kernel will support LPAE and the various virt things that are starting to land in the kernel now so it will be solely for A15 chipsets. I presume the Exynos5 supports those features.
So with that I'd like some feedback from the mainline kernels guys or anyone else that is a kernelly dev sort of person with for/against suggestions and thoughts.
Peter _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
On 12/01/2012 03:33 AM, Peter Robinson wrote:
Hi Mark,
Would love feedback on the 3.7-rc7 unified kernel on Calxeda HW.
http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=102860
I installed kernel, kernel-tools, kernel-tools-libs, and kernel-modules-extra. The boot started, which was nice, and proceeded through driver probing. When it came time to find the hard drive, though:
[ 3.223097] uart-pl011 fff36000.serial: no DMA platform data [ 3.293171] loop: module loaded [ 3.304994] libphy: Fixed MDIO Bus: probed [ 3.312008] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 3.320476] usbcore: registered new interface driver usbserial [ 3.326778] usbcore: registered new interface driver usbserial_generic [ 3.334087] usbserial: USB Serial support registered for generic [ 3.343052] mousedev: PS/2 mouse device common for all mice [ 3.357270] rtc-pl031 fff35000.rtc: rtc core: registered pl031 as rtc0 [ 3.372647] device-mapper: uevent: version 1.0.3 [ 3.382934] device-mapper: ioctl: 4.23.0-ioctl (2012-07-25) initialised: dm-devel@redhat.com [ 3.398526] cpuidle: using governor ladder [ 3.402673] cpuidle: using governor menu [ 3.415758] usbcore: registered new interface driver usbhid [ 3.421367] usbhid: USB HID core driver [ 3.427469] drop_monitor: Initializing network drop monitor service [ 3.436043] ip_tables: (C) 2000-2006 Netfilter Core Team [ 3.442094] TCP: cubic registered [ 3.445452] Initializing XFRM netlink socket [ 3.460771] NET: Registered protocol family 10 [ 3.479839] mip6: Mobile IPv6 [ 3.482861] NET: Registered protocol family 17 [ 3.488783] Key type dns_resolver registered [ 3.493269] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4 [ 3.501052] ThumbEE CPU extension supported. [ 3.505441] Registering SWP/SWPB emulation handler [ 3.516209] registered taskstats version 1 [ 3.529645] rtc-pl031 fff35000.rtc: setting system clock to 2012-12-04 11:54:39 UTC (1354622079) [ 3.543436] md: Waiting for all devices to be available before autodetect [ 3.550225] md: If you don't use raid, use raid=noautodetect [ 3.568496] md: Autodetecting RAID arrays. [ 3.572649] md: Scanned 0 and added 0 devices. [ 3.577091] md: autorun ... [ 3.579884] md: ... autorun DONE. [ 3.584812] Waiting for root device LABEL=rootfs...
it should look more like:
[ 1.623005] uart-pl011 fff36000.serial: no DMA platform data [ 1.631938] loop: module loaded [ 1.635406] libphy: Fixed MDIO Bus: probed [ 1.639553] calxedaxgmac fff50000.ethernet: (unregistered net_device): h/w version is 0x1012 [ 1.648391] calxedaxgmac fff51000.ethernet: (unregistered net_device): h/w version is 0x1012 [ 1.657395] usbcore: registered new interface driver usbserial [ 1.663251] usbcore: registered new interface driver usbserial_generic [ 1.669821] USB Serial support registered for generic [ 1.674876] usbserial: USB Serial Driver core [ 1.679340] mousedev: PS/2 mouse device common for all mice [ 1.685325] rtc-pl031 fff35000.rtc: rtc core: registered pl031 as rtc0 [ 1.692205] device-mapper: uevent: version 1.0.3 [ 1.697052] device-mapper: ioctl: 4.23.0-ioctl (2012-07-25) initialised: dm-devel@redhat.com [ 1.705649] cpuidle: using governor ladder [ 1.709738] cpuidle: using governor menu [ 1.714062] usbcore: registered new interface driver usbhid [ 1.719626] usbhid: USB HID core driver [ 1.723508] drop_monitor: Initializing network drop monitor service [ 1.730050] ip_tables: (C) 2000-2006 Netfilter Core Team [ 1.735409] TCP: cubic registered [ 1.738719] Initializing XFRM netlink socket [ 1.743382] NET: Registered protocol family 10 [ 1.748550] mip6: Mobile IPv6 [ 1.751516] NET: Registered protocol family 17 [ 1.756028] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4 [ 1.763703] Registering SWP/SWPB emulation handler [ 1.768802] registered taskstats version 1 [ 1.773058] rtc-pl031 fff35000.rtc: setting system clock to 2012-12-04 12:01:13 UTC (1354622473) [ 1.782285] Freeing init memory: 320K [ 1.941240] dracut: dracut-018-105.git20120927.fc17 [ 2.079625] udevd[111]: starting version 182 [ 2.181899] dracut: Starting plymouth daemon Couldn't open /dev/ttyAMA0 [ 2.398316] highbank-ahci ffe08000.sata: AHCI 0001.0300 32 slots 5 ports 3 Gbps 0x1e impl platform mode [ 2.407847] highbank-ahci ffe08000.sata: flags: ncq sntf stag pm led clo only pmp pio slum part ccc apst [ 2.424401] scsi0 : highbank-ahci [ 2.428084] scsi1 : highbank-ahci [ 2.431659] scsi2 : highbank-ahci [ 2.435277] scsi3 : highbank-ahci [ 2.438951] scsi4 : highbank-ahci [ 2.442484] ata1: DUMMY [ 2.445003] ata2: SATA max UDMA/133 mmio [mem 0xffe08000-0xffe17fff] port 0x180 irq 115 [ 2.453010] ata3: SATA max UDMA/133 mmio [mem 0xffe08000-0xffe17fff] port 0x200 irq 115 [ 2.453019] ata4: SATA max UDMA/133 mmio [mem 0xffe08000-0xffe17fff] port 0x280 irq 115 [ 2.453024] ata5: SATA max UDMA/133 mmio [mem 0xffe08000-0xffe17fff] port 0x300 irq 115 [ 2.823574] ata2: SATA link down (SStatus 0 SControl 300) [ 3.203569] ata3: SATA link down (SStatus 0 SControl 300) [ 3.583568] ata4: SATA link down (SStatus 0 SControl 300) [ 4.163566] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 4.170203] ata5.00: ATA-9: SAMSUNG MZ7PC256HAFU-000DA, CXM02W1Q, max UDMA/133 [ 4.177437] ata5.00: 500118192 sectors, multi 16: LBA48 NCQ (depth 31/32) [ 4.184462] ata5.00: configured for UDMA/133 [ 4.189048] scsi 4:0:0:0: Direct-Access ATA SAMSUNG MZ7PC256 CXM0 PQ: 0 ANSI: 5 [ 4.197630] sd 4:0:0:0: [sda] 500118192 512-byte logical blocks: (256 GB/238 GiB) [ 4.197811] sd 4:0:0:0: Attached scsi generic sg0 type 0 [ 4.210718] sd 4:0:0:0: [sda] Write Protect is off [ 4.215598] sd 4:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 4.226073] sda: sda1 sda2 sda3 [ 4.230334] sd 4:0:0:0: [sda] Attached SCSI disk [ 4.393561] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null) [ 4.544693] dracut: Checking ext4: /dev/disk/by-label/rootfs [ 4.551032] dracut: issuing e2fsck -a /dev/disk/by-label/rootfs [ 4.578903] dracut: rootfs: clean, 239103/15343616 files, 2623899/61362432 blocks [ 4.588056] dracut: Remounting /dev/disk/by-label/rootfs with -o ro [ 4.655227] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null) [ 4.674612] dracut: Mounted root filesystem /dev/sda3 [ 4.802756] dracut: Switching root [ 5.694246] SELinux: Permission wake_alarm in class capability2 not defined in policy. [ 5.702251] SELinux: Permission block_suspend in class capability2 not defined in policy. [ 5.710535] SELinux: the above unknown classes and permissions will be allowed [ 5.869337] type=1403 audit(1354622477.590:2): policy loaded auid=4294967295 ses=4294967295 [ 5.895568] systemd[1]: Successfully loaded SELinux policy in 1s 16ms 129us. [ 6.215633] systemd[1]: Relabelled /dev and /run in 171ms 604us. [ 6.643830] systemd[1]: systemd 44 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP; fedora)
Welcome to Fedora 17 (Beefy Miracle)! [ 6.659136] systemd[1]: Set hostname to <highbank-f17-hfp>.
It looks like the modules aren't being loaded. Suggested as to what I'm doing wrong?
--Mark Langsdorf Calxeda, Inc.
On Tue, Dec 4, 2012 at 4:07 PM, Mark Langsdorf mark.langsdorf@calxeda.com wrote:
On 12/01/2012 03:33 AM, Peter Robinson wrote:
Hi Mark,
Would love feedback on the 3.7-rc7 unified kernel on Calxeda HW.
http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=102860
I installed kernel, kernel-tools, kernel-tools-libs, and kernel-modules-extra. The boot started, which was nice, and proceeded through driver probing. When it came time to find the hard drive, though:
[ 3.223097] uart-pl011 fff36000.serial: no DMA platform data [ 3.293171] loop: module loaded [ 3.304994] libphy: Fixed MDIO Bus: probed [ 3.312008] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 3.320476] usbcore: registered new interface driver usbserial [ 3.326778] usbcore: registered new interface driver usbserial_generic [ 3.334087] usbserial: USB Serial support registered for generic [ 3.343052] mousedev: PS/2 mouse device common for all mice [ 3.357270] rtc-pl031 fff35000.rtc: rtc core: registered pl031 as rtc0 [ 3.372647] device-mapper: uevent: version 1.0.3 [ 3.382934] device-mapper: ioctl: 4.23.0-ioctl (2012-07-25) initialised: dm-devel@redhat.com [ 3.398526] cpuidle: using governor ladder [ 3.402673] cpuidle: using governor menu [ 3.415758] usbcore: registered new interface driver usbhid [ 3.421367] usbhid: USB HID core driver [ 3.427469] drop_monitor: Initializing network drop monitor service [ 3.436043] ip_tables: (C) 2000-2006 Netfilter Core Team [ 3.442094] TCP: cubic registered [ 3.445452] Initializing XFRM netlink socket [ 3.460771] NET: Registered protocol family 10 [ 3.479839] mip6: Mobile IPv6 [ 3.482861] NET: Registered protocol family 17 [ 3.488783] Key type dns_resolver registered [ 3.493269] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4 [ 3.501052] ThumbEE CPU extension supported. [ 3.505441] Registering SWP/SWPB emulation handler [ 3.516209] registered taskstats version 1 [ 3.529645] rtc-pl031 fff35000.rtc: setting system clock to 2012-12-04 11:54:39 UTC (1354622079) [ 3.543436] md: Waiting for all devices to be available before autodetect [ 3.550225] md: If you don't use raid, use raid=noautodetect [ 3.568496] md: Autodetecting RAID arrays. [ 3.572649] md: Scanned 0 and added 0 devices. [ 3.577091] md: autorun ... [ 3.579884] md: ... autorun DONE. [ 3.584812] Waiting for root device LABEL=rootfs...
it should look more like:
[ 1.623005] uart-pl011 fff36000.serial: no DMA platform data [ 1.631938] loop: module loaded [ 1.635406] libphy: Fixed MDIO Bus: probed [ 1.639553] calxedaxgmac fff50000.ethernet: (unregistered net_device): h/w version is 0x1012 [ 1.648391] calxedaxgmac fff51000.ethernet: (unregistered net_device): h/w version is 0x1012 [ 1.657395] usbcore: registered new interface driver usbserial [ 1.663251] usbcore: registered new interface driver usbserial_generic [ 1.669821] USB Serial support registered for generic [ 1.674876] usbserial: USB Serial Driver core [ 1.679340] mousedev: PS/2 mouse device common for all mice [ 1.685325] rtc-pl031 fff35000.rtc: rtc core: registered pl031 as rtc0 [ 1.692205] device-mapper: uevent: version 1.0.3 [ 1.697052] device-mapper: ioctl: 4.23.0-ioctl (2012-07-25) initialised: dm-devel@redhat.com [ 1.705649] cpuidle: using governor ladder [ 1.709738] cpuidle: using governor menu [ 1.714062] usbcore: registered new interface driver usbhid [ 1.719626] usbhid: USB HID core driver [ 1.723508] drop_monitor: Initializing network drop monitor service [ 1.730050] ip_tables: (C) 2000-2006 Netfilter Core Team [ 1.735409] TCP: cubic registered [ 1.738719] Initializing XFRM netlink socket [ 1.743382] NET: Registered protocol family 10 [ 1.748550] mip6: Mobile IPv6 [ 1.751516] NET: Registered protocol family 17 [ 1.756028] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4 [ 1.763703] Registering SWP/SWPB emulation handler [ 1.768802] registered taskstats version 1 [ 1.773058] rtc-pl031 fff35000.rtc: setting system clock to 2012-12-04 12:01:13 UTC (1354622473) [ 1.782285] Freeing init memory: 320K [ 1.941240] dracut: dracut-018-105.git20120927.fc17 [ 2.079625] udevd[111]: starting version 182 [ 2.181899] dracut: Starting plymouth daemon Couldn't open /dev/ttyAMA0 [ 2.398316] highbank-ahci ffe08000.sata: AHCI 0001.0300 32 slots 5 ports 3 Gbps 0x1e impl platform mode [ 2.407847] highbank-ahci ffe08000.sata: flags: ncq sntf stag pm led clo only pmp pio slum part ccc apst [ 2.424401] scsi0 : highbank-ahci [ 2.428084] scsi1 : highbank-ahci [ 2.431659] scsi2 : highbank-ahci [ 2.435277] scsi3 : highbank-ahci [ 2.438951] scsi4 : highbank-ahci [ 2.442484] ata1: DUMMY [ 2.445003] ata2: SATA max UDMA/133 mmio [mem 0xffe08000-0xffe17fff] port 0x180 irq 115 [ 2.453010] ata3: SATA max UDMA/133 mmio [mem 0xffe08000-0xffe17fff] port 0x200 irq 115 [ 2.453019] ata4: SATA max UDMA/133 mmio [mem 0xffe08000-0xffe17fff] port 0x280 irq 115 [ 2.453024] ata5: SATA max UDMA/133 mmio [mem 0xffe08000-0xffe17fff] port 0x300 irq 115 [ 2.823574] ata2: SATA link down (SStatus 0 SControl 300) [ 3.203569] ata3: SATA link down (SStatus 0 SControl 300) [ 3.583568] ata4: SATA link down (SStatus 0 SControl 300) [ 4.163566] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 4.170203] ata5.00: ATA-9: SAMSUNG MZ7PC256HAFU-000DA, CXM02W1Q, max UDMA/133 [ 4.177437] ata5.00: 500118192 sectors, multi 16: LBA48 NCQ (depth 31/32) [ 4.184462] ata5.00: configured for UDMA/133 [ 4.189048] scsi 4:0:0:0: Direct-Access ATA SAMSUNG MZ7PC256 CXM0 PQ: 0 ANSI: 5 [ 4.197630] sd 4:0:0:0: [sda] 500118192 512-byte logical blocks: (256 GB/238 GiB) [ 4.197811] sd 4:0:0:0: Attached scsi generic sg0 type 0 [ 4.210718] sd 4:0:0:0: [sda] Write Protect is off [ 4.215598] sd 4:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 4.226073] sda: sda1 sda2 sda3 [ 4.230334] sd 4:0:0:0: [sda] Attached SCSI disk [ 4.393561] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null) [ 4.544693] dracut: Checking ext4: /dev/disk/by-label/rootfs [ 4.551032] dracut: issuing e2fsck -a /dev/disk/by-label/rootfs [ 4.578903] dracut: rootfs: clean, 239103/15343616 files, 2623899/61362432 blocks [ 4.588056] dracut: Remounting /dev/disk/by-label/rootfs with -o ro [ 4.655227] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null) [ 4.674612] dracut: Mounted root filesystem /dev/sda3 [ 4.802756] dracut: Switching root [ 5.694246] SELinux: Permission wake_alarm in class capability2 not defined in policy. [ 5.702251] SELinux: Permission block_suspend in class capability2 not defined in policy. [ 5.710535] SELinux: the above unknown classes and permissions will be allowed [ 5.869337] type=1403 audit(1354622477.590:2): policy loaded auid=4294967295 ses=4294967295 [ 5.895568] systemd[1]: Successfully loaded SELinux policy in 1s 16ms 129us. [ 6.215633] systemd[1]: Relabelled /dev and /run in 171ms 604us. [ 6.643830] systemd[1]: systemd 44 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP; fedora)
Welcome to Fedora 17 (Beefy Miracle)! [ 6.659136] systemd[1]: Set hostname to <highbank-f17-hfp>.
It looks like the modules aren't being loaded. Suggested as to what I'm doing wrong?
We might need to add the new calxeda sata module (this is booting off sata?) to the dracut include list. Remind me what the module name is and I'll cross check it.
Peter
On 12/04/2012 10:19 AM, Peter Robinson wrote:
On Tue, Dec 4, 2012 at 4:07 PM, Mark Langsdorf mark.langsdorf@calxeda.com wrote:
On 12/01/2012 03:33 AM, Peter Robinson wrote:
Hi Mark,
Would love feedback on the 3.7-rc7 unified kernel on Calxeda HW.
http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=102860
I installed kernel, kernel-tools, kernel-tools-libs, and kernel-modules-extra. The boot started, which was nice, and proceeded through driver probing. When it came time to find the hard drive, though:
...
It looks like the modules aren't being loaded. Suggested as to what I'm doing wrong?
We might need to add the new calxeda sata module (this is booting off sata?) to the dracut include list. Remind me what the module name is and I'll cross check it.
This is booting off SATA. The module name is sata-highbank.
I don't have this problem when custom building 3.6 kernels for f17 & f18.
--Mark Langsdorf Calxeda, Inc.
We might need to add the new calxeda sata module (this is booting off sata?) to the dracut include list. Remind me what the module name is and I'll cross check it.
This is booting off SATA. The module name is sata-highbank.
Can you try this dracut and regenerate
http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1282787
I don't have this problem when custom building 3.6 kernels for f17 & f18.
But then I'm sure you build the sata kernel modules in and specifying Calxeda specifics as opposed to a generic unified kernel that is ultimately going to need to support 100s of devices from numerous SoCs.
Peter
On Tue, Dec 4, 2012 at 10:56 PM, Peter Robinson pbrobinson@gmail.com wrote:
We might need to add the new calxeda sata module (this is booting off sata?) to the dracut include list. Remind me what the module name is and I'll cross check it.
This is booting off SATA. The module name is sata-highbank.
Can you try this dracut and regenerate
.... regenerate the initrd
http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1282787
I don't have this problem when custom building 3.6 kernels for f17 & f18.
But then I'm sure you build the sata kernel modules in and specifying Calxeda specifics as opposed to a generic unified kernel that is ultimately going to need to support 100s of devices from numerous SoCs.
Peter
On 12/04/2012 04:56 PM, Peter Robinson wrote:
We might need to add the new calxeda sata module (this is booting off sata?) to the dracut include list. Remind me what the module name is and I'll cross check it.
This is booting off SATA. The module name is sata-highbank.
Can you try this dracut and regenerate the initrd
http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1282787
Is there supposed to be an rpm I can download there? I don't see one. What am I missing here?
I don't have this problem when custom building 3.6 kernels for f17 & f18.
But then I'm sure you build the sata kernel modules in and specifying Calxeda specifics as opposed to a generic unified kernel that is ultimately going to need to support 100s of devices from numerous SoCs.
I always build the sata as a module.
I should have said I don't have an issue when building 3.7-rcX, and I use the same scripts and dracut there (with the generic unified kernel) as I do when I'm building the stock 3.6 kernel.
I'm not complaining, I'm just curious about the difference.
--Mark Langsdorf Calxeda, Inc.
On Wed, Dec 5, 2012 at 4:30 PM, Mark Langsdorf mark.langsdorf@calxeda.com wrote:
On 12/04/2012 04:56 PM, Peter Robinson wrote:
We might need to add the new calxeda sata module (this is booting off sata?) to the dracut include list. Remind me what the module name is and I'll cross check it.
This is booting off SATA. The module name is sata-highbank.
Can you try this dracut and regenerate the initrd
http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1282787
Is there supposed to be an rpm I can download there? I don't see one. What am I missing here?
It's a scratch build task so you need to click on the arch (armv5tel / armv7) to get the rpms.
I don't have this problem when custom building 3.6 kernels for f17 & f18.
But then I'm sure you build the sata kernel modules in and specifying Calxeda specifics as opposed to a generic unified kernel that is ultimately going to need to support 100s of devices from numerous SoCs.
I always build the sata as a module.
I should have said I don't have an issue when building 3.7-rcX, and I use the same scripts and dracut there (with the generic unified kernel) as I do when I'm building the stock 3.6 kernel.
I'm not complaining, I'm just curious about the difference.
Do you have the modules specified in a config like modprobe.conf or something? I'm not sure but I would love to find out.
Peter
On 12/05/2012 10:44 AM, Peter Robinson wrote:
On Wed, Dec 5, 2012 at 4:30 PM, Mark Langsdorf mark.langsdorf@calxeda.com wrote:
On 12/04/2012 04:56 PM, Peter Robinson wrote:
We might need to add the new calxeda sata module (this is booting off sata?) to the dracut include list. Remind me what the module name is and I'll cross check it.
This is booting off SATA. The module name is sata-highbank.
Can you try this dracut and regenerate the initrd
http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1282787
Is there supposed to be an rpm I can download there? I don't see one. What am I missing here?
It's a scratch build task so you need to click on the arch (armv5tel / armv7) to get the rpms.
The dracut took me straight into f19 dependency hell. Is there a way I can update my system to f19 first?
But then I'm sure you build the sata kernel modules in and specifying Calxeda specifics as opposed to a generic unified kernel that is ultimately going to need to support 100s of devices from numerous SoCs.
I always build the sata as a module.
I should have said I don't have an issue when building 3.7-rcX, and I use the same scripts and dracut there (with the generic unified kernel) as I do when I'm building the stock 3.6 kernel.
I'm not complaining, I'm just curious about the difference.
Do you have the modules specified in a config like modprobe.conf or something? I'm not sure but I would love to find out.
I don't think so. I pulled the 3.7 kernel and then used a dracut script that I got from David Marlin. I couldn't find a modprobe.conf or anything similar - just modules.dep but that's created after the initramfs.
--Mark Langsdorf Calxeda, Inc.
On Tue, Dec 4, 2012 at 11:07 AM, Mark Langsdorf mark.langsdorf@calxeda.com wrote:
On 12/01/2012 03:33 AM, Peter Robinson wrote:
Hi Mark,
Would love feedback on the 3.7-rc7 unified kernel on Calxeda HW.
http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=102860
I installed kernel, kernel-tools, kernel-tools-libs, and kernel-modules-extra. The boot started, which was nice, and proceeded
You shouldn't need kernel-modules-extra or kernel-tools. Just an FYI.
through driver probing. When it came time to find the hard drive, though:
[ 3.223097] uart-pl011 fff36000.serial: no DMA platform data [ 3.293171] loop: module loaded [ 3.304994] libphy: Fixed MDIO Bus: probed [ 3.312008] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 3.320476] usbcore: registered new interface driver usbserial [ 3.326778] usbcore: registered new interface driver usbserial_generic [ 3.334087] usbserial: USB Serial support registered for generic [ 3.343052] mousedev: PS/2 mouse device common for all mice [ 3.357270] rtc-pl031 fff35000.rtc: rtc core: registered pl031 as rtc0 [ 3.372647] device-mapper: uevent: version 1.0.3 [ 3.382934] device-mapper: ioctl: 4.23.0-ioctl (2012-07-25) initialised: dm-devel@redhat.com [ 3.398526] cpuidle: using governor ladder [ 3.402673] cpuidle: using governor menu [ 3.415758] usbcore: registered new interface driver usbhid [ 3.421367] usbhid: USB HID core driver [ 3.427469] drop_monitor: Initializing network drop monitor service [ 3.436043] ip_tables: (C) 2000-2006 Netfilter Core Team [ 3.442094] TCP: cubic registered [ 3.445452] Initializing XFRM netlink socket [ 3.460771] NET: Registered protocol family 10 [ 3.479839] mip6: Mobile IPv6 [ 3.482861] NET: Registered protocol family 17 [ 3.488783] Key type dns_resolver registered [ 3.493269] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4 [ 3.501052] ThumbEE CPU extension supported. [ 3.505441] Registering SWP/SWPB emulation handler [ 3.516209] registered taskstats version 1 [ 3.529645] rtc-pl031 fff35000.rtc: setting system clock to 2012-12-04 11:54:39 UTC (1354622079) [ 3.543436] md: Waiting for all devices to be available before autodetect [ 3.550225] md: If you don't use raid, use raid=noautodetect [ 3.568496] md: Autodetecting RAID arrays. [ 3.572649] md: Scanned 0 and added 0 devices. [ 3.577091] md: autorun ... [ 3.579884] md: ... autorun DONE. [ 3.584812] Waiting for root device LABEL=rootfs...
That looks more like "I didn't use an initramfs" or "my initramfs didn't load" than anything. What was the full cmdline passed and do you see messages earlier in the boot about the initramfs?
it should look more like:
<snip>
[ 1.782285] Freeing init memory: 320K [ 1.941240] dracut: dracut-018-105.git20120927.fc17
initramfs ^
josh
-
Jon Masters -
Josh Boyer -
Mark Langsdorf -
Paul Whalen -
Peter Robinson