- 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
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:
*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.
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
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#12302I 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: http://www.rockbox.org/irc/log-20111204#17:16:55 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.