FS#10679 - Nano2G "PANIC Stkov dircache" message during database auto update

Attached to Project: Rockbox
Opened by Grant Whiteheart (grantmasterflash) - Friday, 16 October 2009, 13:24 GMT
Last edited by Michael Sparmann (TheSeven) - Wednesday, 17 February 2010, 11:36 GMT
Task Type Bugs
Category Operating System/Drivers
Status Closed
Assigned To No-one
Operating System iPod Nano 2G
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


I'm using r23198-091015 on my 8GB Nano 2G. I've noticed that if I enable Directory Cache (General -> Disk -> Directory Cache -> Yes) and Auto Update (General -> Database -> Auto Update -> Yes), once Rockbox restarts after adding new music files in disk mode, I always get a

Stkov dircache

message. I then hold Menu and Select to reboot and the new files have been added correctly to the database, but clearly something is going wrong during the auto update.

Disabling either of these settings will stop the PANIC - meaning, if only Auto Update or only Directory Cache is enabled, the PANIC does not occur. It's only when Directory Cache is enabled in addition to Auto Update that the PANIC will always occur a few seconds after Rockbox startup after new music files are added to the device.
This task depends upon

Closed by  Michael Sparmann (TheSeven)
Wednesday, 17 February 2010, 11:36 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fix committed in r24708
Comment by Dave Chapman (linuxstb) - Friday, 16 October 2009, 13:46 GMT
The size of the dircache stack is define on line 77 of firmware/common/dircache.c - "DEFAULT_STACK_SIZE + 0x900".

Could someone experiencing this problem who compiles their own builds try increasing this size and try and determine the smallest safe stack size? e.g. replace that "0x900" by "0x1000" (or 0x2000 etc).

The main stack size for Rockbox on the Nano2G is already twice the size of other targets, due to the larger sector size being used (and there are various places in the code where sector buffers are stored on the stack). I'm not surprised that the dircache stack also needs increasing.
Comment by Grant Whiteheart (grantmasterflash) - Friday, 16 October 2009, 14:50 GMT
I tried the 3 values you noted above. The PANIC only stopped with 0x2000. Should I try some values between 0x1000 and 0x2000? Sorry, I'm not sure if there are only certain increments I'm supposed to be trying here.
Comment by Dave Chapman (linuxstb) - Friday, 16 October 2009, 22:04 GMT

Thanks for testing.

Could you also try 0x1400, 0x1800, and 0x1c00 ? You can try any increments, but it's probably not worthwhile doing anything more than those three.

Comment by Grant Whiteheart (grantmasterflash) - Friday, 16 October 2009, 23:20 GMT
Glad to help out. Thanks to you and the other devs for all the recent Nano2g work.

0x1800 is the lowest of those that eliminates the PANIC in my tests.
Comment by Magnus Holmgren (learman) - Saturday, 17 October 2009, 08:47 GMT
Hm, I wonder if the 2 KB stack buffers in ftl_copy_page and ftl_copy_block has anything to do with it...
Comment by Michael Sparmann (TheSeven) - Wednesday, 10 February 2010, 21:40 GMT
Those stack buffers are gone now, so one may want to check if the value can be further decreased now. I think it's rather coming from some sector buffers in the FAT driver though. Those FTL functions are only called on writes, and I don't see why the dircache should perform write operations...
Comment by Grant Whiteheart (grantmasterflash) - Thursday, 11 February 2010, 00:06 GMT
I tried this with r24589M-100210, first with DEFAULT_STACK_SIZE + 0x1400. I got the PANIC with that. Changed it to 0x1800 and no PANIC, so nothing seems to have changed with this so far.