as I think I posted already, I set up two different (wheezy & squeeze) distros with rootfs on USB drives (sticks not HDD) and in both cases after recent updates they were very slow, especially the Wheezy one. its clear people are successfully doing this so I don't understand why this has occurred, whether it's something to do with the individual USB drives (a Sandisk Cruzer 8GB and a Transcend JetFlash 32gb), the USB driver or powered hub (just the keyboard and USB drive in the hub and the mouse in the other USB port), or what. I intend to try again with the Rasbian distro once asb has got the repository updated this weekend but I'm not convinced it will be any different. it's very frustrating.

ren41 wrote:as I think I posted already, I set up two different (wheezy & squeeze) distros with rootfs on USB drives (sticks not HDD) and in both cases after recent updates they were very slow, especially the Wheezy one. its clear people are successfully doing this so I don't understand why this has occurred, whether it's something to do with the individual USB drives (a Sandisk Cruzer 8GB and a Transcend JetFlash 32gb), the USB driver or powered hub (just the keyboard and USB drive in the hub and the mouse in the other USB port), or what. I intend to try again with the Rasbian distro once asb has got the repository updated this weekend but I'm not convinced it will be any different. it's very frustrating.

If you want this fixed, you need to identify the change that caused the slowdown.
GitHub contains a complete history of kernels and start.elfs. If you tell me, for example it was a specific checkin to start.elf that caused the slowdown I'd sure we can remedy it.

(there was a change to start.elf on the 17th that caused a slowdown, but it was fixed on the 18th - you are sure you are not on that version?)

yes - I know I ran raspberrypi, and also did an update from github last Sunday which was supposed to contain the most up to date firmware (dated the 14th) - I think I mentioned that on the previous post I did, which I think was on the wheezy thread. I believe the version came up as #68.

My squeeze was working really well both from the SD card and then from the USB drive prior to this but I decided to wipe that and install Rasbian. I think the smaller SD Card still has wheezy on it, I'll check. And in the meantime I will try moving the rootfs from Rasbian onto the USB drive and see what happens.

I think I said that the only thing which came up during the boot sequence was the line about GET_EVENT & TUR disagreeing but I saw that ignoring GET_EVENT was the accepted workaround for that. The powered hub (Neweer?) does appear to be USB 1 but it seemed quick enough originally on Squeeze so I don't think it can be that.

Note that, when I actually got wheezy to boot, as well as being incredibly slow, my keyboard malfunctioned - keys auto-repeating by themselves, or intermittently failing to respond. The troubleshooting guides say that this suggests a power problem, but (a) it never happened with squeeze, and (b) it continued even with nothing else plugged into the Pi, with 2 different keyboards, and with 2 different chargers. It seemed like there is some sort of issue with either the power or the USB management.

I have Raspbian on the USB stick now (Transcend JetFlash 32gb). I haven't done any actual benchmarks but it takes 90 secs to boot as opposed to 55 secs on SD card, and 90 secs from 'startx' to a fully populated lxde desktop - as opposed to 13 secs with everything on SD card.

I haven't had a chance to retry the last Wheezy image to see what happens with that.

Just FYI Raspbian wheezy works fine for me, with none of the problems I encountered from the Debian wheezy beta. It's still slower than squeeze to boot, but only by a few seconds possibly just due to the fact that it does more, and it seems to be a lot faster in use.

OK, I got a chance this evening to move back to the SD card with my Rasbian install, from the USB stick (Transcend JetFlash 32gb). As performance was so bad I hadn't run update/upgrade or rpi-update, so I changed back purely by altering the target in cmdline.txt. The SD card is a Sandisk microSD 16GB card in an adapter - the writing on it is very faint so I can't give a serial/product number offhand.

I tried this originally with Squeeze and initially experienced a very marginal speed increase on the USB drive, but after I updated in mid-July I got very slow performance out of the USB drive, much slower than the times above. At the same time I did a new install of the then latest Wheezy image and compared a Sandisk Cruzer 8gb USB stick with a Sandisk 4gb class 4 SD card and got the same dreadful results with this same Transcend USB stick, 300 secs to boot to login prompt and 165 secs to fully populate lxde from startx prompt - and the same with a Sandisk Cruzer 8gb stick.

Either these two USB sticks are the worst possible options or someone somewhere must have had similar experiences! Anyone?

There are some sdcard improvements pushed to guthub. You can get the updates with rpi-update.

It includes lb's pull request:
"Here are two more changes for the SDHCI driver.

The extension FIFO is an additional buffer for the data register and can slightly speed up transfers, works fine for me (results might vary with SD cards, it's just barely faster with the one card I tested with). lp0 enabled it with good results, too.

The other commit tries to tackle the dataloss bug on the FAT partition some people are seeing (usually after editing config.txt)."

It also adds another command line parameter "missing_status" which significantly improves interrupt latency. It again could help USB packet loss and audio glitches. You need to enable these:
sdhci-bcm2708.missing_status=0 sdhci-bcm2708.sync_after_dma=0
added to command line. I haven't made these a default yet, but I will soon if no one complains.

Wow, don't know if it's just my sd card or what. Going from the july 25th raspbian untested repository update to this significantly reduced boot time for me. About 8 seconds shaved off. Boots to desktop in 33 seconds, down from 41.

I can report that after updating the firmware, I was able to boot the RPi too, while previously it failed (elf file corrupted).
But then I've done the config.txt "torture" test and it got corrupted (with "sutdown -h now").
I've made a bash script called "poweroff" that executes sync 3 times and a 5 seconds pause before the shutdown command and it seems to solve the issues.
I've put the Samsung 8GB class 10 SD card aside and with my backup image I flashed a brand new Sandisk Extreme 16GB Class 10 (45MB/s).
Time will tell if it behaves better. Anyway, I'll "poweroff" from now on.

After unplugging my pi the latest firmware fails to boot. Rebooting was fine before I unplugged it. As does rolling back to previous elfs. No combination of config.txt or cmdline.txt parameters appears to affect this. Tried redownloading the elfs myself to no avail.

It appears to be reading the first half of the config.txt. All of my overscan settings are applied but not my framebuffer size(I can tell by the size/shape/position of the r-pi logo). Deleting everything from config.txt has no affect. arm240_start.elf works perfectly though.

portets wrote:
It appears to be reading the first half of the config.txt. All of my overscan settings are applied but not my framebuffer size(I can tell by the size/shape/position of the r-pi logo). Deleting everything from config.txt has no affect. arm240_start.elf works perfectly though.

I'm surprised it reads *some* of config.txt. Can you try changing overscan settings and confirm they are actually acted on.

Yeah, just checked. Overscan settings are definitely applied, but framebuffer size isn't. Doesn't matter where things are placed in the config file. Empty config file doesn't boot either. With and without the two new cmdline.txt arguments, doesn't matter. And the status led's on-board all behave completely normal aside from disk access, which turns off as soon as the r-pi logo comes up.

The weirdest part is if I use the 240 memsplit that boots fine, then replace it with any of the other memsplits and reboot, they work too. But only until I unplug the Pi. And after the Pi won't boot, it's start.elf is the same number of bytes that it should be.

All I have plugged in are a logitech wireless mouse and a logitech wired keyboard.

portets, you may have the FAT16 boot partition corrupted.
If you make a filesystem check on this partition, on Windows or Linux, you may end up with one or more missing files, which were totally corrupted.
Replacing these files will not solve the problem, while you don't correct the filesystem errors.
This has happened to me.

I'll have to check that out. But shouldn't the older start.elf files also not work when immediately replacing the current one? They're the same size, so I assumed the file would occupy the same exact spot as the previous file if copied after deleting it.