FS#12423 - Rockbox access to /.rockbox/fonts after usb_enable(true)

Attached to Project: Rockbox
Opened by Boris Gjenero (dreamlayers) - Friday, 02 December 2011, 05:16 GMT
Last edited by Boris Gjenero (dreamlayers) - Tuesday, 06 December 2011, 17:05 GMT
Task Type Bugs
Category Operating System/Drivers
Status Closed
Assigned To No-one
Operating System HW-codec
Severity High
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


On my Archos Recorder V2, when running recent versions, including 3.10RC and r31107, entry into USB mode can be slow and problematic. Unfortunately, I'm not always able to reproduce this. When it happens, it happens repeatedly, but sometimes it repeatedly doesn't happen. Based on the following 3 pieces of evidence, it seems like Rockbox is trying to do something with the disk after the USB to IDE bridge chip is allowed to start using it.

When it happens, there is a long wait before the USB screen is displayed, during which time the red LED is on. I hear disk access as if there is disk access from the computer, and there are many disk errors in dmesg. The LED goes off right before the USB screen appears.

I edited r31107 firmware/usb.c to write strings at various points of usb_slave_mode(). When the problem happens, the string from after cpu_idle_mode(true) is on the screen and the red LED is on.

In the SMART error log on the original DK23EA-20 drive (accessible via smartctl), I saw ICRC errors, which I think means interface CRC, meaning Ultra DMA CRC. This would be consistent with Rockbox doing stuff which corrupts DMA data. (The ISD-300 configuration EPROM has been modified to enable Ultra DMA, using this ) The drive passed the long SMART self-test, and reading of the entire drive surface completed without any errors reported or logged.

Edit: I have traced it to an opendir_uncached("/.rockbox/fonts") that starts after the end of usb_slave_mode(on). So, I guess the font code needs some changes. It would also be nice to have something at the storage or ata level preventing further storage access after storage_enable(false).

Edit 2: I have now traced it to an opening of the font file in glyph_cache_save(). Fonts are closed in gui_usb_screen_run(), but usb_acknowledge(SYS_USB_CONNECTED_ACK) happens before it. So, USB mode can be activated before font_unload() calls. In this patch, I move the usb_acknowledge(SYS_USB_CONNECTED_ACK) to just before the while (1) main loop of the USB screen. This fixes the problem on my Archos Recorder V2, and USB mode entry becomes fast and reliable. It ought to be safe to put the acknowledge earlier, but I see no problem with putting it just before the loop.

I have an electrical concern relating to this bug. It's not good to have the CPU fight the bridge chip. If one pin drives an IDE bus line high and another pin drives it low, that could overload the pins. I'd like to have more protection here, such as pin setup via ata_enable(false) which ensures that the CPU can't drive the IDE bus and/or blocking of disk activity at the ata or storage level. However this this patch ought to be good enough for now.
This task depends upon

Closed by  Boris Gjenero (dreamlayers)
Tuesday, 06 December 2011, 17:05 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed in r31155 for trunk and r31160 for 3.10 branch.
Comment by Fred Bauer (freddyb) - Saturday, 03 December 2011, 14:29 GMT
Thanks for tracking this down. I hope this eliminates the previously inexplicable need for the sleep() in glyph_cache_save().
Comment by Fred Bauer (freddyb) - Saturday, 03 December 2011, 16:05 GMT
Your fix seems to take care of glyph_cache_save(). You may as well roll this in when you commit.
Comment by Boris Gjenero (dreamlayers) - Tuesday, 06 December 2011, 01:04 GMT
I committed delay_usb_screen_acknowledge.patch and 86_glyph_cache_save_delay.patch in r31155.

I think delay_usb_screen_acknowledge.patch ought to be in 3.10 because of the severity of the problem and importance of having a well functioning USB mode. The situation is especially bad on the V2 and FM Recorder, because there BootBox in the v3 bootloader has a bug which makes entry into BootBox USB mode difficult (FS#12426). I wouldn't include 86_glyph_cache_save_delay.patch in 3.10, due to an overabundance of caution.