On 2011-09-09 12:48, David A. Marlin wrote:

Peter Robinson wrote:

...

Hey All,

I know it was discussed a while ago how the USB storage on PandaBoards was slow, not sure what the resolution was but saw this article on LWN that looks like our problem there for those that might not have seen the post elsewhere and are interested.

https://lwn.net/Articles/457145/

I have built a kernel package for f13 and f15 using Mark's patches. They are available from the xpfa repos.

http://fedoraproject.org/wiki/Architectures/Fedora_ARM_Kernels#Set_Up_the_Re...

The f15 repo can be set up just like the f13 version by using f15 in the path, i.e.:

sudo yum --nogpgcheck install \

http://dmarlin.fedorapeople.org/packages/FedoraArm/RPMS/noarch/xpfa-15-1.noa...

If you install (or update) and configure the f15 grubby (grubby-7.0.16-5.01.fc15.armv7hl.rpm) it will create the U-Boot images for you (as per the instructions mentioned above).

Notes: If you use grubby, be sure to configure /etc/sysconfig/uboot _before_ installing the kernel. This version of grubby has only been tested on a Panda board (omap) and on the Trim Slice (tegra). Be sure to install the correct kernel variant for your system, i.e.: sudo yum --enablerepo=xpfa install kernel-omap # for Panda sudo yum --enablerepo=xpfa install kernel-tegra # for Trim Slice

d.marlin

...

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

Jeffrey Bastian wrote:

On 2011-09-09 12:48, David A. Marlin wrote:

...

Peter Robinson wrote:

...

Hey All,

I know it was discussed a while ago how the USB storage on PandaBoards was slow, not sure what the resolution was but saw this article on LWN that looks like our problem there for those that might not have seen the post elsewhere and are interested.

https://lwn.net/Articles/457145/

I have built a kernel package for f13 and f15 using Mark's patches. They are available from the xpfa repos.

I installed the 2.6.40.3-0.fc14.armv7l.omap kernel on my PandaBoard (with Fedora 13) and it boots, but networking seems to be broken. The interface name has reverted back to usb0 (it was eth0 with 2.6.39) and even with the interface up and configured, I can't ping anything.

Do I need to update something else?

I'm not sure what to say, except that I obviously didn't get the latest kernel into the f13 repo. It should be:

kernel-omap-2.6.40.3-2.02.fc13.armv7l.rpm

for the f13 softfp kernel to get Mark's patch. I'll get that fixed ASAP.

On the other hand, I am running 2.6.40.3-0.fc14 on a panda here,

$ uname -a Linux panda-8.farm 2.6.40.3-0.fc14.armv7l.omap #1 SMP PREEMPT Mon Aug 22 12:46:51 EDT 2011 armv7l armv7l armv7l GNU/Linux

and networking is working fine, and is on eth0:

$ ifconfig eth0 Link encap:Ethernet HWaddr E2:D6:6D:A3:52:EF inet addr:192.168.xx.yy Bcast:192.168.255.255 Mask:255.255.0.0 :

I can ssh in, and pings out from that system also work.

I'm not sure what the problem could be, unless there is some difference in your network hardware or configuration. Does the boot log provide any clues?

Note: I am using a static IP address for eth0 since the pandas may assign an arbitrary MAC address when the system is restarted and DHCP may fail. I'm not sure if this could be related to the problem you are seeing or not.

d.marlin ===========

On 2011-09-12 11:05, David Marlin wrote:

I'm not sure what the problem could be, unless there is some difference in your network hardware or configuration. Does the boot log provide any clues?

The dmesg logs held the answer: [ 14.312866] smsc95xx: Unknown parameter `macaddr'

D'oh! I still have a /etc/modprobe.d/smsc95xx.conf file with contents options smsc95xx macaddr=CA:BC:15:4D:B4:49 from my attempts to get a persistent mac address.

This file worked with 2.6.35, and apparently it was ignored with 2.6.39, but it's breaking 2.6.40.

I removed the file and now eth0 is working again! Thanks!

It's time for another round of bonnie++

Jeff

On 2011-09-12 13:24, David Marlin wrote:

I'm glad you were able to find the problem. This kernel probably lacks the patch to handle the persistent MAC address. It does, however, have support for Flattened Device Tree, and a patch to read a MAC address from the device tree, which could be used to make the MAC address persistent.

Great! I'll give the FDT a try next.

...

It's time for another round of bonnie++

I have resync'd the xpfa yum repo for f13 and verified kernel-omap-2.6.40.3-2.02.fc13.armv7l.rpm is there. I updated the panda to 2.6.40.3-2.02 and it boots and runs without issue.

This version includes Mark Salter's patch, so you'll want it before doing the USB storage performance testing.

The bonnie++ results were mixed. Sequential reads showed a bit of a boost, but writes and random seeks took a huge hit. I published the numbers on my blog: http://jeffbastian.blogspot.com/2011/09/storage-speed-on-pandaboard-revisite...

Thanks for building the kernel!

Jeff

On 2011-09-13 10:18, Mark Salter wrote:

These numbers are for SD card in an mmc slot, right? I wouldn't expect the patch to the USB EHCI driver to have any effect on SD card speed.

Oh, you're right. I ran bonnie++ against a USB hard drive and it shows a whopping improvement!

I've edited my blog post and added the USB hard drive numbers: http://jeffbastian.blogspot.com/2011/09/storage-speed-on-pandaboard-revisite...

The big write performance hits are worrisome, though. I'd be good to test on one kernel version with and without the patch just to make sure. Also comparing SD performance with and without nosmp passed on cmdline would be interesting.

Okay, so I should run 8 tests? patch smp sd-card patch smp usb-hd patch nosmp sd-card patch nosmp usb-hd no-patch smp sd-card no-patch smp usb-hd no-patch nosmp sd-card no-patch nosmp usb-hd

Jeff

On 2011-09-13 11:18, Mark Salter wrote:

...

On 2011-09-13 10:18, Mark Salter wrote:

...

The big write performance hits are worrisome, though. I'd be good to test on one kernel version with and without the patch just to make sure. Also comparing SD performance with and without nosmp passed on cmdline would be interesting.

I already have a good idea what the results will look like for usb, so just the other four with sd-card.

I tested 2.6.40.3 with and without the DMA API patch set, and with and without the nosmp cmdline option.

The good news: the DMA API patch set does not seem to be responsible for the slow-down in SD card performance, it was equally slow with all 2.6.40.3 variants. The bad news: some other change between 2.6.35 and 2.6.40 must be responsible, so there's a lot of bisecting to do.

See the bonnie++ results at: http://jeffbastian.blogspot.com/2011/09/sd-card-speeds.html

Jeff

On Thu, Sep 15, 2011 at 06:07:52AM -0400, Jon Masters wrote:

On Fri, 2011-09-09 at 12:36 +0100, Peter Robinson wrote:

...

I know it was discussed a while ago how the USB storage on PandaBoards was slow, not sure what the resolution was but saw this article on LWN that looks like our problem there for those that might not have seen the post elsewhere and are interested.

https://lwn.net/Articles/457145/

For the record, I've raised this directly with ARM and connected a few folks who should be talking together. Mark is going to throw some time at tracking this down as he has been doing - thanks for that Mark!

Out of curiosity, I'm resurrecting this old thread: how was the slow storage problem resolved? (I assume it was resolved because storage speeds on Fedora 17 on my Pandaboard are nice and fast.)

I don't see Mark Salter's patches in the kernel, though.

Émeric Vigier mentioned (in a private email) that this may have been resolved with this patch for PL310 erratum 769419: https://lkml.org/lkml/2011/12/7/393

Was this ^^ patch the final solution? I *do* see this change in the Fedora kernel sources.

Jeff