[00:10:38] *** Quits: [Saint] (~saint@rockbox/staff/saint) (Quit: Quit.) [04:14:58] *** Joins: [Franklin] (~franklin@unaffiliated/franklin) [04:31:06] *** Quits: [Franklin] (~franklin@unaffiliated/franklin) (Quit: Lost terminal) [06:35:22] *** Quits: TheSeven (~quassel@rockbox/developer/TheSeven) (Ping timeout: 265 seconds) [06:36:18] *** Joins: TheSeven (~quassel@rockbox/developer/TheSeven) [13:54:58] *** Joins: luyikei (~quassel@i255020.dynamic.ppp.asahi-net.or.jp) [13:59:33] *** Quits: luyikei (~quassel@i255020.dynamic.ppp.asahi-net.or.jp) (Ping timeout: 265 seconds) [14:01:23] *** Joins: luyikei_ (~quassel@i255020.dynamic.ppp.asahi-net.or.jp) [17:32:49] *** Quits: luyikei_ (~quassel@i255020.dynamic.ppp.asahi-net.or.jp) (Remote host closed the connection) [20:57:49] well this isn't really writeahead [20:58:09] you need to defer the writes to userspace because you can't access the disk from the IRQ handler [20:58:38] what I'm doing is already accepting the next scsi command while such a write is taking place [20:58:52] (or the next block of a large write) [20:59:09] so this is basically just pipelining [21:00:36] you could simplify things a bit by only sending the CSW (or accepting the next data block) after the block has been written to disk [21:00:53] basically always forcing the overrun condition [21:01:48] but that also isn't really trivial, would likely cut performance in half and I'm not sure if it would actually fix the problem - I'd rather have a look what's wrong with that code in the first place [21:02:07] and I think I've spotted the cause, we just need to work out what exactly that code should be doing instead [21:03:14] what seems to be happening here is that two write blocks come in at once from a userspace point of view - either because of the thread wakeup taking too long for some reason, or because of the thread being already busy doing readahead [21:03:48] this is simply a case that needs to be handled properly which the code doesn't seem to take care of yet [21:04:29] we should look at the write busy and overrun flags and all possible races that could occur there [21:44:53] *** Quits: Guest68659 (1003@lotjuh.xenbro.nl) (Quit: leaving) [23:56:26] *** Joins: [Franklin] (~franklin@unaffiliated/franklin)