Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#11995 - screendump problems caused by r29445

Attached to Project: Rockbox
Opened by Michael Chicoine (mc2739) - Monday, 07 March 2011, 17:48 GMT+2
Task Type Bugs
Category Drivers
Status New
Assigned To No-one
Player Type Sansa e200
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Private No

Details

r29445 introduced problems with screendump on sansa e200 and e200v2 (and possibly more). Screendump works properly with r29444.

Steps to reproduce:

1. delete or backup existing .rockbox directory
2. install r29445 (or later)
3. reboot
4. navigate to System -> Debug (Keep Out!) -> Screendump and press select to enable
5. attach USB cable to trigger screendump

On e200, this results in:
*PANIC*
Stkov usb (0)

on e200v2, this results in a deadlock - no keypad response - backlight & button light never timeout. Upon reboot, multiple dump files exist.

On e200v2 only, when dircache is disabled, screendump will function properly.
This task depends upon

Comment by Michael Sevakis (MikeS) - Tuesday, 08 March 2011, 09:06 GMT+2
Just to start off, try upping the USB thread stack size a good amount and check if it goes away. My gigabeat S showed stack use for a screendump to be very high (97%) without dircache enabled. That plus target differences in stack usage can mean different character of failure.
Comment by Michael Chicoine (mc2739) - Tuesday, 08 March 2011, 18:44 GMT+2
I increased USB stack size by 0x400 and screendump works for both e200 and e200 v2.

USB stack usage for various size increases (screendump works in all cases):

e200 increase 0x400 - 59%
e200 increase 0x200 - 75%
e200 increase 0x100 - 86%
e200 increase 0x080 - 96%

e200v2 increase 0x400 - 59%
e200v2 increase 0x200 - 75%
e200v2 increase 0x100 - 86%
e200v2 increase 0x080 - 94%
Comment by Michael Sparmann (TheSeven) - Friday, 11 March 2011, 00:56 GMT+2
Hm, would be interesting to know where the overflow actually happens. Is it in the FAT/storage code?
Should we commit a stack size increase by 0x100?
Comment by Boris Gjenero (dreamlayers) - Monday, 05 December 2011, 23:18 GMT+2
I am unable to reproduce this in r31152 on my 5G iPod. If you want to track this down, try the ARM backtrace patch:  FS#12302 
Comment by Michael Chicoine (mc2739) - Tuesday, 06 December 2011, 05:29 GMT+2
I am also unable to reproduce this on e200 and e200v2 (r31155)

e200 USB stack usage - 97%
e200v2 USB stack usage - 94%
Comment by Michael Sparmann (TheSeven) - Tuesday, 06 December 2011, 22:40 GMT+2
Seems to be happening on some targets but not on others: http://www.rockbox.org/irc/log-20111204#17:16:55
A stack size increase has been committed to the release branch.
Comment by Boris Gjenero (dreamlayers) - Wednesday, 07 December 2011, 07:22 GMT+2
The backtrace didn't work too well with this, but it helped. From thread_stkov(), it just showed where switch_thread() calls thread_stkov(), and a backtrace from ata_transfer_sectors() ended where fat_getnext() calls fat_readwrite().

A lot of the stack is used by opendir_uncached(), which is called when opening a file for writing. It subtracts 0x224 from SP for local variables. What it's doing seems reasonable. However, you don't need stack space for creat() and linebuf[] at the same time, and that provides an opportunity for reducing stack usage.

Edit: This uses __builtin_alloca() to allocate linebuf after a successful creat(). It reduces stack usage in r31161 on my 5G 30GB iPod from 96% to 72%. I didn't do it for the remote because remotes seem to require less memory for linebuf, so there should be extra space due to that. It could easily be done for remotes also.
   alloca_for_linebuf.patch (0.8 KiB) 
 firmware/screendump.c |    9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

Loading...