• Status Closed
  • Percent Complete
  • Task Type Bugs
  • Category Operating System/Drivers
  • Assigned To No-one
  • Operating System HW-codec
  • Severity High
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by dreamlayers - 2011-12-02
Last edited by dreamlayers - 2011-12-06

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

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.

Closed by  dreamlayers
2011-12-06 17:05
Reason for closing:  Fixed
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

Fixed in r31155 for trunk and r31160 for 3.10 branch.

Thanks for tracking this down. I hope this eliminates the previously inexplicable need for the sleep() in glyph_cache_save().

Your fix seems to take care of glyph_cache_save(). You may as well roll this in when you commit.

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.


Available keyboard shortcuts


Task Details

Task Editing