[02:01:29] *** Quits: Dgby714_ (~dgby714@nala.villavu.com) (Read error: Operation timed out) [02:01:37] *** Joins: Dgby714 (~dgby714@nala.villavu.com) [02:04:00] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [02:04:00] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [02:14:03] *** Quits: Kebianizao (~kvirc@95.2.219.87.dynamic.jazztel.es) (Quit: Estaba usando KVIrc KVIrc Equilibrium 4.2.0, revision: 420, sources date: 20120701, built on: 2013-05-18 09:37:12 UTC 420 http://www.kvirc.net/) [03:32:23] *** Quits: TheSeven (~quassel@rockbox/developer/TheSeven) (Read error: Operation timed out) [03:33:12] *** Joins: TheSeven (~quassel@rockbox/developer/TheSeven) [03:34:41] *** Quits: alberthrocks (~alberthro@unaffiliated/alberthrocks) (Read error: Connection reset by peer) [03:52:31] *** Joins: [Saint] (~saint@rockbox/user/saint) [03:52:31] *** Quits: [Saint] (~saint@rockbox/user/saint) (Client Quit) [03:52:50] *** Joins: alberthrocks (~alberthro@unaffiliated/alberthrocks) [03:52:55] *** Joins: [Saint] (~saint@rockbox/user/saint) [03:53:02] *** Quits: [Saint_] (~saint@rockbox/user/saint) (Ping timeout: 264 seconds) [06:16:58] *** Quits: TheSeven (~quassel@rockbox/developer/TheSeven) (Disconnected by services) [06:17:08] *** Joins: [7] (~quassel@rockbox/developer/TheSeven) [06:54:03] *** Quits: [Saint] (~saint@rockbox/user/saint) (Remote host closed the connection) [06:55:23] *** Joins: [Saint] (~saint@rockbox/user/saint) [08:03:57] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [08:03:57] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [09:51:15] [7]: http://i.imgur.com/RtSb6FS.jpg [09:51:22] doesn't look good to me :) [14:04:01] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [14:04:01] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [14:16:09] <[7]> user890104: interesting... huge burst of bad blocks at the end? [14:16:28] <[7]> my scanner crashed with a stack overflow [14:21:36] <[7]> hm, it seems to have somewhat finished [14:21:50] <[7]> the end result was a properly formatted drive with a zero byte hddscan_result.bin on it [14:22:10] <[7]> so it probably crashed somehow while writing the result data [14:23:20] <[7]> the new BBT is a bit smaller than the old one... I'm wondering what happened there [14:25:26] <[7]> hm, a lockup while writing the result file suggests that it might have run into undiscovered bad blocks while doing so [14:25:42] <[7]> which could happen if the drive changes its behavior while scanning [14:25:51] <[7]> i.e. testing the last blocks corrupts some earlier ones [14:27:08] mine is expected to be finished, i'll have a look at the result when i get home [14:27:39] which software uses the BBT? emcore? rockbox? something else? [14:29:02] <[7]> both [14:29:38] <[7]> given that mine screwed up somehow I'd strongly suggest to take a full memory dump once it's done before doing anything else [14:29:53] <[7]> i.e. emcore.py downloadfile 0x08000000 0x04000000 memdump.bin [14:30:26] <[7]> it's likely to have written the BBT, but not the result files (which contain more information) [14:31:10] what will happen when it's done? does it reboot the ipod or exits the app (deallocating all its memory)? [14:35:14] <[7]> in theory the latter, but in that case it should have saved all state info to the disk [14:35:56] <[7]> or it will just lock up like mine (with the monitor thread crashing), in which case the allocations will still be there [14:43:10] if the monitor thread crashes, how do i dump the memory? :) [14:46:52] <[7]> using the command above [14:50:38] isn't the monitoring thread responsible for usb debugging? [14:51:13] <[7]> 1. I'm talking about the hddscan monitoring thread which handles statistics display [14:51:26] <[7]> 2. downloadfile doesn't rely on the other one either, it's fully IRQ driven [14:52:04] <[7]> only things that are "complex" (e.g. lock mutexes or take long) are done by the USB monitor thread [14:52:21] <[7]> the other ones are handled straight from the packet received IRQ [14:52:44] <[7]> (which means that memory access and "emcore.py reset 1" will always work as long as the kernel isn't hard-frozen) [14:53:04] <[Saint]> nice [15:16:52] <[7]> http://theseven.bounceme.net/~theseven/tmp/bbt_diff.htm [15:16:57] <[7]> I'm wondering if I should merge them... [15:18:23] <[7]> really weird that the damage can "move" like that [15:19:05] <[7]> the total number of bad blocks dropped from 6145 to 5747 [15:20:34] * [7] wonders to which degree firmware bugs might be involved here [15:20:52] *** Quits: Rurd2di (~Rurd2di@hotaru.1337.net.nz) (Ping timeout: 264 seconds) [15:22:15] <[7]> drive firmware revision: VQ1100A [15:23:25] <[7]> retracts: 2129, reallocs: 4832, pending: 3376, poweron hours: 646, start/stops: 23761, temp: 28°c (lifetime min/max: 2°C/53°C) [18:05:27] *** Joins: n1s (~n1s@nl118-168-30.student.uu.se) [18:05:27] *** Quits: n1s (~n1s@nl118-168-30.student.uu.se) (Changing host) [18:05:27] *** Joins: n1s (~n1s@rockbox/developer/n1s) [19:38:39] [7]: looks like it's stuck on Generating BBT [19:52:47] at least i have a memdump [19:54:28] *PANIC* [19:54:28] Failed to generate BBT: Need to remap across too high distance! [19:54:33] ah, there you are [19:55:39] console: http://pastie.org/pastes/8263206/text [19:56:09] threads: http://pastie.org/pastes/8263209/text [19:58:54] tlsfanalyze of the memdump: http://pastie.org/pastes/8263214/text [20:01:37] and the memdump: https://mega.co.nz/#!V9RmyRYS!asbiFXfQQDXY4YYem2IjBzJz4u4rthNwg64G4LFH3GE [20:03:58] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) [20:03:58] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection) [22:16:10] <[7]> user890104: yes, that's what I had feared given the huge amount of bad sectors towards the end [22:16:41] [7]: what should i do next then? [22:16:57] <[7]> wow, I didn't even remember that it logs that detailed info to the USB console [22:18:39] generating a BBT from the memdump should be possible, right? [22:19:05] <[7]> that's an interesting question [22:19:39] or should i rerun the app, with patched memory? [22:19:46] <[7]> won't help [22:19:51] <[7]> we have a fundamental problem here [22:20:20] this looks like state[]: 0801A6E8: 01BF2978+8 bytes owned by 0801A660 (Thread: HDD scanner) [22:20:29] <[7]> yes [22:21:31] can i run the app, then overwrite the array, locate the current sector pointer, and change it to the last one, so it skips scanning and generates a BBT from state[] ? [22:22:32] <[7]> well it apparently can't generate a BBT from this state array [22:22:49] <[7]> because there's a *huge* block of bad sectors somewhere [22:23:12] <[7]> depending on where it is, it might be easiest to just trim the drive at the end [22:27:42] <[7]> what does diagmode say now btw? [22:28:55] <[7]> also... can you re-run hddscan2, just across the first few sectors? [22:29:05] <[7]> just to check if absolutely *every* sector is bad now? [22:30:48] <[7]> it's kinda weird that it seems to have 2761MiB of consecutive bad sectors at the end [22:33:06] well, we can trim that if it's needed [22:33:47] <[7]> writes failing immediately is fishy [22:34:04] <[7]> I'm not sure if that damage is actually present or if we had just screwed up the drive firmware somehow [22:34:23] * user890104 reruns hddscan2 [22:34:45] <[7]> can you pipe the debug console into a file this time? [22:34:55] yeah, sure [22:34:56] <[7]> just to get a better idea of how that drive behaves [22:35:12] i just need to run that thing, it seems that emcore's umsboot can't run it [22:35:27] so i'll use dfu+itunesdfu [22:35:36] which worked last time [22:35:47] <[7]> hm... I think I just ran it through emcore.py runfirmware [22:41:01] http://pastie.org/pastes/8263594/text [22:41:35] should i keep it running, or we can trick it somehow? [22:44:02] <[7]> hm, looks like we have new damage now? [22:44:07] <[7]> did you check diagmode in between? [22:44:26] no [22:44:54] PASS 22 WRITE 47347 RC 80000007 TIME 211589 [22:45:11] <[7]> PASS 0 WRITE 1 RC 80000003 TIME 521522 worries me [22:45:28] what do these mean? can you explain it? [22:45:58] <[7]> it means that the second sector if the disk is bad now [22:46:21] <[7]> (failed writing, and took 500ms to do so) [22:46:36] <[7]> hm, or wait... [22:48:41] <[7]> given the nasty firmware behavior it could be either sector 0 or 1 [22:48:57] <[7]> anyway, these errors weren't there during the first run [22:49:04] <[7]> so somehow the damage has spread [22:49:13] <[7]> could be that the heads have been damaged [22:53:12] * user890104 restores so he can run diagmode [22:55:34] retracts: 122 reallocs: 569 pending: 61 poweron: 323 hrs start/stops: 137 curr temp: 33C min: 18C max: 48C [22:57:00] <[7]> hm, that might need some scrubbing [22:57:10] <[7]> and you don't need to restore to run diagmode [22:58:34] <[7]> can you just boot the OF, diskmode, rockbox or whatever and dd /dev/zero to the drive (will take a few hours and might possibly fail because of I/O errors) [22:58:56] <[7]> if you do that aggressively enough the "pending" value should go back down to zero [23:01:23] any equivalent of dd /dev/zero on windows? [23:02:24] [22:57:13] <[7]> and you don't need to restore to run diagmode << how do i do it then? [23:03:00] restoring using ipoddfu + ipodscsi is fun, that's why i did it that way :) [23:06:25] i don't want to use my linux vm, because virtualbox's usb driver is most likely going to crash my OS (again) [23:30:15] <[7]> user890104: winhex could do it [23:30:37] <[7]> f9, select drive, ctrl+l [23:50:13] http://i.imgur.com/xtSHqj2.png