Rockbox mail archive
Subject: potential bug report
From: Greg Haerr (greg_at_censoft.com)
A quick review of the source shows that,
although not a bug yet, the code in
won't work if the count parameter is ever
called with a value != 1. This is because the
'buf' value in the inner for loop is never incremented
by the size of a disk sector (512).
All current cases of ata_read_sectors from
fat.c are called with count == 1 for the time being.
BTW, I'm trying to understand exactly how many threads
are running in the current version. Is it just the mpeg_thread,
or is there a seperate UI/button thread? I ask because
the ATA disk routines have mutex sections, and was
wondering whether the entire disk subsystem was built
to work using open "files" from multiple threads... Very
cool low-level code, BTW.
In the kernel.c mutex_lock function, there's no STI/CLI
pair around the mutex, is this because there's no
preemptive scheduling? I see that the queue_post routines
have it, and I assume that's because those routines can
be called from a bottom-half interrupt routine (which
aren't scheduled, just interrupt-driven?
I haven't seen yet what gcc emits for SH1, but for
some systems, ++m->count is much faster than
m->count++. (same for decrement)
Page was last modified "Jan 10 2012" The Rockbox Crew