• Status New
  • Percent Complete
  • Task Type Bugs
  • Category Drivers
  • Assigned To No-one
  • Operating System Sansa e200
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by mc2739 - 2011-03-07

FS#11995 - screendump problems caused by r29445

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:
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.

MikeS commented on 2011-03-08 08:06

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.

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%

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?

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 

I am also unable to reproduce this on e200 and e200v2 (r31155)

e200 USB stack usage - 97%
e200v2 USB stack usage - 94%

Seems to be happening on some targets but not on others: A stack size increase has been committed to the release branch.

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.


Available keyboard shortcuts


Task Details

Task Editing