[00:11:20] user890104: [00:11:21] https://mega.co.nz/#!d11EXZiA!I8sUs94Tb7Yn3KfrH4xU0-eRNpcRk8ICSTFCyQz4cGE [00:11:29] https://mega.co.nz/#!pgcTSbBa!TH2Kx3CtPQobDjBBJuchfpZEMO--nKekA4vDdYnl67E [00:11:37] https://mega.co.nz/#!cx03TDyT!f2VAWP1oPk4r_nhMAeYzBDNmfOeLtg6RV2pO9lR8CK0 [00:11:52] this one gives me ~17MB read and 18-19MB write [01:16:58] *** Quits: bcobco (~bcobco@77.225.204.119) () [02:11:08] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [02:11:08] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [06:34:07] *** Quits: TheSeven (~quassel@rockbox/developer/TheSeven) (Ping timeout: 245 seconds) [06:36:06] *** Joins: TheSeven (~quassel@rockbox/developer/TheSeven) [06:51:16] *** Quits: [Saint] (~saint@rockbox/staff/saint) (Remote host closed the connection) [06:52:20] *** Joins: [Saint] (~saint@rockbox/staff/saint) [08:11:10] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [08:11:10] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [08:29:59] *** Joins: bcobco (~bcobco@77.225.204.119) [09:10:42] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [09:11:07] *** Joins: bcobco (~bcobco@77.225.204.119) [09:16:27] TheSeven: ~22 MB/s read/write here, on my old laptop [09:16:46] i got 30 on a better one, will test there again [10:35:51] i can test on hackintosh [10:36:08] just to have more cases [10:58:22] bcobco: can't hurt ;) [11:11:28] *** Quits: [Saint] (~saint@rockbox/staff/saint) (Remote host closed the connection) [11:12:28] *** Joins: [Saint] (~saint@rockbox/staff/saint) [11:14:03] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [11:14:25] *** Joins: bcobco (~bcobco@77.225.204.119) [14:11:10] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [14:11:10] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [15:53:34] TheSeven: same speed on the "fast" computer [15:53:40] 30 read, 22 write [15:53:54] that's for large files (flacs) [15:54:27] so no noticable difference to the old one? [15:54:51] well, looks like we're just maxing out the bus on the read side [15:55:04] I don't get why write is slower than read though [15:55:10] should be the other way round [15:55:59] *** Quits: bcobco (~bcobco@77.225.204.119) (Quit: sudo rm -rf \/) [15:57:03] What's the disk's raw performance? [15:58:10] *** Joins: bcobco (~bcobco@77.225.204.119) [15:58:48] TheSeven: yes, no visible difference [15:58:59] * TheSeven compiles a build with test plugin [15:59:20] *** Quits: bcobco (~bcobco@77.225.204.119) (Client Quit) [16:00:34] gevaerts: just got an odd rockbox crash [16:00:43] never seen that type of panic screen before [16:00:56] *PANIC* usb_storage_init_connection(): OOM [16:01:07] Oh. Recent rockbox? [16:01:12] git head [16:01:17] See kugel :) [16:01:19] or master or whatever they call it [16:01:28] *** Joins: bcobco (~bcobco@77.225.204.119) [16:01:30] It means it can't get memory for the buffer [16:01:52] There was a window of a few weeks several months ago with a bug in there, but that one's gone [16:16:15] gevaerts: test_disk only reports "Create (512,A): 8370KB/s" and then seemingly freezes [16:16:40] Sounds like you have interesting things to look at :) [16:17:12] I can't rule out I/O errors/lockups on this piece of hardware [16:36:41] gevaerts: finally finished the next one: Write (512,A): 68KB/s [16:37:06] In that case, your USB numbers are *impressive*! [16:37:08] Read (512,A): 7987KB/s [16:38:33] Create (512,U): 7276KB/s [16:40:45] * gevaerts waits for the 4096 numbers :) [16:41:15] well, first we'll have to wait for write 512 U, which will take another half an hour or so [16:56:58] gevaerts: C/W/R (4096,A): 8578 / 9273 / 8303 KB/s [16:57:20] gevaerts: C/W/R (4096,U): 8300 / 8829 / 7423 KB/s [16:57:40] gevaerts: C/W/R (1048576,A): 8380 / 8857 / 8184 KB/s [16:57:58] gevaerts: C/W/R (1048576,U): 7774 / 8793 / 8305 KB/s [16:58:30] so not quite sure what this thing is doing... either it's messing around with a badly damaged area of the disk, or it's just slow [16:59:48] emCORE diskmode gives me 13MB read 18MB write peak [17:00:43] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [17:01:08] *** Joins: bcobco (~bcobco@77.225.204.119) [17:03:10] gevaerts: rockbox USB gives me 12MB read 13MB write [17:04:21] so the benefit of write double buffering is clearly visible [17:04:31] the one of read ahead... not so much [17:07:26] TheSeven: I'm slightly confused here [17:07:34] rockbox should do write double-buffering [17:07:47] hm [17:08:20] then there's something else that's slower in rockbox's write path than in emcore's [17:08:33] which is funny as they're mostly clones [17:08:53] Hmmm [17:09:00] Wait, it all depends [17:09:04] * gevaerts isn't sure now!~ [17:10:04] I'm doing it fairly aggressively [17:10:08] How exactly does your double-buffering work on write? [17:10:39] I basically defer the write and start receiving the next block (or command) [17:10:51] Right. [17:11:07] I don't think I send the CSW until the data is written [17:11:09] which means that I/O errors will be misattributed to the next chunk, or completely ignored if it was the last one [17:11:18] I think... [17:11:24] that would explain it [17:11:25] * gevaerts 's memory is hazy! [17:11:47] I know I once had asynchronous CSWs, but I don't remember if those were committed [17:13:15] * TheSeven has a look at the code [17:13:58] http://www.rockbox.org/tracker/task/10239 [17:14:31] The big problem is that write errors become mostly invisible to users [17:15:00] On windows e.g. they appear somewhere in the event log, and *nowhere* else [17:15:34] Similar on linux, where you notice the filesystem going read-only and dmesg having new lines, but cp didn't see anything [17:15:42] And that wasn't worth the performance for me [17:16:30] I don't get why that would happen unless the error is in the last chunk of the SCSI command, but how would those even end up in dmesg? [17:16:56] How do you report errors? [17:17:57] I just report them on the next chunk [17:18:12] actually what I'm doing might be plain wrong there [17:18:46] how should an I/O error behave? I'm fairly sure that it won't cancel the data reception early [17:18:54] Yes, that's not what you're supposed to do. If you do that, the OS will assume that the last written block is wrong [17:19:04] Which in your case is off by one :) [17:20:03] how does send_csw behave if the data stage isn't over yet? [17:20:10] I'd expect that to cause a bus lockup [17:20:35] as the host won't even request the CSW before it has ACKs for the data stage [17:20:41] It's on a different endpoint (the return one), so that should be OK [17:21:05] The thing that's different (IIRC) is what you return to REQUEST_SENSE [17:22:02] As far as I know, FS#10239 is technically correct (although it won't apply any more), so that's what I'm basing things on now [17:22:54] IIUC you need to STALL the OUT EP if you want to send an early CSW [17:23:34] "The device shall receive the intended data. [17:23:34] The device shall either accept a total of dCBWDataTransferLength, or end the transfer [17:23:34] prematurely by STALLing the Bulk-Out pipe." [17:23:43] * gevaerts nods [17:24:07] I don't see the big advantage in doing that though. Just accept the data and then report back that you didn't write it :) [17:24:15] yes [17:24:26] but that's not what the current code seems to be doing [17:25:08] http://git.rockbox.org/?p=rockbox.git;a=blob;f=firmware/usbstack/usb_storage.c;h=59ada3bdd87580bb36e3bed9dae22eca42aa3372;hb=HEAD#l546 [17:26:25] Hmmm [17:26:54] You mean it could still be receiving data through line 526? [17:27:47] yes, and probably interpret that as a CBW [17:28:00] because it's in WAITING_FOR_CSW_COMPLETION_OR_COMMAND state [17:28:05] Good point [17:28:28] not quite sure what exactly would happen, but it smells ultra fishy [17:28:54] Only on USBOTG_AS3525 or STORAGE_SD though :) [17:29:06] That's likely to be a bug [17:29:22] why only on those two? [17:29:45] Because on everything else WRITE_BUFFER_SIZE is 64K, and that's the most hosts ever send [17:29:53] nah [17:29:59] linux keeps sending 120KB chunks here [17:30:00] Wait [17:30:05] Really?> [17:30:16] not 128, but something slightly below it [17:30:26] That must be new... [17:30:36] * gevaerts investigates [17:30:57] possibly related to 4K sector size in some way? [17:31:32] I doubt it. The old 64K limit was because of so many usb devices breaking if you tried more [17:31:48] * gevaerts is updating his linux git tree to find out [17:33:00] OK, right [17:33:06] max_sectors = 64 [17:33:15] So yes, sector size dependent [17:33:41] Which means you *do* get double-buffering, since rockbox handles things 64K at a time :) [17:33:57] (and writes to disk while receiving the next chunk) [17:48:44] yes, just only for every second chunk [17:49:13] user890104: who was that guy with the SD-modded ipod who was running into ATA trouble? [17:49:16] is he still around? [17:49:24] I've improved the error handling in that area a bit [17:54:11] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [17:54:37] *** Joins: bcobco (~bcobco@77.225.204.119) [18:01:13] * user890104 greps his logs [18:02:16] he went by the name ipod_user apparently [18:03:36] freenode_#freemyipod-support_20140410.log:61:[11:33:34] i'm using a 128GB SDXC SanDisk-card, combined with the iFlash SD-CF Adapter Bundle from tarkan.info [18:03:38] yes [18:07:26] ipod_user (3eb24718@gateway/web/freenode/ip.62.178.71.24) [18:50:50] TheSeven: [18:50:54] http://i.imgur.com/35DDS1A.png [18:51:00] looks like a corrupted FS, right? [18:51:13] yes [18:52:20] C:\Windows\system32>chkdsk.exe G: [18:52:20] The type of the file system is FAT32. [18:52:20] An unspecified error occurred (666174766f6c2e63 d6). [18:52:21] lol [18:52:29] *** Quits: [Saint] (~saint@rockbox/staff/saint) (Remote host closed the connection) [18:52:35] lol, have you ever seen that work on an ipod? [18:53:18] well, if it only does block-level operations, it should work, right? [18:53:32] it gets confused by something [18:53:58] yes, and the GUI variant just terminates after running, no success/error message at all [18:54:06] that "666174766f6c2e63 d6" error is actually a failing assertion in fatvol.c line 214 [18:54:56] looks like they just terminate the app when there's an unspecified error [18:55:30] ah, that's hex-encoded ascii :) [18:56:09] i'll just reformat it, and transfer back my files [18:56:25] seems like one of the diskmode apps has a bug [18:56:37] try chkdsk on a freshly formatted one and it will fail the same way [18:56:47] *** Joins: [Saint] (~saint@rockbox/staff/saint) [18:56:51] if you want to repair the FS: use fsck on linux [18:56:56] really? why is that? [18:57:09] chkdsk is just dumb [18:57:14] I've never seen it work on an ipod [18:57:17] not quite sure why [18:57:29] given that some HDDs have the same sector size these days [18:57:52] is there something wrong we're doing to the fat table? [18:58:08] i mean, if i format it with some other tool, is it also supposed to fail? [18:58:31] no idea [18:58:56] i'll try this later, when i get home [19:15:15] try with fsck [19:16:39] fsck.msdos [19:22:42] bcobco: I think he's more interested in why chkdsk breaks than in actually repairing the damage ;) [19:29:43] chkdsk expect a fat filesystem created in redmond headquarters [19:30:30] and signed by steve ballmer [19:31:50] does rockbox can support another filesystem? (ext2 for example) [19:32:01] i mea, if its technically possible [19:32:07] mean* [19:33:15] only with major rework [19:50:37] i have to update rockbox. version 6b01da8-140225 has huge playback underruns [19:52:09] any version recomendation? (thx in advance) [20:11:11] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [20:11:11] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [20:25:50] *** Quits: [Saint] (~saint@rockbox/staff/saint) (Remote host closed the connection) [20:27:20] *** Joins: [Saint] (~saint@rockbox/staff/saint) [22:27:47] *** Quits: krnlyng (~liar@83.175.90.24) (Ping timeout: 252 seconds)