[00:40:47] TheSeven: if diskmode looks stable enough for a beta release, should we make it public? [00:41:07] or you prefer waiting for more feedback [00:41:21] well, we should figure out what caused your data corruption case [00:41:40] probably my own tests [00:41:45] and I'd release it along with a bunch of other improvements, such as better ATA error handling [00:41:58] or resetting the ipod while performing a transfer [00:42:07] it's a development device after all [00:42:09] I'm aware of a few possible race conditions in my current code [00:43:26] ok, what about fixing the kernel bugs and releasing my version without your buffering optimizations, just with splitting [00:43:44] so future installs won't have mounting issues [00:44:00] huh? which mounting issues? [00:44:05] then take as much time as needed to fix the optimised code [00:44:13] the ones with rockbox [00:44:40] it still fails for some users [00:44:42] there are two known issues: [00:44:59] 1. if a readahead is in progress, and something requests another sector range for the same buffer, there's a brief window during which the old data could be accepted as the response for the new request [00:45:25] 2. if a write hits the same sectors as an in-progress readahead, a subsequent read could return old data [00:45:58] both of those should only cause temporary read corruption, but who knows what kind of cascading effects this could cause [00:47:54] anything that contains "corruption" doesn't sound good to me :) [00:48:49] both only occur if a very rare sequence of operations meets a very narrow timing window, but they need a better fix regardless [00:49:57] also, I/O errors just aren't handled properly right now [00:50:03] is there a trivial way to fix it? adding some variables e.g. buffer0_busy = 1? [00:50:21] no, it's a nasty race condition between IRQ and user mode [00:50:41] ah, i see [00:50:45] that, in combination with enter_critical_section not being available in apps (why?) makes this a bit tricky to fix [00:51:23] someone should also investigate why rockbox is having trouble in the first place [00:51:32] problem is that I can't reproduce it at all [00:51:44] well, i can [00:51:56] and i can dump the usb traffic if this helps [00:52:12] also, it doesn't mount on n2g [00:52:52] the funny part about nano2g is that versions of rockbox that properly work as mass storage devices, are incompatible with emcore's lcd config [00:52:55] yes, I'll have a look at n2g, but that looks like a different problem [00:53:08] so you either have working mass storage, or a working lcd :) [00:54:43] hm, one could try implanting the new usb driver into rockbox, but it seems like there are quite some API differences [00:55:31] sound like a task for Mr. Someone [01:00:57] what kind of exception does the usb irq bug cause? [01:01:46] is it possible that those rename() data aborts are caused by it? [01:02:57] also, disk_unmount() seems to fail if the filesystem failed to mount, i.e. is not mounted *and* corrupted [01:03:28] needs investigation [01:03:48] ok, can you commit the fix? i can do some testing [01:07:09] which fix? [01:07:16] and no, I can't currently commit things [01:07:19] we need to set that up first [01:07:42] ah, right. can you generate an ssh key for that? [01:10:18] ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC7WxfCH2ZqXvHLZRo2v6UbfPxDYzoPBjR1UkSvqGMK05N3qj5piWmND7ugh+AzqTW83EpR4jvGv/ucQykBWvnMWOxbNB+nwzRx+/lAz5Id+sAc+IitBglEhT3tLB0cfBMlukfU4GJPCZ9U3axAW8JSOznqdwzhV0oYi6W2OFcqQFhje94Y5E2PI+Wwg3q6wwlIqDPFjPbwmRGE6sTmGpbcmCOsYWKBJx0TqB+Bo6Zgdgkxk0yJBmuBVy3RPpOXBRhWyUJ13hsFUA/7joZMxCUtbkp8b8ryFcfKPPiqeINfMTI09PvQCJD6F65g0MGDFixeZnpyG3b2Lvz6pr+pbLsX theseven@gmx.net [01:11:33] luckily, it didn't get truncated [01:16:47] ok, use svn+ssh://svn.freemyipod.org/ with username svn for commits, and username theseven for shell access (root with sudo -i, without a password) [01:17:24] there's a TNT toolchain in /home/build/toolchains/TNT [01:18:33] nano2g analysis says that after a few roundtrips of scsi requests, a read request will lock up during the data stage [01:18:45] the ipod thinks at that time that it would be sending a CSW [01:19:21] that kinda doesn't make sense because both go through the same EP, so the pending data stage transfer from the host should ACK the CSW, which it doesn't [01:19:41] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [01:20:05] *** Joins: bcobco (~bcobco@77.225.204.119) [01:20:07] so the ipod somehow spuriously gets an ACK for the data stage, then tries to send a CSW and that either never actually gets sent, or the ack of it gets ignored, I suspect the former [01:20:26] if the CSW would go through, it should kill the data stage transfer as a short packet which it doesn't [02:11:10] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [02:11:10] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [06:14:32] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [06:14:54] *** Joins: bcobco (~bcobco@77.225.204.119) [06:32:52] *** Quits: TheSeven (~quassel@rockbox/developer/TheSeven) (Ping timeout: 245 seconds) [06:35:18] *** Joins: TheSeven (~quassel@rockbox/developer/TheSeven) [07:47:46] *** Quits: [Saint] (~saint@rockbox/staff/saint) (Quit: Quit.) [07:48:05] *** 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:47:57] *** Joins: slenselink__ (~STeeF@office.hostnetbv.nl) [10:08:55] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [10:09:21] *** Joins: bcobco (~bcobco@77.225.204.119) [13:34:15] *** Quits: [Saint] (~saint@rockbox/staff/saint) (Remote host closed the connection) [13:35:46] *** Joins: [Saint] (~saint@rockbox/staff/saint) [13:36:22] *** Quits: [Saint] (~saint@rockbox/staff/saint) (Remote host closed the connection) [13:43:32] *** Quits: bcobco (~bcobco@77.225.204.119) (Remote host closed the connection) [13:43:57] *** Joins: bcobco (~bcobco@77.225.204.119) [13:50:23] *** Joins: [Saint] (~saint@rockbox/staff/saint) [14:11:14] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [14:11:15] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Read error: Connection reset by peer) [17:43:13] *** Joins: krnlyng (~liar@83.175.90.24) [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)