Overclocking

[dom]

I've now observed corruption of a Transcend Class 2 SD card running OpenELEC r11978 with the following overclock settings:

Code: Select all

arm_freq=750
core_freq=255
sdram_freq=400
over_voltage=3


Can you remove over_voltage and try. It shouldn't be needed for that very minor overclock, and would be interesting if it proves significant.

Can you remove over_voltage and try. It shouldn't be needed for that very minor overclock, and would be interesting if it proves significant.

I've removed it, and I'm struggling to locate any corruption! Put it back, and next reboot, the partition is corrupt...

So it does appear to be significant (although please note I've only tested this for about 10-15 minutes).

For the past few hours I've been testing with current_limit_override enabled now that I've shorted the polyfuses on my Pi, and I've achieved stability in Raspbian at 1000/500/500/+6/+4 (+4 for over_voltage_sdram), this includes now being able to play Quake3 which previously forced a reboot. SD card corruption does not seem to occur with Raspbian (Transcend Class 10). OpenELEC is also stable with these same settings, but only when mounting root from USB memory stick - pretty much any overclock corrupts the SD card (Transcend Class 2 or Class 10) in OpenELEC. The only reason I mention this is to show that my Pi and PSU seem to be up to snuff when it comes to obtaining a decent overclock.

Could the difference in firmware be a factor (OpenELEC r11978 is using firmware from 16 Sep, while Raspbian dates from 20 Sep)?

[dom]

I've removed it, and I'm struggling to locate any corruption! Put it back, and next reboot, the partition is corrupt...

So it does appear to be significant (although please note I've only tested this for about 10-15 minutes).

For the past few hours I've been testing with current_limit_override enabled now that I've shorted the polyfuses on my Pi, and I've achieved stability in Raspbian at 1000/500/500/+6/+4 (+4 for over_voltage_sdram), this includes now being able to play Quake3 which previously forced a reboot. SD card corruption does not seem to occur with Raspbian (Transcend Class 10). OpenELEC is also stable with these same settings, but only when mounting root from USB memory stick - pretty much any overclock corrupts the SD card (Transcend Class 2 or Class 10) in OpenELEC. The only reason I mention this is to show that my Pi and PSU seem to be up to snuff when it comes to obtaining a decent overclock.

Could the difference in firmware be a factor (OpenELEC r11978 is using firmware from 16 Sep, while Raspbian dates from 20 Sep)?

Nothing that seems relevent changed between start.elf from 16 Sep, and 20 Sep. You should be able to replace OpenELEC start.elf with latest one:
https://github.com/raspberrypi/firmware ... /start.elf

Can you try paying quake in your raspbian image, whole copying files in the background (to sdcard). Possibly quake doesn't write to sdcard much, compared to XBMC.

Nothing that seems relevent changed between start.elf from 16 Sep, and 20 Sep. You should be able to replace OpenELEC start.elf with latest one:
https://github.com/raspberrypi/firmware ... /start.elf

I did try using the start.elf from Raspbian but it ended up as a bit of a mess - I'll try the one from github.

Can you try paying quake in your raspbian image, whole copying files in the background (to sdcard). Possibly quake doesn't write to sdcard much, compared to XBMC.

OK, just did that with the following settings:

Code: Select all

arm_freq=1000
core_freq=500
sdram_freq=500
over_voltage=6
over_voltage_sdram=4

current_limit_override=0x5A000020


I played a game of Quake, and simultaneously copied 1GB of data (two directories, 10 files each, 0.5GB in each directory, a total of 20 files) over NFS to the SD card (Transcend Class 10).

There were no errors during the copy, and Quake played fine (if slowly!)

Once the copy had finished I exited from Quake, fsck'd the /dev/mmcblk0p2 partition (without making any changes - it was clean anyway), rebooted, and Raspbian came up fine with no errors - all the data is there, no corruption.

I've just finished running an md5sum on the transferred data, and all of the hashes are correct.

I did try using the start.elf from Raspbian but it ended up as a bit of a mess - I'll try the one from github.

OK, I downloaded start.elf from github, and it's returned mixed results.

I slapped it on a fresh OpenELEC r11978 image (Transcend Class 10, root on /dev/mmcblk0p2), and with the following overclock settings I didn't see any hint of corruption:

Code: Select all

arm_freq=1000
core_freq=500
sdram_freq=500
over_voltage=6
over_voltage_sdram=4

current_limit_override=0x5A000020

I rebooted 3 times and cached about a dozen thumbnails each time - all good, no problems.

I then tried the following "low" settings:

Code: Select all

arm_freq=750
core_freq=255
sdram_freq=400
over_voltage=3


and cached another dozen or so thumbnails, and there were no mmc errors in log/messages - it was all looking so good. Then, just as I was about to reboot, I saw the following in log/messages:

Code: Select all

Sep 23 12:59:48 openelec user.info kernel: [   79.359253] bcm2835-cpufreq: Freq 700000->750000 (min=700000 max=750000 target=750000 request=750000)
Sep 23 12:59:51 openelec user.info kernel: [   80.088838] bcm2835-cpufreq: Freq 750000->700000 (min=700000 max=750000 target=700000 request=700000)
Sep 23 13:03:33 openelec user.info kernel: [   83.039619] bcm2835-cpufreq: Freq 700000->750000 (min=700000 max=750000 target=750000 request=750000)
Sep 23 13:03:33 openelec user.notice kernel: [  305.128016] EXT4-fs (mmcblk0p2): error count: 6
Sep 23 13:03:33 openelec user.notice kernel: [  305.128050] EXT4-fs (mmcblk0p2): initial error at 6: htree_dirblock_to_tree:587: inode 26: block 8730
Sep 23 13:03:33 openelec user.notice kernel: [  305.128076] EXT4-fs (mmcblk0p2): last error at 7: ext4_mb_generate_buddy:739


Rebooting resulted in a system that would not start (failure to mount /storage etc.).

On the basis of this limited testing, I'd say this github start.elf is an improvement on the version provided with OpenELEC r11978. However, it is very limited testing and I need to sit down and watch the footie...

Here is the version information for the start.elf I used for this test:

Code: Select all

root ~ # vcgencmd version
Sep 20 2012 22:38:16
Copyright (c) 2012 Broadcom
version 338528 (release)


I'll do more testing in OpenELEC r11978 at high and low overclocks later on today to confirm what I've seen so far....

[dom]

I think we've got more than one reason for corruption going on here.

One plausible reason I can think of, is the BogoMips value reported is done early in boot, before the cpufreq driver is loaded, and so measures the stock (700MHz) frequency.
Now this is value is used elsewhere in linux when calibrating delays. E.g. the sdcard driver might call udelay(1) and expect to get a delay of at least one microsecond.
However if the ARM is now at 1GHz, it will only get a 0.7 microseconds, which could cause a problem.

To help investigate this, I've add a config.txt parameter, initial_turbo, which means turbo will be enabled from boot for this many seconds (up to 60), or until cpufreq driver sets a frequency.

This has the effect of setting the BogoMips value to the turbo frequency (1000MHz), and that has the side effect of making all delays at least as long as they should be.

So, if you have suffered sdcard corruption, please reimage. Run rpi-update. Set
initial_turbo=30
and enable overclock with raspi-config. Let me know if it behaves any better.

Sticking my head in, bored with the Liverpool/United match... is there a version I can download for OpenELEC? ie. just the start.elf? Or do I need a kernel too?

Thanks dom.
initial_turbo=30 seems to work for me.

So far I copied about 3 GB of data with 100% ARM usage. I'm using turbo mode with 1100MHz arm_freq.
No issues so far.

[dom]

Sticking my head in, bored with the Liverpool/United match... is there a version I can download for OpenELEC? ie. just the start.elf? Or do I need a kernel too?

Just replacing start.elf should be fine. The kernel hasn't changed.

To help investigate this, I've add a config.txt parameter, initial_turbo, which means turbo will be enabled from boot for this many seconds (up to 60), or until cpufreq driver sets a frequency.

This has the effect of setting the BogoMips value to the turbo frequency (1000MHz), and that has the side effect of making all delays at least as long as they should be.

Rather than use a delay until the cpufreq driver may or may not set an upper frequency, why not simply use the arm_freq defined by config.txt (defaulting to 700 if not specified) as the "bogomips" figure - would this be easier?

Sticking my head in, bored with the Liverpool/United match... is there a version I can download for OpenELEC? ie. just the start.elf? Or do I need a kernel too?

Just replacing start.elf should be fine. The kernel hasn't changed.

Same link as before? I'll give it a go...

[dom]

same link as before? I'll give it a go...

Yes, it's a different version, but that link points to top of tree so should get the latest.

Not good news I'm afraid.

I booted OE r11978 with a "low" overclock (750/255). BogoMips is determined correctly as ~750 in /proc/cpuinfo. Three mmc-related errors appeared in log/messages. I rebooted, and the ext4 partition had been hosed.

@dom: I'm not sure if I should be testing with or without over_voltage=+3 any more... it's a valid setting so I don't see why not...

Will test some more later unless there's any more breakthroughs.

Code: Select all

Sep 23 15:00:53 openelec user.notice Boot: ### Starting Samba server ###
Sep 23 15:00:56 openelec daemon.err smbd[1136]: [2012/09/23 15:00:56.607395,  0] passdb/pdb_smbpasswd.c:248(startsmbfilepwent)
Sep 23 15:00:56 openelec daemon.err smbd[1136]:   startsmbfilepwent_internal: file /var/run/smbpasswd did not exist. File successfully created.
Sep 23 15:00:59 openelec user.notice Boot: ### set cpu's to 'ondemand' ###
Sep 23 15:00:59 openelec user.info kernel: [   22.429930] bcm2835-cpufreq: switching to governor ondemand
Sep 23 15:01:17 openelec user.info kernel: [   22.429999] bcm2835-cpufreq: switching to governor ondemand
Sep 23 15:01:17 openelec user.err kernel: [   40.106077] mmc0: final write to SD card still running
Sep 23 15:01:27 openelec user.info kernel: [   46.044521] bcm2835-cpufreq: Freq 750000->700000 (min=700000 max=750000 target=700000 request=700000)
Sep 23 15:01:27 openelec user.err kernel: [   50.123669] mmc0: Timeout waiting for hardware interrupt - cmd12.
Sep 23 15:01:27 openelec user.err kernel: [   50.124984] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
Sep 23 15:01:27 openelec user.notice Boot: ### SSH: generating SSH2 RSA key ###
Sep 23 15:01:40 openelec user.notice Boot: ### SSH: generating SSH2 DSA key ###
Sep 23 15:01:55 openelec user.notice Boot: ### Starting SSH Server ###
Sep 23 15:02:09 openelec user.info kernel: [   50.514628] bcm2835-cpufreq: Freq 700000->750000 (min=700000 max=750000 target=750000 request=750000)
Sep 23 15:02:09 openelec user.info kernel: [   91.914654] bcm2835-cpufreq: Freq 750000->700000 (min=700000 max=750000 target=700000 request=700000)
Sep 23 15:02:11 openelec user.info kernel: [   92.274753] bcm2835-cpufreq: Freq 700000->750000 (min=700000 max=750000 target=750000 request=750000)
Sep 23 15:02:11 openelec user.info kernel: [   94.104670] bcm2835-cpufreq: Freq 750000->700000 (min=700000 max=750000 target=700000 request=700000)


Code: Select all

arm_freq=750
core_freq=255
sdram_freq=400
over_voltage=3
#over_voltage_sdram=4

initial_turbo=30

#current_limit_override=0x5A000020


Code: Select all

Processor       : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS        : 749.56
Features        : swp half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xb76
CPU revision    : 7


Code: Select all

root ~ # vcgencmd version
Sep 23 2012 14:54:04
Copyright (c) 2012 Broadcom
version 338882 (release)


I have a strange problem when using raspi-config that it doesnt did what i want. i'll configured ram split to 240/16 and overclocking to Turbo but when i reboot its still on ram split 192/64 without overclocking...

when i then check /boot/config.txt its ******up (last line is cuttet or very many " @ " appended) and no overclocking settings

Linux raspberrypi 3.2.27+ #160 PREEMPT Mon Sep 17 23:18:42 BST 2012 armv6l GNU/Linux

when i edit /boot/config.txt and only add the overclock lines its again gone after reboot. only when i completely clear config.txt and add the lines it works


i also some other questions:
- what means "initial_turbo=30" ?
- and is there a way to get the current voltage of cpu/gpu?

I did try using the start.elf from Raspbian but it ended up as a bit of a mess - I'll try the one from github.

OK, I downloaded start.elf from github, and it's returned mixed results.

I slapped it on a fresh OpenELEC r11978 image (Transcend Class 10, root on /dev/mmcblk0p2), and with the following overclock settings I didn't see any hint of corruption:

Code: Select all

arm_freq=1000
core_freq=500
sdram_freq=500
over_voltage=6
over_voltage_sdram=4

current_limit_override=0x5A000020

I rebooted 3 times and cached about a dozen thumbnails each time - all good, no problems.

I then tried the following "low" settings:

Code: Select all

arm_freq=750
core_freq=255
sdram_freq=400
over_voltage=3


and cached another dozen or so thumbnails, and there were no mmc errors in log/messages - it was all looking so good. Then, just as I was about to reboot, I saw the following in log/messages:

Code: Select all

Sep 23 12:59:48 openelec user.info kernel: [   79.359253] bcm2835-cpufreq: Freq 700000->750000 (min=700000 max=750000 target=750000 request=750000)
Sep 23 12:59:51 openelec user.info kernel: [   80.088838] bcm2835-cpufreq: Freq 750000->700000 (min=700000 max=750000 target=700000 request=700000)
Sep 23 13:03:33 openelec user.info kernel: [   83.039619] bcm2835-cpufreq: Freq 700000->750000 (min=700000 max=750000 target=750000 request=750000)
Sep 23 13:03:33 openelec user.notice kernel: [  305.128016] EXT4-fs (mmcblk0p2): error count: 6
Sep 23 13:03:33 openelec user.notice kernel: [  305.128050] EXT4-fs (mmcblk0p2): initial error at 6: htree_dirblock_to_tree:587: inode 26: block 8730
Sep 23 13:03:33 openelec user.notice kernel: [  305.128076] EXT4-fs (mmcblk0p2): last error at 7: ext4_mb_generate_buddy:739


Rebooting resulted in a system that would not start (failure to mount /storage etc.).

On the basis of this limited testing, I'd say this github start.elf is an improvement on the version provided with OpenELEC r11978. However, it is very limited testing and I need to sit down and watch the footie...

Here is the version information for the start.elf I used for this test:

Code: Select all

root ~ # vcgencmd version
Sep 20 2012 22:38:16
Copyright (c) 2012 Broadcom
version 338528 (release)


I'll do more testing in OpenELEC r11978 at high and low overclocks later on today to confirm what I've seen so far....

Try a different sd card. Even thought the Transcend class 10 is listed as compatible on the wiki. It suffered sd card corruption pre-09/21/12 issues.

when i then check /boot/config.txt its ******up (last line is cuttet or very many " @ " appended) and no overclocking settings

I've been seeing the same kind of issue (corrupted config.txt) and failure to rpi-update (broken filesystem in /boot) on what is an otherwise completely stable overclock (quake3 and background cpu tasks no trouble for hours).

Using arm1000, core500, dram450, ovolt5, current override.

I also have trascend class10 card so wonder if it is that... I'm going to experiment with the core to see if it is stable writng to the card. If i clock back to 700 then it absolutely fine doing updates and boot config etc.

Cheers,

Kev

[dom]

I've been seeing the same kind of issue (corrupted config.txt) and failure to rpi-update (broken filesystem in /boot) on what is an otherwise completely stable overclock (quake3 and background cpu tasks no trouble for hours).

Using arm1000, core500, dram450, ovolt5, current override.

I also have trascend class10 card so wonder if it is that... I'm going to experiment with the core to see if it is stable writng to the card. If i clock back to 700 then it absolutely fine doing updates and boot config etc.

Can you try this:
viewtopic.php?f=29&t=6201&start=425#p180099

I've been seeing the same kind of issue (corrupted config.txt) and failure to rpi-update (broken filesystem in /boot) on what is an otherwise completely stable overclock (quake3 and background cpu tasks no trouble for hours).

Using arm1000, core500, dram450, ovolt5, current override.

I also have trascend class10 card so wonder if it is that...

im currently using a class4 platinum 4gb
when i'll clear config.txt and only add the 5 overclock lines

Code: Select all

force_turbo=0
arm_freq=1000
core_freq=500
sdram_freq=500
over_voltage=6

it works so no broken filesystem

Try a different sd card. Even thought the Transcend class 10 is listed as compatible on the wiki. It suffered sd card corruption pre-09/21/12 issues.

I'll also be testing with a Class 2 which exhibits similar problems to the Class 10, but for now one card at a time is about all I can cope with...

As for any prior issues, I can't say I've experienced anything negative. Prior to the introduction of the dynamic overclock feature, these Class 10 cards have been as good as gold, at least in my experience anyway, with OpenELEC (which I test frequently, whenever there is a new testbuild) and also (but less often) Rasbpmc.

@dom:

(Testing with a Transcend 8GB Class 10 SD Card)

1) Booting this latest "delayed turbo" start.elf using OE r11978 and with settings at 750/255/+3 is a bit hit & miss, with a fresh image the R-Pi never makes it to the GUI (the Pi can be ping'ed etc., but no sshd and just a blank display) so the device has to be power cycled, then typically the GUI comes up at the second attempt. Since this power cycle can leave the ext4 partition in a corrupt state, I first clean boot with 750/250/+3 settings as this configuration seems to boot first time every time, for some strange reason.

2) At 720/250/+3, with XBMC idle at the menu, I used an ssh session to transfer 0.5GB of data (1 directory, 10 files) over NFS to the SD card. Once complete, e2fsck checked out clean. OpenELEC rebooted without a problem on 3 occasions.

3) At 750/255/+3, I again commenced the transfer of the same 0.5GB data to the SD card, and this resulted in catastrophic corruption of the ext4 partition, see log (pastebin). I have indicated in the log the approximate point at which the data transfer begins - it's only a simple cp of the directory over NFS. Rebooting this device was obviously futile. This test case is easily repeatable (for me, anyway).

4) At 1000/500/500/+6/+4, the freshly imaged SD card booted first time without a hitch (as per 750/250, but not 750/255), and the 0.5GB transfer over NFS commenced, ending after only 68MB had transferred when the Pi stopped responding to the network, keyboard/mouse and IR receiver but XBMC was still active on the display (click updating, RSS feed scrolling etc.). I'm guessing from the message in the log below, that the USB bus shut down completely (I've included the output of lsusb -v in case it's helpful). Strange that I had no problem transferring double this amount of data while playing a game of Quake in Raspbian!

A power cycle was required, and the system came up clean. I reverted to testing SD card writes by caching thumbnails, I must have cached over 20 thumbnails (coverart + fanart) without any errors appearing in the log, and the device was able to reboot on three consecutive occasions without any SD card corruption.

Code: Select all

root ~ # tail -f log/messages
Sep 23 19:37:17 openelec user.info kernel: [   21.734552] bcm2835-cpufreq: switching to governor ondemand
Sep 23 19:37:23 openelec user.notice Boot: ### SSH: generating SSH2 RSA key ###
Sep 23 19:37:26 openelec user.notice Boot: ### SSH: generating SSH2 DSA key ###
Sep 23 19:37:33 openelec user.info kernel: [   21.734570] bcm2835-cpufreq: switching to governor ondemand
Sep 23 19:37:33 openelec user.notice Boot: ### Starting SSH Server ###
Sep 23 19:37:34 openelec user.info kernel: [   37.294176] bcm2835-cpufreq: Freq 1000000->700000 (min=700000 max=1000000 target=700000 request=700000)
Sep 23 19:37:35 openelec user.info kernel: [   38.014331] bcm2835-cpufreq: Freq 700000->1000000 (min=700000 max=1000000 target=1000000 request=1000000)
Sep 23 19:37:37 openelec user.info kernel: [   39.854193] bcm2835-cpufreq: Freq 1000000->700000 (min=700000 max=1000000 target=700000 request=700000)
Sep 23 19:37:37 openelec user.info kernel: [   41.014345] bcm2835-cpufreq: Freq 700000->1000000 (min=700000 max=1000000 target=1000000 request=1000000)
Sep 23 19:37:40 openelec user.info kernel: [   41.394196] bcm2835-cpufreq: Freq 1000000->700000 (min=700000 max=1000000 target=700000 request=700000)
Sep 23 19:39:13 openelec user.info kernel: [   44.874301] bcm2835-cpufreq: Freq 700000->1000000 (min=700000 max=1000000 target=1000000 request=1000000)
Sep 23 19:39:13 openelec user.warn kernel: [  137.257972] usb 1-1.2: input irq status -5 received


Code: Select all

root ~ # lsusb -v
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         1 Single TT
  bMaxPacketSize0        64
  idVendor           0x1d6b Linux Foundation
  idProduct          0x0002 2.0 root hub
  bcdDevice            3.02
  iManufacturer           3 Linux 3.2.29 dwc_otg_hcd
  iProduct                2 DWC OTG Controller
  iSerial                 1 bcm2708_usb
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           25
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 Full speed (or root) hub
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0004  1x 4 bytes
        bInterval              12
Hub Descriptor:
  bLength               9
  bDescriptorType      41
  nNbrPorts             1
  wHubCharacteristic 0x0008
    Ganged power switching
    Per-port overcurrent protection
    TT think time 8 FS bits
  bPwrOn2PwrGood        1 * 2 milli seconds
  bHubContrCurrent      0 milli Ampere
  DeviceRemovable    0x00
  PortPwrCtrlMask    0xff
 Hub Port Status:
   Port 1: 0000.0503 highspeed power enable connect
Device Status:     0x0001
  Self Powered

Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         2 TT per port
  bMaxPacketSize0        64
  idVendor           0x0424 Standard Microsystems Corp.
  idProduct          0x9512
  bcdDevice            2.00
  iManufacturer           0
  iProduct                0
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           41
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                2mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      1 Single TT
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0001  1x 1 bytes
        bInterval              12
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       1
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      2 TT per port
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0001  1x 1 bytes
        bInterval              12
Hub Descriptor:
  bLength               9
  bDescriptorType      41
  nNbrPorts             3
  wHubCharacteristic 0x000d
    Per-port power switching
    Compound device
    Per-port overcurrent protection
    TT think time 8 FS bits
  bPwrOn2PwrGood       50 * 2 milli seconds
  bHubContrCurrent      1 milli Ampere
  DeviceRemovable    0x02
  PortPwrCtrlMask    0xff
 Hub Port Status:
   Port 1: 0000.0503 highspeed power enable connect
   Port 2: 0000.0303 lowspeed power enable connect
   Port 3: 0000.0303 lowspeed power enable connect
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         0 Full speed (or root) hub
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0001
  Self Powered

Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass         0
  bDeviceProtocol         1
  bMaxPacketSize0        64
  idVendor           0x0424 Standard Microsystems Corp.
  idProduct          0xec00
  bcdDevice            2.00
  iManufacturer           0
  iProduct                0
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           39
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                2mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol    255
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0010  1x 16 bytes
        bInterval               4
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass         0
  bDeviceProtocol         1
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0001
  Self Powered

Bus 001 Device 004: ID 0518:0001 EzKEY Corp. USB to PS2 Adaptor v1.09
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x0518 EzKEY Corp.
  idProduct          0x0001 USB to PS2 Adaptor v1.09
  bcdDevice            0.01
  iManufacturer           1 Composite USB PS2 Converter
  iProduct                2 USB to PS2 Adaptor  v1.12
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           59
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          2 USB to PS2 Adaptor  v1.12
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      1 Boot Interface Subclass
      bInterfaceProtocol      1 Keyboard
      iInterface              0
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.10
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      64
         Report Descriptors:
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval              10
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      1 Boot Interface Subclass
      bInterfaceProtocol      2 Mouse
      iInterface              0
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.10
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength     102
         Report Descriptors:
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval              10
Device Status:     0x0000
  (Bus Powered)

Bus 001 Device 005: ID 05a4:9881 Ortek Technology, Inc.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x05a4 Ortek Technology, Inc.
  idProduct          0x9881
  bcdDevice            1.20
  iManufacturer           0
  iProduct                0
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           59
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      1 Boot Interface Subclass
      bInterfaceProtocol      1 Keyboard
      iInterface              0
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.10
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      63
         Report Descriptors:
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval              10
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 No Subclass
      bInterfaceProtocol      0 None
      iInterface              0
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.10
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength     208
         Report Descriptors:
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0005  1x 5 bytes
        bInterval              10
Device Status:     0x0000
  (Bus Powered)


Getting these quite often now when playing back media on the OpenELEC system with latest start.elf at 1000/500/500/+6/+4:

Code: Select all

Sep 23 21:39:39 openelec user.warn kernel: [  101.595294] usb 1-1.3: input irq status -5 received
Sep 23 21:40:21 openelec user.warn kernel: [  142.877388] usb 1-1.2: input irq status -5 received


The system appears to hang (playback freezes), but it probably is available, just that no USB I/O (network, keyboard/mouse, IR) is possible.

I don't recall seeing this USB issue prior to this new start.elf - I haven't seen it in Raspbian (with the default - as supplied - 2012-09-18 start.elf), nor in OpenELEC when using the default r11978 start.elf and mounting root from a USB memory stick to avoid SD corruption at these same high overclock settings).

Getting these quite often now when playing back media on the OpenELEC system with latest start.elf at 1000/500/500/+6/+4:

Code: Select all

Sep 23 21:39:39 openelec user.warn kernel: [  101.595294] usb 1-1.3: input irq status -5 received
Sep 23 21:40:21 openelec user.warn kernel: [  142.877388] usb 1-1.2: input irq status -5 received


The system appears to hang (playback freezes), but it probably is available, just that no USB I/O (network, keyboard/mouse, IR) is possible.

I don't recall seeing this USB issue prior to this new start.elf - I haven't seen it in Raspbian (with the default - as supplied - 2012-09-18 start.elf), nor in OpenELEC when using the default r11978 start.elf and mounting root from a USB memory stick to avoid SD corruption at these same high overclock settings).

@Dom: I've gone back to Raspbian 2012-09-18 (vcgencmd version version 337601, Sep 18 2012 01:45:27) to repeat the data transfer tests I performed previously at 1000/500/500/+6/+4 with Quake running concurrently, and I've discovered that Raspbian can be made to "hang" - but only when Quake is NOT running. It's not consistent, but I've managed to cause it to happen three times now. OpenELEC, however, is much easier to hang in this way - that's guaranteed with the latest start.elf, I'll test that start.elf with Raspbian as well to see if it makes any difference.

With the original start.elf, Raspbian will consistently complete the data transfer without fail when Quake is being run AT THE SAME TIME (which was the purpose of the original test) - testing with dd to /dev/null, the Pi will achieve about 11.5MB/s over NFS (not bad for a 10/100 connection!):

Code: Select all

pi@raspberrypi ~ $ dd if=/freenas/data/pi.test/largefile.dat of=/dev/null bs=1M
457+1 records in
457+1 records out
479493658 bytes (479 MB) copied, 41.536 s, 11.5 MB/s

pi@raspberrypi ~ $ dd if=/freenas/data/pi.test/largefile.dat of=/dev/null bs=1M
457+1 records in
457+1 records out
479493658 bytes (479 MB) copied, 41.3872 s, 11.6 MB/s

pi@raspberrypi ~ $ vcgencmd version
Sep 18 2012 01:45:27
Copyright (c) 2012 Broadcom
version 337601 (release)


However, Raspbian can be made to "hang" (stop responding to USB I/O) when performing the same data transfer in isolation, that is, *without* Quake running simultaneously. Not always, but some times.

It's not even necessary to write to the SD card when performing this test so the SD card can be eliminated as a variable - simply dd'ing a large file across the network to /dev/null is sufficient to hang Raspbian (struggling to see precisely why though, as there's nothing being written to the logs - I'm guessing it's a problem with the USB bus).

Presumably while Quake is also running, the additional load from Quake prevents some other part of the system from being swamped/overloaded by the USB activity. With Quake running, the IRQ load during the "dd to /dev/null" transfer is about 7,500-8,000 IRQ/s, but when Quake is not running the IRQ load for the same transfer can peak at about 11,200 IRQ/s. With only Quake running (and no data transfer) the IRQ load is about 900 IRQ/second.

I'd guess this is a separate issue from the SD Card corruption - is anyone else able to confirm this USB behaviour when overclocked?

Hmmm... this isn't so easy to reproduce, not even with OpenELEC which has now decided to remain stable during my most recent tests.... what a PITA.

Forgive me - I'm not 100% up to speed with how all the bits (slices?) of the Pi hang together...

Is the SD card connected through the USB bus in a similar manner to the networking?

I'm wondering if it's possible that the problems being seen aren't necessarily coming from the overclocks and if they might be symptoms of USB issues? I'm sure I read that some USB fixes had gone in at the same time as the turbo mode stuff.

Perhaps those 2 changes are masking each other, possibly the overclocking exacerbating another issue.

I'm not in a position to do so at the moment but,is anybody able to, and think it worthwhile, to do some testing with the USB fixes disabled?

Please ignor eme if I'm talking nonsense, I just wanted to throw the idea out there.

[dom]

Is the SD card connected through the USB bus in a similar manner to the networking?

No.

I've been seeing the same kind of issue (corrupted config.txt) and failure to rpi-update (broken filesystem in /boot) on what is an otherwise completely stable overclock (quake3 and background cpu tasks no trouble for hours).

Using arm1000, core500, dram450, ovolt5, current override.

I also have trascend class10 card so wonder if it is that... I'm going to experiment with the core to see if it is stable writng to the card. If i clock back to 700 then it absolutely fine doing updates and boot config etc.

Can you try this:
viewtopic.php?f=29&t=6201&start=425#p180099

I'm using forceturbo so I assume that won't matter? I also have a Kingston class 4 card with an identical image that I'm about to see if i can reproduce the issue on - i'm testing up to arm1100 ovolt8 with that also.

Is there anything that can be one to "tame" the class 10 cards if it does prove to be the problem...?