text:
RPi Xorg rpi Driver
This is the documentation for the Xorg Raspberry Pi driver developed in this thread [1]
By default, each Raspberry Pi Linux distro uses the generic framebuffer driver to draw the X display. All rendering of the display is done by the CPU into off- or on-screen buffers which eventually are shown on the output by the scan-out hardware. As the CPU on the Raspberry Pi is reasonably weak this makes for a sluggish user interface that at the same time causes a high CPU load, that slows down other programs.
In the modern 2D X11 desktop environment however there are two major ways that an application can choose to render itself,
- all rendering done by the X server
- nearly all rendering done by the application, with the X server simply presenting the rendered output
The primary goals of this project are to improve the performance of the first case and leave the second to other projects - there are many different user libraries that can do application-side rendering and boosting the performance of each of those would be a huge undertaking. The driver accomplishes this by offloading common tasks onto other hardware on the SoC that can process the work asynchronously, allowing the X server to be pre-empted by the OS yet still allowing progress to be made. This should allow other processes to see more CPU time.
Unfortunately this means that even if the X server runs infinitely faster, applications can still seem unresponsive if extensive application-side rendering is used. This is a common problem in optimisation. [2]
No effort has been made so far to allow applications access to OpenGL/GL ES through the X server eg via GLX - basic 2D has been the priority so far.
- 1 Design
- 2 Memory layout
- 3 Installation of the driver
- 4 Configuration of the driver
- 5 Troubleshooting
- 5.1 Failed to initialise kernel interface (does /dev/dmaer_4k exist?)
- 5.2 Incompatible dmaer version
- 5.3 My display is entirely corrupt yet it appears 'functional'
- 5.4 Memory size not specified! (use BlockSize)
- 5.5 Failed to open VCIO mailbox via device file <whatever>
- 5.6 No VpuElf section in configuration file
- 5.7 No memory mode specified
- 5.8 Memory base not specified! (use BlockBase)
- 5.9 Memory size of <whatever> bytes is too small to be useable
- 5.10 Failed to open /dev/mem
- 5.11 VC requires memory size to be multiple of page size
- 5.12 Failed to allocate memory from VC
- 5.13 Failed to open binary file <whatever>
- 5.14 Misc VPU binary loading problems
- 5.15 System hangs whilst testing VPU code
- 5.16 There is some display corruption
- 5.17 SIGSEGV or SIGTRAP
- 5.18 The display does not appear to be accelerated
- 5.19 Black square in the top left of the display
- 5.20 rendercheck sometimes fails
- 5.21 Window contents or decorations corrupts during window dragging
- 5.22 How to change VPU binary
- 5.23 The Ethernet driver oopses/runs out of memory/stops working
- 5.24 Display quickly turns off/loses signal
- 6 Disabling / uninstalling
- 7 Download links
Xorg provides a mechanism for drivers to accelerate a number of important rendering tasks. This is called EXA [3]. EXA allows easy overriding of,
- block copy aka blitting
- solid colour fills
- compositing, aka alpha blending
This driver implements the required functionality of EXA by using different parts of the Raspberry Pi SoC.
- 2D A->B block copies are performed using asynchronous DMA. A DMA engine is programmed to copy - in either a linear or 2D fashion - from A(x, y) to B(x2, y2) with an incrementing source address and incrementing destination address.
- Solid colour fills are also performed by asynchronous DMA. A DMA engine is programmed to copy (again either linear or 2D) from a non-moving source address to a moving destination address starting at B(x, y). The source address holds the colour that is to be used in the fill.
DMA commands are enqueued one after the other to ensure correct results. They are constructed as a chain of DMA control blocks (CBs), and passed to the DMA controller to be kicked in one go.
For cases where the DMA set-up time would take longer than a naive CPU copy or fill, a CPU fallback is used instead.
Composition is more complex as the inputs vary much more. The operation allows many different operating modes, eg with different filtering, transformations, pixel formats, blend equations, wrapping modes - but some operations are much more common than others. These are handled in three different ways:
- synchronous acceleration by the VPU's vector unit [4]. This covers the fewest cases but ideally the ones in which the most pixels need to be processed, where a speed-up will be most appreciated. Hand coded in assembly.
- synchronous low-latency CPU implementation using 32-bit ARM SIMD, catching all common cases. This should perform a "good enough" job, as it is primarily designed for low-pixel-count operations, eg rendering small antialiased characters.
- fallback to the generic X implementation: this covers all other composition modes. This is the worst case, as the overhead reaching the first actual image processing instruction is high.
SoC hardware used
As mentioned above, the driver leverages three things that the generic driver wouldn't otherwise use.
This is not as comprehensive [5] as the NEON instruction set found in some v7 ARM implementations but is still useful for the task of composition. Through C++ template metaprogramming, a careful consideration of what a compiler can and cannot optimise, and finally eyeballing the code generated we can have composition functions that are of a comparable speed to those hand-optimised functions in pixman. The templating helps here by generating hundreds of these functions, rather than the handful that are specially implemented in pixman.
DMA engines
The Raspberry Pi SoC includes a decent number of DMA engines which can be used by the ARM for moving data around memory. They can all access the full bandwidth of the memory - more than the ARM could itself. They all share the bandwidth, and one DMA is sufficient to saturate the bus. The DMA engines are not all the same however - some have greater performance or features than the others. For instance, half of them have the ability to perform '2D' DMAs rather than straight linear transfers. Also one of the DMA engines (DMA zero) has a deeper FIFO allowing it to do larger read bursts.
The DMA hardware does not live within the same address space as the ARM CPU. It uses the bus address space instead. A translation must be made to the address to get from one to the other. Also, the ARM's page tables are not used by this hardware. Virtually contiguous ARM addresses are not necessarily physically contiguous and the DMA hardware won't know about this - as a result DMA needs to be sometimes broken up into 4 KB blocks to ensure the correct result.
There is a start-up cost associated with DMA, and as a result sometimes it is not efficient to use this hardware. Steps include,
- breaking a large transfer up into something which respects 4 KB page boundaries
- entering the kernel
- translating user virtual addresses into bus addresses for each DMA CB
- flushing and invalidating parts of the data cache, then kicking off the DMA chain
- returning to user mode to do more work
- entering the kernel
- waiting for the DMA to complete
- returning to user mode
For reference, a user->kernel->user transition takes roughly 1 us. Each DMA CB appears to take the DMA engine around 6 us to start.
Also on the SoC is the a custom processor that appears to be the controlling brains of the GPU, the VPU. This is what the 'firmware' runs on. Rpi_Software#Overview
Within this processor is a 16-way vector unit which is well-suited to image processing operations. Although this processor is ordinarily clocked nearly three times slower than the ARM core, the vector unit and improved memory interface more than make up for it. Some composition functions that commonly operate on thousands of pixels have been coded to run on this unit.
Like the DMA hardware, it lives within the bus address memory space. User virtual ARM addresses need translation, and the 4 KB page boundary/page table issues still apply. Also from the viewpoint of the driver the VPU appears as an asynchronous co-processor: there is a ~56 us overhead at stock clock speeds communicating with it from X so work should really only be sent to it if worthwhile.
Blocking waits
The workload sent to the driver from the running applications is not known in advance. The structure of the work is generally the same though. Allocate some images, upload some data from the user application, perform a handful of operations, synchronisation point. Perform some more operations, synchronisation point.
The point of the frequent synchronisation points is to allow the application to get a hold of the rendered pixel data. It is also there to allow the application to release memory. By knowing that all rendering has completed by a given point, it knows what is sees in the buffer is correct and also that a given image buffer is no longer in use and can be freed.
This behaviour is contrary to a game-style render loop: for the majority of a frame a command buffer is filled with drawing commands. At the end of a frame this command buffer is sent to the GPU for processing. However whilst this was going on, the GPU was processing the last frame's command buffer. This contrasts the X update loop as,
- there are many more synchronisation points, and it is unknown when they will appear
- there is not a double-buffered command buffer, meaning the GPU cannot be processing "last frame's image" whilst the CPU is building this frame's command buffer
- image data cannot go too far away from the CPU as the application may want to inspect it with the minimum of delay
This means OpenGL and other run-times are not appropriate for an X driver on a system like the Raspberry Pi that lacks horsepower. If GL or a similar run-time was used, the high CPU cost of setting up and tearing down images and command lists etc would drawf the actual amount of time the GPU would be doing rendering. Also the fact that on the Raspberry Pi textures are not trivially accessible by the CPU means that when an application needs to gain access to pixel data a high cost must be paid stopping the GPU and then downloading the textures. Even the 6 us start-up time of a DMA CB is noticeable in some applications - if instead the whole 3D stack is traversed many applications would be far slower than the generic CPU route.
That said applications which expect the driver to be implemented on a run-time like OpenGL will tailor their workload to properly suit it. For example, the Chromium browser. This is an exception though - most applications expect a synchronous driver with easily-reachable memory
When to synchronise
As mention before, the driver treats the VPU and DMA hardware as asynchronous co-processors. The CPU overhead of reaching them is relatively high and as CPU time is not in abundance this overhead needs to be amortised over as many operations as possible. This means the CPU builds up a list of work to send to the DMA hardware and a list of work to send to the VPU hardware. Eventually these lists are sent off for processing. The overhead cost is only paid once.
Yet as it is not known when a synchronisation point may appear it is not clear when a DMA or VPU command list must be started. By waiting longer the overhead is decreased (per unit of work) yet there is a greater chance that the application requests the work is finished, but it won't be as it has yet to start. The application then blocks. The opposite is also true - if work is kicked too frequently, too much overhead results yet the application will wait less as there is a greater chance the work has completed by the time it requests a sync point.
Performing composition with the VPU is tricky too - as there is a 56 us start-up cost to performing work there, are there sufficient pixels to process that it is worth this cost? An estimate needs to be made of the relative speeds of the two processors (ARM and VPU) and based on this a decision is made whether the task is run on the co-processor or not. Something to also consider is that on the ARM CPU the run-time is variable. There are early-out optimisations that can be performed based on the value of the mask (if present). These optimisations can't be used on the VPU.
Finally there is also the case where work to be processed with DMA is so small that it would be quicker to process on the CPU. Yet if a million tiny pieces of work come along back-to-back it would still have been faster to do with DMA - but it is not known how many pieces of work will be enqueued. This means there is a decision to be made: when should the CPU perform work that it thinks it could do faster than the DMA hardware?
High-level driver layout
Yellow represents "the driver", code that has been written as part of this project.
Memory layout
In order to suit different situations, there are three main ways of using the driver. Each has advantages and disadvantages. Due to the way EXA is currently being used, it needs to track a large chunk of "offscreen memory". This is memory that the application can't see, yet the graphics accelerator (in whatever form the driver writer is targetting) can see. The problem comes in the Raspberry Pi's case is that all the hardware targetted can see all the memory, and so this abstraction is unnecessary and wasteful. This limitation incurs a decent performance penalty, but work will be done in the future to address this issue.
Initial work has been done to work around the above issue by use of the SelfManagedOffscreen option.
Here are the three ways of providing EXA and the driver with its offscreen memory.
4 KB page mode
In order for DMA to function, the the memory being operated on must not move to a different physical address by the Linux page compaction system nor be paged out to swap. This will happen to normal user pages, so they are not suitable. One way to get around this is to allocate pages from the kernel and map them in to the user space. These pages are unmoveable, they will never be swapped and their physical addresses can be cached for a more efficient translation.
The advantages for this scheme include:
- no wasted memory - if X does not use the whole of the offscreen space, then only the pages that are used are allocated. No pre-declaration or reservation of memory is necessary.
- it is the most robust and secure system, as all address translations are vetted by the kernel, and the hardware that is provided the addresses is simple and predictable.
- the maximum memory can be scaled up and down at run-time, without a reboot
The disadvantages are based around the fact that memory is not physically contiguous:
- DMA must be broken at the 4 KB page boundary into separate DMA transfers (still as part of the CB chain though)
- VPU composition cannot be used
- 2D DMA cannot be used due to the complexity of breaking at page boundaries
- more CPU address translation is necessary due to the increase in CBs
Finally, as the pages are unmoveable they cannot be swapped out - this will increase the pressure on the remaining 'normal' memory.
- the address translation is generally more complex, increasing the ARM CPU load
With all three memory options, all on-screen pixmaps that are not under the control of EXA are allocated with the 4 KB mode in order to allow DMA to pull them into offscreen memory.
Boot-time reservation mode
This mode involves telling the kernel to simply ignore - at boot-time - a chunk of the memory provided to the CPU. It is never used by applications or the kernel as the system simply believes it has less memory attached. This reserved memory can be mapped in as the offscreen buffer to good effect. It is physically continuous, and this means address translation is very simple. Just one constant needs to be added to the user virtual address to get to the final bus address needed by DMA and the VPU. If the mapping is done smartly, no offset is needed at all.
Advantages include:
- DMA does not need to be broken into 4 KB chunks
- VPU composition can be used
- 2D DMA can function
- address translation is very simple
Disadvantages include:
- memory is wasted if it is not used, either by X not needing it all or the user simply not running X in the first place
- a reboot is needed to change the reservation size
- the user needs to compute the address of the reservation before passing it to X
- there is generally a greater chance of something "going wrong" due to user or programmer error (there's no problem inherent to the technique, though)
VideoCore mailbox reservation mode
This involves asking the firmware for a block of memory from its share, and then mapping it in to the user process. This can function either in the static split mode, where the user declares how much is needed for the GPU in their config.txt (eg 192/64) or via the new "floating split" CMA mode. The size of the split grows and shrinks based on what's happening at that time.
Advantages include:
- DMA does not need to be broken into 4 KB chunks
- VPU composition can be used
- 2D DMA can function
- address translation is very simple
- easy user set-up
- no wasted memory if X is not used
- memory usage can be changed without a reboot
Disadvantages include:
- if not in the CMA mode, this may prevent 3D applications from starting as there may be insufficient GPU memory
Installation of the driver
Installation of the pre-prepared binary driver is easy, assuming a few prerequisites.
- Raspbian
- as up-to-date as possible
- xserver-xorg-core and xserver-xorg-video-fbdev need to already be installed: ie you need to be able to load a desktop without any trouble, with no modifications made to the installed code
- memcpy and memset replacement installed and enabled, available here [6]. This is part of the stock Raspbian install.
Pre-install set-up
- Install Hexxeh's rpi-update, if not previously installed
- sudo wget http://goo.gl/1BOfJ -O /usr/bin/rpi-update && sudo chmod +x /usr/bin/rpi-update
- Update to the bleeding edge (as of the time of writing) kernel and firmware
- sudo rpi-update
- Change the display to 32-bit mode
- Add these lines to your /boot/config.txt file
- framebuffer_depth=32
- framebuffer_ignore_alpha=1
- Add these lines to your /boot/config.txt file
- If you want to use the VideoCore mode and the CMA memory allocation also add,
- Remove any exising cma_* or gpu_mem* options
- then insert,
- gpu_mem_256=112
- gpu_mem_512=368
- cma_lwm=16
- cma_hwm=32
- cma_offline_start=16
- If you want to use the VideoCore mode but not CMA then you need to manage the memory split yourself
- Remove any cma_* options
- Try gpu_mem=32, 48 or 64
- Once you reboot, run sudo vcdbg reloc | grep "largest free block"
- Multiply this size by 1048576 and use as the BlockSize option. See that entry in the configuration section to know what sort of size to aim for.
- Reboot, and ensure your device comes back up with the new firmware and kernel
- uname -a should give at least 3.6.11
- vcgencmd version should give at least 359004
- Check that the display is in fact in 32-bit mode
- fbset, and look at the end of the 'geometry' line: it should say 32
- Ensure you can load the desktop like normal
- do this however you would do, and confirm that everything works (eg your USB input devices) and also that there are no oddities due to being in 32-bit colour mode
- eg, run startlxde from another terminal
- Quit the desktop and return to the console again
Driver install
Download <xorg-server.tar.gz> and <xserver-xorg-video-fbdev.tar.gz>. See here for the files.
- Install the X server
- sudo tar xfvz xorg-server.tar.gz -C /
- Install the driver, default config file and VPU binary
- sudo tar xfvz xserver-xorg-video-fbdev.tar.gz -C /
Kernel module install and set-up
Two kernel modules need to be configured, the DMA controller and the VC mailbox.
- Load the DMA module
- sudo modprobe dmaer_master
- major=$(awk '$2=="dmaer" {print $1}' /proc/devices)
- sudo mknod /dev/dmaer_4k c $major 0
- Make the mailbox character device (for now in the home dir as that's what the default config file expects)
- sudo mknod /home/pi/char_dev c 100 0
Running it
Make sure you have backed up by this point. Run 'sync' just because you can. From a console that you will always be able to see in the event of a trouble an alt-F1 VT is not good enough, SSH is recommended,
- sudo gdb Xorg
- set args -verbose -keeptty
- handle SIGPIPE nostop
- handle SIGUSR1 nostop
- run
If you see a hang at "Checking that it works..." then this means VPU composite has failed. You must now ctrl-z, sync and sudo reboot. You will not be able to ctrl-c. When the device reboots, try running again (you will need to modprobe the module and make /dev/dmaer_4k again). If it hangs again double-check you do have the latest kernel and firmware, and that /usr/share/X11/vpu_offload_asm.bin is intact. Its md5sum is 3978152d8db9a69c0cd33d248cbbba89.
You should now see your display monitor sitting at an all-black screen. You now need to run an X windows application in order to see something on it! I would recommend, from another SSH terminal:
...and you will then see the default desktop. Try dragging some windows around, scrolling, selecting all the icons on the desktop in a huge selection box etc. Web browsing can still be slow, but much of this is due to the web browser rendering the page. Look for web pages which use static backgrounds that do not scroll (eg Twitter). These pages should refresh much faster now when scrolling the text (but frequently you are still bound by the browser's internal rendering performance).
Note that many X desktop scripts try to run another copy of the X server, eg startxfce4. This will fail as only one copy can run at a time. If however before calling those scripts you export DISPLAY=:0 then they will use the original X server you created. This is likely the behaviour your want.
It is recommended that during initial set-up of the driver than any overclocking is disabled. The driver stresses hardware that is not normally used whilst sitting at the desktop.
However once it is confirmed that everything runs fine, feel free to try and overclock the system again - testing all the time.
What to overclock:
- the CPU of course, simply to accelerate the applications and fallback blits and composites
- GPU core: this affects the L2 cache, DMA controller and VPU
- memory subsystem, one of the main limiters of performance
As the 3D hardware is not used don't waste your time overclocking this.
Configuration of the driver
There are a number of different 'Options' that can be passed to the driver at load-time. These can be added to the default configuration file I supply.
The configuration file can be found at /usr/share/X11/xorg.conf.d/01-fbdev-rpi.conf
|Option name
|Suitable inputs
|EXA, EXA_NULL, NoAccel
|This is really only useful for people who choose to find their EXA offscreen memory RPi_Xorg_rpi_Driver#Memory_layout via the 4 KB method. As memory is allocated lazily (ie when it is first used) you will have a slowly increasing memory load. This can cause trouble for the Ethernet/USB driver, plus cause occasional slow-downs.
By choosing yes here all pages allocated via the 4 KB method will be allocated and locked up-front. Only use if you're seeing trouble in dmesg related to memory allocations.
|an address, in decimal or hexadecimal.
|If you choose to use the boot-time reservation you will need to use this option to configure where your memory hole is. You can derive this address yourself, or sort of look it up in /proc/iomem. Let's say you reserve 123 MB for the driver and you choose to use the a 240/16 MB CPU/GPU split in config.txt. The address will be (240 - 123) * 1048576.
You will be able to see this by looking in /proc/iomem at the first entry: "System RAM". It will say 00000000-<some number in hex>. <some number> will be (240 - 123) * 1048576 - 1. Easy.
To make the actual reservation you must add to your kernel command line mem=sizeMB, where size is the amount that the kernel will manage. eg in the example above size would be 256-16-123 ie mem=117MB
|a number of bytes, in decimal or hexadecimal
|This is the maximum number of bytes you would like to use as the driver's offscreen memory. You should realistically use over 8 MB - I would say this would be a minimum for 1280x1024x32. 16 MB would be a realistic minimum for 1080p.
Nothing should fail if you get it too small (although it will stop and caution you at load-time if you choose a number silly small), there will simply be more swapping back and forth ie worse performance. For users who use the boot-time reservation this number should really be the size of the hole that you reserve. It can be smaller (pointless) but no bigger.
Note that if SelfManagedOffscreen is used then things may go funny if it runs out of memory. So these recommendations apply for SelfManagedOffscreen=false. If SelfManagedOffscreen=true then maybe try 24-32 MB.
|4k, mem, vc
|true, false
|This toggles whether large composition operations will be offloaded to the VPU, assuming the blending function and pixel formats match. This is a highly-experimental feature and can lock up your Raspberry Pi and/or corrupt your SD card.
This makes use of information derived through reverse engineering and should not be used in countries where this is prohibited.
|a filename
|This should point to a special character device file, with major 100 minor 0. Only needs to be set if VPU offloading is used.
|a filename
|This should point to a special binary which is to be run on the VPU and provides the VPU offload functionality. Not necessary if VPU offload is disabled.
|true, false
|Turns on the stats the show what the EXA system is handing to the driver, broken down by each function, the number of pixels being pushed by each part, and which part of the SoC is doing what work.
|true, false
|This allows the driver to manage the offscreen memory itself, rather than letting EXA manage that memory as a cache. This has the advantage that the download step is no longer necessary (but upload still currently is), and performance improves as a result. The disadvantage is the scheme is very new, and it is not clear how it behaves in the long run. If this option is used, it is recommended that sufficient memory is allocated with BlockSize such that the driver does not run out of memory.
Here is a list of common problems and hopefully their solutions. This section will likely be expanded as problems arise.
Failed to initialise kernel interface (does /dev/dmaer_4k exist?)
This problem occurs when either the /dev/dmaer_4k file cannot be successfully be opened. This can either happen because,
- the file does not exist
- the file exists, but the major/minor dev numbers do not match that of the kernel module
- the file exists, but the kernel module is not loaded
- the file exists, the kernel module is loaded, but the permissions on the file do not allow it to be opened
Double-check that you have modprobe'd the kernel module, and that you have created the special device file with the correct major/minor numbers. Note that these numbers can change depending on the order that modules are loaded into the kernel. Finally check that you are running Xorg as root.
Incompatible dmaer version
The dmaer module interface is controlled via a version number. When breaking changes are made to either the driver or the kernel module, the version number is incremented. If this happens you must upgrade both your kernel module and the driver.
This error message indicates that the kernel module has become too old for the driver, and you must upgrade the kernel module or downgrade the driver.
My display is entirely corrupt yet it appears 'functional'
If you choose to use the 'null' driver then this will happen; it is intentional. Double-check that you are not using EXA_NULL as AccelMethod in your Xorg config file.
Memory size not specified! (use BlockSize)
You need to tell the driver how much memory you would like to use as "video memory". Memory is physically unified in the Raspberry Pi so this concept does not really apply, but you must tell the driver nonetheless. See RPi_Xorg_rpi_Driver#Memory_layout and RPi_Xorg_rpi_Driver#Configuration_of_the_driver for details.
Failed to open VCIO mailbox via device file <whatever>
This means that the mailbox file specified with the MboxFile option is invalid in some way, or the option has simply not been specified. Check that the MboxFile option exists in the config file and that it points to something correct. Potential failures here:
- MboxFile option not specified
- option points to a device file that does not have the correct permissions accessible to the current user
- option points to a device file where the major/minor numbers are not correct for the mailbox driver
- the mailbox driver is missing from the current running kernel
Double-check RPi_Xorg_rpi_Driver#Kernel_module_install_and_set-up
No VpuElf section in configuration file
You have chosen to use VPU offload, but you have not specified where the VPU binary is. Ensure that you have the VpuElf option set, and that it points to a valid VPU binary.
No memory mode specified
You need to tell the driver how to configure the "video memory" that is used by the driver. See the above question as it is very similar.
Memory base not specified! (use BlockBase)
You have chosen to use the 'mem' memory mode option, but you have not told the driver where it is mapped in the address space. See RPi_Xorg_rpi_Driver#Configuration_of_the_driver for an example of its usage.
Memory size of <whatever> bytes is too small to be useable
You must specify the BlockSize option in bytes, not megabytes or kilobytes. The driver does a basic test to see if the value is below 1048576 and will immediately fail if so.
Failed to open /dev/mem
If using the 'vc' or 'mem' memory modes the driver then /dev/mem is used to map memory in to Xorg's address space. You must ensure that /dev/mem exists, and has the correct permissions to allow opening by the current user - which should ideally be root.
VC requires memory size to be multiple of page size
The size you choose for BlockSize must be a multiple of 4096. Ensure the number you pass in with this option has no remainder.
Failed to allocate memory from VC
This means that the VideoCore has rejected the size of the memory allocation. Check dmesg just for confirmation. You will see that the address returned is zero. Try reducing your BlockSize option to match what sudo vcdbg reloc | grep "largest free block" returns, in bytes.
Failed to open binary file <whatever>
This means that the file chosen with the VpuElf option could not be opened for reading. Check that that path to the file is correct, and that it has read permissions for the current user.
Misc VPU binary loading problems
- failed to read file marker
- binary does not appear to be loadable
- failed to read version number
- incorrect format version number, <whatever>
- header is at invalid offset, <whatever>
- header points beyond the end of the file, <whatever>
- Could not identify itself correctly
- Could not find GetVersion function
- Version of VPU binary is too new for this driver, <whatever>
- failed to upload VPU code
- File failed to load from <whatever> or is zero bytes in length
These all indicate a complete failure to load the VPU binary. Check that the file pointed to by the VpuElf option is not corrupt, and is exactly what comes from the driver release. VPU binaries are versioned and must correspond to a given driver release. Any corruptions to the file can hang the VPU or trash the memory or SD card.
System hangs whilst testing VPU code
Immediately ctrl-z (not ctrl-c) Xorg, sync and reboot your system. It will likely fail to shut down properly but as soon as the ARM kernel has shut down (you'll see a message on the screen) pull the power. On rebooting, try again. If it happens again confirm that the VPU binary is intact and has not been tampered with, and that you have an up-to-date start.elf/GPU firmware that has execute capability.
There is some display corruption
For example, colours are not what they are expected to be, icons look corrupt, speckled pixels etc. This should be reported to me as a bug via [7]. However you need to ensure you have a reproducible example - otherwise it can't be fixed. Restart X and try to figure out the minimum number of steps needed to get the artefacts you can see.
Also try disabling VpuOffload and see if you have the same effect. You must disable any overclocking. Finally, before submitting the bug you need to confirm that the stock driver would not have done it anyway. Uninstall the driver and run your test again to confirm if it does or does not happen.
SIGSEGV or SIGTRAP
This will mean one of three things,
- the driver has crashed outright
- the driver has caught an invalid DMA command
- the driver has malfunctioned somehow and caught it
all these are bad and need to be reported via [8]. It may be user error but if so a more user-friendly message should be displayed.
In order to submit this as a bug you need to have a reproducible example, the output log from Xorg (if appropriate) and the core file. The repro needs to work without any overclocking too. After the crash, from gdb run generate-core-file and ensure this file is submitted with the repro.
The display does not appear to be accelerated
The ARM CPU is a huge bottleneck and even at its best the driver is not substantially faster than the stock driver. You may need to reel in your expectations! Don't forget that previously you would likely have been using the 16-bit colour mode, which is lighter on the memory subsystem. However in the case of genuine lack-of-acceleration, check:
- the display is running in 32-bit colour mode. The driver is designed for this mode and any other mode will invoke much of the original driver's code as its fallback mechanism. There is no composition support for 16-bit colour on either the CPU or VPU, but DMA copies and blits will work correctly. CPU fallback for small copies/blits does not exist for 16-bit colour mode and will continue to use DMA.
- you may be running programs which do all of their work with client-side rendering. This driver cannot assist there, and so ends up being a glorified framebuffer. There are many such programs which do all their work like this. Run top and see where your CPU time is being spent - is it all in the application?
- has enough memory been passed to the driver. If not enough memory is provided (consider the display resolution too) then there will be insufficient memory for the code to manoeuvre and the fallback path will be chosen. If using the SelfManagedOffscreen option check to see that the driver is not running out of memory.
- the whole system may have run out of memory, and swap memory is being used. You can identify this with top or free.
- some applications will try to use OpenGL to do display composition, rather than XRender. There is no hardware support for OpenGL, and this means that (at best) software rendering will be used. Check to see if the application or window manager is trying to use GL. Remember, there is currently no support for OpenGL ES via GLX either.
Finally do consider that the current version needs to be tuned (hence the testing, to learn common usage patterns) and that it is full of validation code to ensure that if things go awry they get caught before any damage is done. This validation code does slow things down.
If you are purely using canned benchmarks to test for any performance increase then ignore them - use subjective tests instead. Most benchmarks do not appear to consider the EXA architecture (eg x11perf). They do not understand the on/offscreen memory divisions and spend excessive time performing unnecessary upload/download operations. Also command-recording systems (eg gtkperf) that then replay the command as fast as possible do not consider the RPi_Xorg_rpi_Driver#Blocking_waits issue and send their synchronisation points far too soon after the actual draw commands are issued. The sync point kick code is designed around testing with real-time user interaction sync points, not sync points that appear instantly after the draw call.
Black square in the top left of the display
This is the VT's cursor showing through onto the framebuffer. This sounds exactly like what is seen [9]. Note that even with the stock fbdev driver, when used in 32-bit colour mode, exhibits the same behaviour. No effort has been made to address this.
rendercheck sometimes fails
It appears that the render targets that use the 'window' can sometimes fail. This is because the window render options use the X root window, which lives in the framebuffer memory. The VT cursor/black square issue in the previous point interferes with this (by writing black), causing those tests to fail.
Window contents or decorations corrupts during window dragging
This can happen if the original libc memcpy function is being used, not the replacement available at [10]. Ensure that this library is installed (it's enabled by default in Raspbian) and is enabled.
How to change VPU binary
At the time of writing the VPU instruction cache appears to be sticky. If you have previously run the driver, with VPU offload enabled, in the current session you should reboot if you need to change the VPU binary. For instance, if you are sent an updated version of the VPU binary, copy it into the correct place (or change your VpuElf option), reboot and then run X. If you do not reboot there is a strong change that the driver will hang.
The Ethernet driver oopses/runs out of memory/stops working
The dmaer kernel module allocates a fair amount of memory in the form of individual pages - but nothing too excessive. GFP_KERNEL is used, and is allowed to fail. However it appears that the Ethernet driver voluntarily gives up its memory when allocations are requested...and then complains about it.
This problem happens more often when BlockSize is large, the 4k memory mode is used and FaultInImm is not used. Try,
- not using Ethernet
- smsc95xx.turbo_mode=N in /boot/cmdline.txt
- vm.min_free_kbytes = 12288 in /etc/sysctl.conf (or even higher?)
- not using the 4k mode
- reducing the BlockSize memory size
- enabling the FaultInImm option - this will cause the all the memory to be allocated immediately, rather than gradually. If the Ethernet driver doesn't fail right then, you are in the clear.
Display quickly turns off/loses signal
If you start X and very quickly after loading a graphical application (one which uses the XRender extension) the display turns off or loses signal and you find your Raspberry Pi has hung - congratulations! Your AXI bus has locked up. You will need to power cycle your Pi to turn it back on.
In order to report this, please give the dmesg kernel log around the time the DMA module is loaded, as well as the Xorg log. You should be fine re-running Xorg and loading the kernel module as long as you do not run any kind of X windows application. This is what triggers the lock-up.
Finally, make sure you're not mistaking this for the screensaver coming on ;)
Disabling / uninstalling
You can disable the driver by changing the NoAccel option from EXA to NoAccel. This disables VPU and DMA work, but still leaves the X server itself with performance-altering modifications in it - toggling NoAccel will do nothing here.
To wholly remove this code, run
sudo apt-get install --reinstall xserver-xorg-video-fbdev xserver-xorg-core
This will just reinstall over the top of any modified files.
Download links
WIP source can be found here This link also includes the license and readmes. They are not included within the binary packages as they are intended to be extracted to / (root). No-one wants a readme living in /!
Initial release. Includes lots of verification and debugging code. LINK


text:
The role of financial advisor is an admirable and important profession. In addition, health is perhaps the most important issue to an individual, and hence, doctors hold a special place in the hearts of their patients. Finally, pastors, priests, and other religious leaders address a crucial aspect of one's life. In the opinion of this author, these three vocations address the most critical aspects of humanity which are: the financial or material, the physical, and the spiritual. If a person has great wealth, but poor health, they may not be able to enjoy their possessions. Moreover, if someone is healthy, but poor, happiness may prove elusive. If a person is relatively healthy and financially prosperous, but spiritually miserable, life may be a constant struggle trying to understand the reason for things that happen and the larger question of why we are here.
Leaving the philosophical behind, in this article we'll focus on the financial part of the equation through the practice of financial planning, and more specifically, two components not often found in financial planning output.
Financial planning was ranked as the number one profession a few years back and for good reason. The profession, or vocation if you will, offers great income potential and places the practitioner in a position of trust due to the breadth and depth of information shared by the client. For practitioners who engage in this area, planning is an excellent way to distinguish themselves from others in their field.
In general, a financial plan is an excellent way to condense all components of a client's financial life into a clear and concise document. Hence, clients should derive great comfort from its contents as they fully understand where they stand relative to their goals. Normally, all plans will project retirement, analyze taxes to an extent, determine the amount of insurance a client may need, and more. In the past decade, simulation techniques have crept into planning software along with "What if?" scenario analysis. However, there are a few items of great benefit to a financial planning client but are generally absent from a financial plan. The first is a funeral directive and the second is a document locator.
Document 1: The funeral directive is not a legal document per se, but rather a statement of the deceased's wishes pertaining to issues such as the preferred funeral home, songs to be sung at the service and the pastor, priest, rabbi or other religious leader whom the client wishes to officiate at a funeral or memorial service.
Document 2: The document locator is an inventory of every account, real estate holding, safe deposit box and so forth. It should contain a description of the item, its location, the person to contact and their contact information. It should also be updated annually, especially if the client is approaching the upper limits of his or her life expectancy. Obviously, if the client is in poor health, keeping it updated carries greater importance.
These are just a few of the ancillary items of a comprehensive financial plan. It's rather obvious that creating these documents does not directly benefit the advisor or lead to a sale. However, since we're supposed to put the interests of the client ahead of our own, this shouldn't be a consideration. This also raises the point that advisors should charge a fee for this and that planning is a top-shelf service we can offer.
Thanks for reading and have a great week!

subset: commoncrawl


text:
"We're counting down days until Christmas is here,
And gifting you cool security tips to be of good cheer,
And make sure this season is the best of your year."
Join us every day for a new Norton tip to keep your holidays merry and bright. A secure holiday is a happy holiday with Norton.
If you are experiencing an issue that needs urgent assistance please visit our customer support area:
There are currently 9 users online.


text:
A bride in Connecticut threw her wedding together in just 24 hours so her terminally ill mother could attend.
Initially, Aly Femia had planned to marry her childhood sweetheart in September 2015.
But after learning her mother's lung cancer had spread to her brain, Aly and Anthony decided to move things up -- a lot.
She walked down the aisle of the hospital corridor, her stepdad on her arm, on Jan. 29.
"My favorite part of the day was having my mom see me in my wedding dress, wearing a string of her pearls, and seeing her smile," Femia told Buzzfeed. "I couldn't have asked for a more perfect day."
Staff members at Yale-New Haven Hospital helped make the big day possible, donating food, flowers and even a cake.
Femia's father died of cancer 16 years earlier.


text:
The Alternative To Peasmarsh TA19 Call Girls.
Find Women In Your Postcode Looking For Sex. Join Free and Browse 1000s of Profiles. Sex does not have to be complicated.
Get Laid Tonight
The Alternative To Escorts. Women Looking For Sex In Your Local Area Peasmarsh TA19
Riley O'Day Irish Lass is here in Peasmarsh TA19
Hi my name is Ada im from France. I am 25 years old. I offer GFE and PSE. I also do erotic massages and im a party (...) Peasmarsh TA19
Call Girls Peasmarsh TA19
Top Call Girls in Peasmarsh TA19
Over the years, many call girls have flocked to North Carolina for the scenic beauty and wonderful, sunny weather. Because of its natural beauty, the area has become the top destination for this type of beauties. And it is not just a few people who are drawn to this beautiful place. In fact, the number of people attracted to the beauties of North Carolina is constantly increasing.
There are many well-known sites for women looking for some action and wild fun. Some of the best escorts come from the areas surrounding the state and these places are definitely where you should look for the sexiest call girls. Here are the top destinations in North Carolina:
Dollywood: Dollywood is a theme park that offers a lot for visitors and you can also hire their services in making sure you get the most out of your trip. As a matter of fact, there are many reasons why this is a popular destination.
This attraction offers a wide range of activities for everyone to enjoy including, Disney rides, amusement rides, indoor rides, and games. You can even rent a fishing boat and make the most of the delicious homemade food. What more, the whole family can have fun and enjoyment in this area.
The park itself has breathtaking views of beautiful and captivating water bodies like the Great Smoky Mountain, Roan Mountain, Pisgah National Forest, and Pisgah Ranger District. Of course, there are also beautiful beaches, sandy places, and a couple of restaurants for you to enjoy.
A large number of call girls usually travel to Dollywood each year and you can find many local, popular, and famous beauties like Gina Gershon, Ashley Davis, and Penny Pax working at this attraction. On top of that, there are even some call girls who have earned enough reputation to earn their own successful careers as strippers.
Call Girls Peasmarsh TA19 Sluts
Huntersville: The best thing about this location is the fact that it is located near Myrtle Beach and Sea Isle City, which is an area famous for its beaches and accommodations. The area is also known for its hiking trails, the beach, and fishing spots.
If you want to enjoy some of the best sights of the state and see some of the most beautiful nature you will ever see, then the best thing that you can do is head to Huntersville. However, the problem with the state is that it is notoriously tough to find the quality girls.
However, this area is well known for its beautiful women who have gone on to become outstanding beauties and fortune tellers. You can now find gorgeous ladies all around the world working in this location.
Hilton Head: Hilton Head Island is also a very famous location for women and it is often called the sister city of Myrtle Beach. What's more, it has several hot spots that are popular among many professional beauties.
It is not unusual to find famous entertainers, models, and beauties living on the island as well. If you are planning to have fun and have a great time with your friends, then it is advisable that you go and check out the different spots of Hilton Head.
Calling girls are available all over the state. You just need to know where to look for them.


text:
Baby Bandit Picks Locks, Steals Sister's Toys
We would say this impressive, but it seems more appropriate to say this kid is the uber-little brother. Breaking into his sister's room? Check. Stealing her stuff? Check. Doing it in a manner that makes it hard to prove it was him? Check.
Unfortunately, times have changed, and now there are baby cams to catch thieving little toddlers who can pick locks. The glory the sister must be experiencing at getting justice must be amazing.


text:
C++ Reading List, May 28, 2013 The new C++11 standard has led to a flood of new books and updates to classics. These are the core books you need.
C++ Programming Language, 4th Edition
by Bjarne Stroustrup
This book is rightfully viewed as the "Bible" of C++ programming. It's the authoritative exposition of the language, its features, and its peculiarities, all written with considerable clarity by Stroustrup, who designed C++. Some readers might view the ANSI C++ document as a more definitive source of information, but it is a rather terse reference resource intended for readers who already know the language. This book, in contrast, gives friendly explanations of new features, coupled with advice on things to do and practices to avoid, making it a more approachable choice for readers needing to understand specific features. In this sense, this book is more a reference than a tutorial.
Some physical aspects detract from the book, especially the choice of printing code without using a monospaced font. No matter how aesthetically pleasant this might look to some readers, it throws off regular readers of code, who expect vertical alignments that no longer appear. Despite this, the typesetting of the code is much better than in previous editions. A second concern is one that has to do more with C++ itself than the book. This edition is 1328 pages long. That is roughly 1000 pages more than the original edition. As Stroustrup gives scant coverage of the libraries, these numbers are indicative of how much more complex C++ has become. These concerns notwithstanding, I don't see how serious C++ programmers looking to use the new features of the language can proceed without this work. Definitely recommended.


text:
Carrie Kahn
Carrie Kahn is NPR's international correspondent based in Mexico City, Mexico. She covers Mexico, the Caribbean and Central America. Kahn's reports can be heard on NPR's award-winning news programs including All Things Considered, Morning Edition and Weekend Edition.
Prior to her post in Mexico Kahn had been a National Correspondent based in Los Angeles since joining NPR in 2003. During that time Kahn often reported on and from Mexico, most recently covering the country's presidential election in 2012. She was the first NPR reporter into Haiti after the devastating earthquake in early 2010, and has returned to the country six times in the two years since to detail recovery and relief efforts, and the political climate.
Her work included assignments throughout California and the West. In 2010 Kahn was awarded the Headliner Award for Best in Show and Best Investigative Story for her work covering U.S. informants involved in the Mexican Drug War. In 2005, Kahn was part of NPR's extensive coverage of Hurricane Katrina, where she investigated claims of euthanasia in New Orleans hospitals, recovery efforts along the Gulf Coast and resettlement of city residents in Houston, TX. She has covered her share of hurricanes since, fire storms and mudslides in Southern California and the controversial life and death of pop-icon Michael Jackson. In 2008, as China hosted the world's athletes, Kahn recorded a remembrance of her Jewish grandfather and his decision to compete in Hitler's 1936 Olympics.
Before coming to NPR in 2003, Kahn worked for 2 1/2 years at NPR station KQED in San Francisco, first as an editor and then as a general assignment reporter with a focus on immigration reporting. From 1994 to 2001, Kahn was the border and community affairs reporter at NPR station KPBS in San Diego, where she covered Northern Mexico, immigration, cross-border issues and the city's ethnic communities.
While at KPBS, Kahn received numerous awards, including back-to-back Sol Price Awards for Responsible Journalism from the Society of Professional Journalists. She won the California/Nevada Associated Press award for Best News Feature, eight Golden Mike Awards from the Radio & TV News Association of Southern California and numerous prizes from the San Diego Press Club and the Society of Professional Journalists of San Diego. She was also awarded three consecutive La Pluma Awards from the California Chicano News Media Association.
Prior to joining KPBS, Kahn worked for NPR station KUSP and published a bilingual community newspaper in Santa Cruz, CA.
Kahn is frequently called upon to lecture or discuss border issues and bi-national journalism. Her work has been cited for fairness and balance by the Poynter Institute of Media Studies. She was awarded and completed a Pew Fellowship in International Journalism at Johns Hopkins University.
Kahn received a Bachelors degree from UC Santa Cruz in Biology. For several years she was a human genetics researcher in California and in Costa Rica. She has traveled extensively throughout Mexico, Central America, Europe and the Middle East, where she worked on a English/Hebrew/Arabic magazine.


text:
Spinner "Interface" Podcast Launches This Week
Legendary folk/punk figure Billy Bragg is set to tour the US in the lead-up to this years election, making a dozen or so stops along the Eastern Seaboard beginning in mid-October.
This week, Spinner launched a new Interface podcast, featuring an in-studio performance from Billy, singing songs from his latest release Mr. Love and Justice, and well as an in-depth interview with the revered populist in which he talks about trying to overthrow Margaret Thatcher's government, the music he's most proud of and how Prince Charles is "a f-king jerk." See it here.
Mr. Love and Justice, Billy's 12th studio album and his first in six years, has been widely hailed by fans and critics alike:
- "A return to form, a step forward, and a potent reminder of why Bragg's music still matters." -All Music Guide - "Whether you prefer him shouting vitriol on the picket line or whispering sweet nothings in the bedroom, you'll find plenty to enjoy here." -Billboard - "Frequently fantastic folk-rock that keeps both the faith and your attention." -Village Voice
Billy Bragg on Tour: 10-17 The State Theatre State College PA 10-18 State Theatre Ithaca NY 10-19 Monmouth University West Long Branch NJ 10-21 Somerville Theater Somerville MA 10-22 Somerville Theater Somerville MA 10-23 Lebanon Opera House Lebanon NH 10-24 Keswick Theatre Glenside PA 10-27 9:30 Club Washington DC 10-28 Rams Head Live Baltimore MD 10-29 Paramount Theatre Charlottesville VA 10-30 Attucks Theater Norfolk VA 11-01 Duke University Durham NC 11-02 The Orange Peel Asheville NC


text:
Blue Jays - 000 000 210 - 3 14 0The Red Sox battered Cecil with a four-dong fifth, with home runs from Jason Varitek (his second of the night), David Ortiz, Jason Bay and Mike Lowell.
Red Sox - 002 060 00x - 8 15 0
The big man slammed a 1-1 fastball into the camera well in dead center field. (He also doubled off The Wall in the eighth.) It increased the Red Sox's lead from 3-1 to 5-1 and sent Fenway into a frenzy. After Kevin Youkilis (3-for-5) singled to left, Bay hit a bomb over everything in left and Dr. Doubles followed him with a shot into the Monster Seats.
Penny (6.2-9-2-1-2, 96) pitched well, but wilted in the seventh. ... Jacoby Ellsbury set a new Red Sox record (and tied the major league mark) for most putouts by an outfielder with 12 catches. By inning: 222 212 001.
Brett Cecil (1.80, 254 ERA+) / Brad Penny (6.69, 74 ERA+)
Cecil is a rookie lefty who turns 23 in July. He has made three starts for the Jays -- facing Cleveland, the Athletics and the White Sox this month -- pitching at least six innings every time out. Totals: 20 innings, 17 hits, 4 walks, 15 strikeouts.
BP 2009 describes Cecil, a 2007 supplemental-round pick, as a "big lefty with low-90s velocity, a plus slider, and a decent changeup ... projects as a mid-rotation horse".
Penny has also gone at least six innings in each of his last three starts, though he has had less success (18.2-21-5-14) than Cecil.
Terry Francona talked a lot about David Ortiz on WEEI today. Extra Bases has lengthy quotes. One quote, in response to whether Ortiz could be finished as a hitter, Tito said:
No, I don't feel that way. You can go back and go a long way, because I've done some research, and look at Yaz. He had some injuries, and he went, what, 56 games one year. It was a pretty good dry spell, and he had what, 10 years in the major leagues and everyone thought he was done. I mean, everyone thought Pedroia was done before he got started. ...Research? Does Tito have a B-Ref subscription?
Yaz did not hit a home run in his first 57 games in 1972. That drought lasted until July 22! Yet what Tito may not know is that, when combined with a homer-less streak to end the previous season, Yaz actually went 72 games without a home run -- from September 4, 1971 to July 21, 1972.
That link shows all of his HR-less streaks, including a 43-gamer in 1976: July 10 to August 22 (my first game at Fenway!).


text:
Published November 22, 2013 at 3264 × 1836 in ST GEORGE UNDER SIEGE 3: 'UNITS, UNITS, EVERYWHERE!' | Leave a comment
Truly a once in a lifetime opportunity, Bexley's most Iconic Residence… This Federation Masterpiece is full of Period features, including High Ornate Ceilings, Wide Hallways, 4 Original Fire Places, Tiled Foyer Entry, Lead Light Windows and Main Entry, Slate Roof, Pressed Metal Ceiling and much, much more… Not my words, the real estate agent's… And […]Continue Reading
What constitutes a gateway building? What does it even mean, this wildly encompassing propagandist term 'gateway building'? Is it a building with a gateway attached or a gateway within a building? I believe it is a recent turn of phrase, coined by councils, developer lobby groups and probably the Liberal government, in order to raise […]Continue Reading
There was a time when industrial buildings were seen as ugly, void of beauty, unsightly, uncharming. In many circles that may still be the current held point of view. I myself have stumbled over enough examples to contradict this, many of which are disappearing from our cities' urban landscapes, as entire swathes of post-industrial precincts […]Continue Reading


text:
Tracy Morgan's estranged mother was turned away at the hospital when she went to visit her son, who was critically injured in a car accident last weekend, according to TMZ.
Alicia Warden — who is known for not having a close relationship with Morgan — reportedly told TMZ no one called her about her son's accident. She said she heard about it on TV.
She told the website she went to visit Morgan on Saturday, but wasn't allowed in by hospital security and Tracy's fiancee, Megan Wollover. Warden believes Tracy's fiancee has a thing against her.
Warden said she returned the next day and was admitted, but the former "Saturday Night Live" star was unconscious and she was only allowed to stay for five minutes. She said his friends and a pastor were in the room.
Warden added,"All I wanted was for our family to be alone with him. I wanted to pray over him and couldn't do that because so many people were in the room."
Morgan — who said in a 2012 interview he hadn't seen his mother in 11 years — was injured on a New Jersey freeway while coming home from a show, when a big rig hit the van limo he and his friends were riding in. Morgan's friend and collaborator James McNair, 62, died at the scene. Morgan and comics Ardie Fuqua and Harris Stanton, and Morgan's assistant, Jeff Millea, were injured.
Morgan is expected to be in the hospital for at least two more weeks. He suffered a broken leg, nose and ribs and has undergone surgery at Robert Wood Johnson University Hospital Center in New Brunswick.
The big rig driver, 35-year-old Kevin Roper, of Jonesboro, Ga., reportedly hadn't slept in at least 24 hours before the accident. He's scheduled to appear in court on Wednesday on charges of vehicular homicide and three counts of assault by auto, according to court documents.
Tony Hicks provides celebrity commentary for the Bay Area News Group. Contact him at Facebook.com/BayAreaNewsGroup.TonyHicks or Twitter.com/insertfoot.


text:
Kiki meets up with some old friends again. It has been hours since she last saw them. She knows that she can always rely on them.
Her reading brings memories flooding back. She goes back through the well-thumbed pages that have given her such happy times. But which of her little friends will be the chosen one this time? All of them bring pleasure so how to choose? Maybe the best way will be to try more than one?
Yes – that's doing it for her, the way she wants it.
Would you like to comment? Join us today, or sign in if you're already a member.


text:
Join free now!
It is free to search locals
After finish Richard, Ellen extended in the sun. Richard had brought a beach bag with him. If there was anything to check out, Ellen asked him. Richard handed her a book. Although the cover stated it was a trashy romance book, inside it was a collection of women's stories stating their very first time. Ellen was soon entirely mesmerized by the stories. There were also a couple of stories of women stating the first time they betrayed to their sweethearts or spouses. Ellen recognized once again how protected she had actually been till the Hart's entered her and Jack's life. While reading she discovered her wedding event band and engagement ring. Here she was masquerading as another guy's spouse while her own spouse was in a facade of his own.
After reading for a while Ellen decided to take a dip. Ellen might not help but discover how in shape he was. He wasn't Richard of course however he was undeniably well built.
Jack eyed the swimwear that his better half wore and flashed her a smile and a thumbs up. Ellen smiled, suggested his own skimpy clothing and flashed her own thumbs up. Ellen noticed Blair as Jack headed towards her. She was wearing an easy black one piece. Ellen might not assist but observe that despite the reality that Blair wore much more material, there was no concern that Blair was far sexier than Ellen in her swimwear. She understood precisely what Richard and Jack and every other man saw in Blair. It was something that she knew that she might never ever have. When the Hart's were completed with them, not for the first time Ellen questioned if Jack would be satisfied with her.
After finishing Richard, Ellen extended out in the sun. Ellen was quickly totally mesmerized by the stories. Ellen recognized once again how protected she had actually been till the Hart's entered her and Jack's life.
Jack was waiting in the space using a match Ellen had actually never ever seen prior to. Jack appeared surprised to see Ellen. Ellen felt an unexpected tint of jealousy.
Once they had actually ended up consuming and had actually gone back to the resort Richard led Ellen towards the east wing of the resort. He knocked on a door and Blair opened it.
Ellen observed Blair as Jack headed towards her. Ellen might not assist however discover that regardless of the reality that Blair used far more material, there was no concern that Blair was far sexier than Ellen in her swimsuit. Not for the very first time Ellen questioned if Jack would be pleased with her when the Hart's were ended up with them.
escort agency Mangatiti, escort service Mangatiti, escort girl Mangatiti, mature escorts Mangatiti, adult escorts Mangatiti, cheap escorts Mangatiti, local escort Mangatiti, independent escorts Mangatiti


text:
10% off Sitewide.
Enter this code during checkout to save at Flex Watches.
Code copied! Now enter this code at Flex Watches to save!
loyalty10 Shop
Browse all deals at Flex Watches
See more in Coupons & Rebates, Clothing Accessories
* This offer may contain time-sensitive information and offers. Please check with Flex Watches to confirm actual price & availability.
Please enter your name
- Be the first to comment!


text:
Carmen Reinhart and Kenneth Rogoff, in a formal response on Wednesday to a trio of researchers assailing their work, vigorously defended a seminal study they authored in 2010 while accounting for a spreadsheet glitch and addressing other criticisms.
A critique by University of Massachusetts researchers Thomas Herndon, Michael Ash and Robert Pollin heated up the blogosphere Tuesday with its discovery that Reinhart and Rogoff's influential paper grossly overstated the impact of high debt-to-GDP ratios as a result of a simple Excel spreadsheet error.
The University of Massachusetts trio also criticized what they termed "selective exclusion" of data that would be unfavorable to their conclusions as well as an alleged "unconventional weighting" of statistics.
Condemnatory reaction was swift, particularly from many liberal economists suggesting that Reinhart and Rogoff's research was aimed at discrediting high levels of public spending; one critic asked "how much unemployment was caused by Reinhart and Rogoff's arithmetic mistake" and several called for higher deficit spending.
In a full response on Wednesday (following a briefer reaction Tuesday), Reinhart and Rogoff (left), famed for their 2009 book on financial crises (This Time is Different), concede the spreadsheet glitch. "It is sobering that such an error slipped into one of our papers despite our best efforts to be consistently careful," they write.
But they argue the mistake does not invalidate the "central message" of the paper that Herndon, Ash and Pollin (HAP) critique and they counter HAP's other criticisms as well.
The coding error caused Reinhart and Rogoff to present countries with a debt-to-GDP ratio of greater than 90% as having an average growth rate of negative 0.1%, rather than HAP's corrected 2.2% growth rate.
Though they regret the error, "we are fortunate that we chose to present our results in several different ways, including means, medians and individual country averages, in no small part as standard robustness checks," they write.
In other words, the very same paper with a false mean result that HAP critiqued also contained much higher median (1.6%) postwar growth rates as well as results for a longer time period (1.9%) to which they gave parallel attention. Moreover, a subsequent study they conducted last year (that is, prior to the HAP critique) showed even higher long term growth rates for high debt countries of 2.4%.
So Reinhart and Rogoff are "grateful" for the HAP correction, which helps them "reconcile why one result is out of line with all the other results in our original paper."
But the economic duo take umbrage at HAP's accusation of "selective omissions," a charge they say permeates their critique. HAP's finding that Reinhart and Rogoff left out unfavorable data for postwar New Zealand is "explained by the fact there were still gaps in our public data debt set at the time of this paper, a data set no one else had ever been able to construct before and which we now have filled in much more completely," they write.
The New Zealand data had just become available at the time of their study—"HAP only knew we had these data as we sent them the file we had used at that time." Reinhart and Rogoff respond that they had not yet vetted the comparability of the data.
"But surely the authors do not mean to insinuate that we manipulated the data to exaggerate our results," the economic duo protest, noting that the same study contained multiple higher median figures and that they have continually documented and updated multiple sources in the public domain over the years.
As to the problem of unconventional weighting of statistics, Reinhart and Rogoff respond that they took average growth rates for each country, then group averages, which they duly reported in a table.
Yet they sought to avoid in another chart overly weighing a small number of counties with peculiarities. "We do not want to excessively weight Greece, for example, which has debt over 90% for 19 years in the 1946-2009 sample."
The bottom line, Reinhart and Rogoff say, is that HAP's results are in line with their own original conclusions. "They, too, find lower growth associated with periods when debt is over 90%. And they emphasize that a different table using median figures in the very same paper HAP critique were close to the corrected figure HAP generates.
Indeed, Reinhart and Rogoff go on offense in saying that HAP dangerously minimize the smaller growth rate differentials their corrected study shows.
High debt episodes tend to last 23 years on average, Reinhart and Rogoff say. "If a country grows at 1% below trend for 23 years, output will be roughly 25% below trend at the end of the period, with massive cumulative effects."
Finally, Reinhart and Rogoff lament accusations that politics influenced their scholarly work.
"Looking to the reaction to this comment in [the] blogosphere, we note that this is not the first time our academic work is seen pandering to a political view. What is quite remarkable is that this claim has spanned polar opposites! This time, we are charged with misconstruing analysis to support austerity. Only a few months ago, our findings on slow recoveries from financial crises was accused as providing a rationale for the deep recession and weak economy the Obama administration has faced since 2009," they write.
Indeed, amid the heat of the 2012 election campaign Reinhart and Rogoff critiqued advisors to Republican Mitt Romney's campaign who said the absence of a stronger economic recovery was out of line with historic norms.
The economic duo identified with neither party in the race, saying they spoke up merely to defend the thrust of their research that the U.S. is not different from the experience of other countries recovering from systemic financial crises.
Read Oops! Reinhart-Rogoff Research Tripped Up by Typo on AdvisorOne.


text:
LSU Athletics Online Fan Support
LSU Athletics Online Fan Support
Please select an area of interest:
Edit E-mail list(s) subscriptions:
Autograph Requests – Submit form to LSU Athletics Office of Compliance.
LSU Ticket Office – Questions, technical support with ticketing, parking or online account/billing issues.
LSU Athletics – Questions, suggestions and complaints for the LSU Athletics Department. | Directory
LSU Coaches – Prospective student-athletes or those looking to contact coaches directly.
LSU Sports Properties -- Questions for the Marketing and Multimedia Partner (TV, radio, internet, in-stadium, hospitality, and more).
LSU Marketing and Promotions -- Questions and suggestions about LSU marketing and promotions.
LSU Spirit Squads -- Questions about LSU Cheerleading, Tiger Girls Dance Team and Mike the Tiger mascot.
LSU Youth Camps – Questions, brochures and registration for Youth Camps.
LSUshop.net (Fanatics, Inc.) -- Customer service for online merchandise purchases (or call 866-231-1246)
Tiger Athletic Foundation – Questions for TAF.
Please use the following as LSU's mailing addresses:
Overnight/Shipping address:
To easily find this page, visit www.LSUsports.net/contactus.