Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: potential bug report
From: Greg Haerr (greg_at_censoft.com)
Date: 2002-06-12


A quick review of the source shows that,
although not a bug yet, the code in
firmware/drivers/ata.c::ata_read_sectors()
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)

Regards,

Greg



Page was last modified "Jan 10 2012" The Rockbox Crew
aaa