| 00:00:42 | | Join T44 [0] (~Topy44@89.204.137.203) |
| 00:01:03 | | Join pamaury_ [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net) |
| 00:01:23 | | Join Unhelpful_ [0] (~quassel@rockbox/developer/Unhelpful) |
| 00:01:41 | | Join Robdgreat_ [0] (~rob@1606inc.com) |
| 00:02:27 | kugel | thomasjfox: I'm assuming the shutdown code works for you? |
| 00:02:46 | | Join linuxstb_ [0] (~linuxstb@23.230.19.95.dynamic.jazztel.es) |
| 00:02:46 | | Quit linuxstb_ (Changing host) |
| 00:02:46 | | Join linuxstb_ [0] (~linuxstb@rockbox/developer/linuxstb) |
| 00:02:56 | | Quit sideral (Remote host closed the connection) |
| 00:03:08 | thomasjfox | kugel: Oh yes, I really tortured it. 25 shutdowns with sigaltstack and 25 with SDL threads. |
| 00:03:29 | thomasjfox | kugel: Thanks for fixing it :) |
| 00:03:30 | | Join sideral [0] (~sideral@213.165.85.248) |
| 00:03:30 | | Quit sideral (Changing host) |
| 00:03:30 | | Join sideral [0] (~sideral@rockbox/developer/sideral) |
| 00:04:08 | | Join viv [0] (~slayer@cpc5-king10-2-0-cust73.perr.cable.virginmedia.com) |
| 00:04:28 | | Join n17ikh| [0] (~n17ikh@c-68-59-25-51.hsd1.sc.comcast.net) |
| 00:04:46 | | Part viv |
| 00:05:06 | CIA-70 | New commit by thomasjfox (r29467): Move sleep timer code outside of PLATFORM_NATIVE ifdef so RaaA can access it ... |
| 00:05:10 | pamaury_ | sideral: hello, I tried to see which files were left open on usb mount and could only get the currently playing file... |
| 00:05:52 | sideral | pamaury: I always get at least one more file: a font file |
| 00:06:32 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 00:06:41 | pamaury_ | actually, I wrote some code to print the file names and except if I did a mistake, the font file is never left open |
| 00:06:51 | sideral | And sometimes a third, which I haven't identified yet −− I guess it could be a DB-related file during DB update |
| 00:07:21 | sideral | maybe the font file is specific to my theme? |
| 00:07:21 | | Join crwll [0] (~crwlll@dsl-jklbrasgw1-fe8edf00-29.dhcp.inet.fi) |
| 00:07:21 | pamaury_ | I can provide you with the code do log the file names, if it helps identifying them |
| 00:07:33 | pamaury_ | perhaps, I know nothing about fonts |
| 00:07:33 | sideral | pamaury: Yes, that would be nice |
| 00:07:56 | | Quit froggyman_ (*.net *.split) |
| 00:07:56 | | Quit Keripo1 (*.net *.split) |
| 00:07:57 | | Quit pamaury (*.net *.split) |
| 00:07:57 | | Quit tchan (*.net *.split) |
| 00:07:57 | | Quit domonoky (*.net *.split) |
| 00:07:57 | | Quit Topy44 (*.net *.split) |
| 00:07:57 | | Quit robin0800 (*.net *.split) |
| 00:07:58 | | Quit Unhelpful (*.net *.split) |
| 00:07:59 | | Quit MagusG (*.net *.split) |
| 00:07:59 | | Quit ehntoo (*.net *.split) |
| 00:07:59 | | Quit YPSY (*.net *.split) |
| 00:08:00 | | Quit linuxstb (*.net *.split) |
| 00:08:00 | | Quit ender| (*.net *.split) |
| 00:08:01 | | Quit crwl (*.net *.split) |
| 00:08:02 | | Quit n17ikh (*.net *.split) |
| 00:08:02 | | Quit Robdgreat (*.net *.split) |
| 00:08:02 | | Nick n17ikh| is now known as n17ikh (~n17ikh@c-68-59-25-51.hsd1.sc.comcast.net) |
| 00:08:33 | | Join MagusG [0] (magusg@c-71-59-57-46.hsd1.ga.comcast.net) |
| 00:08:35 | kugel | sideral: that worked, cool |
| 00:09:09 | pamaury_ | sideral: http://pastebin.com/mkUE6Hhv, you need to disable dircache and enable logf |
| 00:09:26 | sideral | kugel: Great to hear! Now the two of us can commit to the 3.8.1 branch like crazy :) |
| 00:09:37 | CIA-70 | r29467 build result: 468 errors, 0 warnings (thomasjfox committed) |
| 00:09:44 | kugel | pamaury_, sideral: I know buffering doesn't close the last file if it's buffered partially. I tried to close it but it introduced noticeable audio glitches |
| 00:09:49 | sideral | Thanks pamaury, I'll apply it to my build and report back |
| 00:09:55 | mshathlonxp | 486 errors :D |
| 00:09:58 | kugel | sideral: AlexP can too :P |
| 00:10:06 | thomasjfox | still no high score :( |
| 00:10:25 | *** | Saving seen data "./dancer.seen" |
| 00:10:32 | AlexP | There is no 3.8.1 branch :) |
| 00:10:46 | kugel | you need to seriously break some often included header to get a high score :) |
| 00:11:13 | | Join saratoga [0] (9803c6dd@gateway/web/freenode/ip.152.3.198.221) |
| 00:11:36 | | Quit linuxguy3 (Ping timeout: 250 seconds) |
| 00:12:54 | | Join ehntoo [0] (~ehntoo@lug.mtu.edu) |
| 00:12:58 | | Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) |
| 00:13:01 | | Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.3-3.cable.virginmedia.com) |
| 00:13:10 | | Quit sideral (Remote host closed the connection) |
| 00:13:20 | | Join froggyman_ [0] (~seth@98.115.0.7) |
| 00:13:27 | | Join sideral [0] (~sideral@213.165.85.248) |
| 00:13:27 | | Quit sideral (Changing host) |
| 00:13:27 | | Join sideral [0] (~sideral@rockbox/developer/sideral) |
| 00:13:31 | sideral | AlexP: Is there not? |
| 00:13:32 | kugel | TheSeven: your fat commits created some warnings in the android build |
| 00:13:37 | | Join linuxguy3 [0] (~timj@adsl-75-57-176-108.dsl.emhril.sbcglobal.net) |
| 00:13:47 | TheSeven | kugel: hm? what kind of warnings? |
| 00:13:51 | TheSeven | can you paste them? |
| 00:13:55 | AlexP | sideral: No, just 3.8 |
| 00:14:02 | kugel | swap16/32 redefined |
| 00:14:07 | | Join Ypsy [0] (~ypsy@geekpadawan.de) |
| 00:14:15 | | Nick Ypsy is now known as YPSY (~ypsy@geekpadawan.de) |
| 00:14:15 | AlexP | sideral: Any backports will normally go in 3.8, then a 3.8.1 will be tagged |
| 00:14:22 | * | TheSeven hasn't touched that |
| 00:14:23 | CIA-70 | New commit by thomasjfox (r29468): Fix red |
| 00:14:28 | sideral | AlexP: I see |
| 00:14:53 | thomasjfox | ha, commit 29-468 fixes 468 build errors |
| 00:15:21 | | Join Keripo [0] (~Keripo@eng103.wireless-resnet.upenn.edu) |
| 00:15:33 | sideral | BTW, I cannot play back m4a files in my trunk-based build any more −− hope that's cause by post-branch changes |
| 00:15:42 | sideral | perhaps jhMikeS' buffering changes |
| 00:15:57 | sideral | s/cause/caused/ |
| 00:15:58 | stripwax | I'm sortof following FS #11863 ... is that a bug in 3.8 or just svn? |
| 00:16:57 | kugel | thomasjfox: heh, nice one |
| 00:17:16 | [Saint] | kugel: The touch area "menu" goes to the WPS if there's music playing now? |
| 00:17:23 | sideral | stripwax: Both, AFAIK. Some fixes went into 3.8 already, and some were made after the branch |
| 00:17:41 | kugel | [Saint]: does it? |
| 00:17:43 | [Saint] | Or, did it always used to do that....? |
| 00:17:54 | [Saint] | it does, yes. |
| 00:18:02 | [Saint] | I swear this is a new thing ;) |
| 00:18:10 | kugel | if it does what the menu button does, it goes to the main menu and back to where you come from (if you press it in the main menu) |
| 00:18:26 | kugel | I suspect it always did |
| 00:18:39 | CIA-70 | r29468 build result: 1 errors, 0 warnings (thomasjfox committed) |
| 00:19:06 | [Saint] | Hmmm, I have only just noticed this...it's quite convenient. |
| 00:19:06 | | Nick Robdgreat_ is now known as Robdgreat (~rob@1606inc.com) |
| 00:19:12 | | Quit Robdgreat (Changing host) |
| 00:19:12 | | Join Robdgreat [0] (~rob@unaffiliated/robdgreat) |
| 00:19:21 | kugel | TheSeven: http://pastie.org/1618722 |
| 00:19:43 | thomasjfox | kugel: Your build host is fscked up :o) |
| 00:19:57 | stripwax | sideral - (or maybe MikeS or Buschel) - and the bit that's unfixed is vorbis-specific only? |
| 00:19:57 | thomasjfox | home/kugel/compilers/bin//m68k-elf-ar: /home/kugel/rockbox-client/builds/build-mpiohd200/apps/codecs/lib/ffmpeg_bitstream.o: No such file or directory |
| 00:20:45 | sideral | stripwax: I haven't been following these changes that closely, sorry |
| 00:20:46 | * | [Saint] wonders how hard it would be to add kinetic scrolling to pictureflow. |
| 00:20:59 | [Saint] | It looks *really* nice on RaaA btw |
| 00:21:02 | kugel | thomasjfox: nah, that's just a superflous / in $PATH (I hope so anyway) |
| 00:21:02 | [Saint] | \o/ |
| 00:21:25 | * | stripwax should try 3.8 and see if it's more stable than svn |
| 00:21:28 | thomasjfox | kugel: does the build run a parallel build? |
| 00:21:53 | thomasjfox | kugel: see http://build.rockbox.org/shownewlog.cgi?rev=29468;type=mpiohd200 |
| 00:21:56 | kugel | with -j9 |
| 00:21:56 | TheSeven | kugel: sounds like the one in /home/kugel/rbdev/rockbox-git/firmware/export/system.h should ne #ifndef'ed |
| 00:22:03 | thomasjfox | looks like a typical parallel make problem |
| 00:23:16 | [Saint] | kugel: Is there a reason that Hotkey isn't defined for any application builds? |
| 00:25:07 | kugel | I don't think so |
| 00:25:37 | JdGordon | hotkey should be automatically enabled for touchscreen in config.h |
| 00:25:38 | kugel | I quite possibly copy&pasted <target>.h from the wrong one :p |
| 00:26:01 | [Saint] | right...well, it'd be cool if it were enabled. |
| 00:26:17 | [Saint] | (I don't mean that to sound demanding) |
| 00:28:56 | thomasjfox | kugel: Is there a way to retrigger a build? I'll take it that I can ignore the failure on the build host |
| 00:29:34 | | Join jhMikeS [0] (~jethead71@adsl-99-36-9-193.dsl.sfldmi.sbcglobal.net) |
| 00:29:34 | | Quit jhMikeS (Changing host) |
| 00:29:34 | | Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) |
| 00:30:09 | kugel | thomasjfox: just ignore it |
| 00:30:38 | thomasjfox | kugel: Ok. I'm just surprised it didn't see something like this pop up before |
| 00:31:42 | | Quit mshathlonxp (Quit: fall into sleep) |
| 00:32:42 | * | thomasjfox definately needs more sleep and the sleep timer isn't working for RaaA yet |
| 00:34:27 | stripwax | data abort at 0004e860 with 3.8 . that's after database autoupdate has finally completed to 100% (although playback paused). is that the same symptom as fs#11863? (i find it hard to tell) |
| 00:37:46 | sideral | stripwax: Don't think so |
| 00:37:49 | stripwax | maybe it's unrelated. |
| 00:39:05 | sideral | stripwax: If it's reproducible with a release build, please report it to the bug tracker |
| 00:39:26 | sideral | (with the steps / data that reproduce it) |
| 00:39:43 | | Quit ender` (Quit: Consultation, n. Medical term meaning "to share the wealth.") |
| 00:40:01 | stripwax | sideral - yep, will see if it's reproducible. data aborts due to database update/initialize seem hard to get good reusable test cases for |
| 00:40:34 | stripwax | i'll try deleting + reinitalising database first |
| 00:41:21 | sideral | What version generated the old database? |
| 00:41:54 | stripwax | sideral - some post 3.7 svn build, but i wouldn't know the exact build unfortunately |
| 00:42:01 | | Quit linuxguy3 (Read error: Operation timed out) |
| 00:42:15 | sideral | There has been a DB schema change since 3.7. Possibly the logic that checks for database incompatibility is broken. |
| 00:45:23 | sideral | thomasjfox: Is the last commit considered OK despite the build error? |
| 00:45:24 | | Join linuxguy3 [0] (~timj@76.202.211.225) |
| 00:45:31 | thomasjfox | sideral: yes |
| 00:45:45 | sideral | OK, thanks |
| 00:47:16 | CIA-70 | New commit by sideral (r29469): DB import: Correctly import previously exported resume offsets |
| 00:48:40 | thomasjfox | kugel: After testing on my host, I think the SDL audio backends needs some work. It also clicks on every seek / touchscreen activity |
| 00:49:00 | kugel | on a pc? |
| 00:49:16 | stripwax | sideral - hrm, database abort at 0004ee74, on a Initialise Now with 3.8. |
| 00:49:22 | thomasjfox | kugel: yes |
| 00:49:33 | thomasjfox | kugel: x86_64 Fedora 14 box |
| 00:49:51 | stripwax | although i just saw your above commit. reckon i should try svn latest? |
| 00:50:26 | sideral | stripwax: Could also be a metadata parsing problem. Can you enable metadata logging in the debug menu prior to initializing the database? |
| 00:50:32 | stripwax | i do have an exported database, which presumably gets imported as the final step of database initialise? (it appears to dara abort only right at the very end) |
| 00:50:45 | stripwax | will do. with 3.8; or with svn latest? |
| 00:51:06 | CIA-70 | r29469 build result: All green |
| 00:51:14 | sideral | stripwax: I believe the import of the exported data is done only when requested explicitly / manually |
| 00:51:42 | sideral | My commit is not related to DB init, only to DB import |
| 00:51:58 | kugel | Torne: do you know what's the deal with the ipod video 64mb ata hack? |
| 00:51:58 | sideral | stripwax: with 3.8, please |
| 00:52:22 | TheSeven | kugel: which one of the hacks? |
| 00:52:29 | Torne | not really. it's, er, to make the physical sector thing work. |
| 00:52:32 | kugel | ata_lock |
| 00:52:43 | kugel | especially why it can't use a standard mutex |
| 00:52:44 | Torne | i'm not sure what the problem is with using a regular lock though |
| 00:52:48 | sideral | stripwax: Also / alternatively, you could try DB import of your old export instead of DB init |
| 00:52:51 | Torne | obviously it needs a mutex |
| 00:52:58 | Torne | but i'm not sure why it uses that weird hacky implementation |
| 00:53:03 | TheSeven | multicore? |
| 00:53:04 | Torne | or how that one even works |
| 00:53:39 | kugel | TheSeven: standard mutex also has a corelock |
| 00:53:58 | stripwax | sideral - i thought the DB import would just merge in the modifications (play counts, ratings, etc) into the database? |
| 00:54:13 | stripwax | anyway, reiniting db now with metadata cache enabled. |
| 00:54:44 | stripwax | fyi dircache is on, load to ram is true, and there is an existing database (presumably loaded to ram at this point) |
| 00:55:19 | kugel | I can't seem to spot why it needs a separate mutex implementation |
| 00:55:19 | sideral | stripwax: I'm not sure. I've only ever used DB export/import as a backup mechanism, not for merging DB data |
| 00:55:46 | Torne | kugel: well someone tried taking it out and it doesn't work :) |
| 00:55:47 | Torne | iirc |
| 00:56:02 | kugel | it seems to work really the same |
| 00:56:15 | TheSeven | kugel: at the first glance it looks to me as if it is actually some kind of more lightweight mutex that isn't IRQ-safe |
| 00:56:21 | Torne | oh? maybe i'm not remembering right |
| 00:56:31 | Torne | i thought someone found it broke stuff to not use it |
| 00:56:41 | kugel | if the thread has the lock, then count up and return, otherwise get the corelock and lock the current thread until the mutex is released by the owner |
| 00:56:53 | kugel | between switch_thread()s the corelock is released |
| 00:57:18 | kugel | yes, it doesn't disable irqs, is that the reason? |
| 00:57:37 | TheSeven | this might have something to do with thread blocking behavior as well |
| 00:57:43 | CIA-70 | New commit by sideral (r29470): autoresume: Optimize playlist resume (manual, bookmark, or after power-on) ... |
| 00:57:56 | TheSeven | this one more or less polls for the lock, while mutexes probably do some more sophisticated blocking |
| 00:58:28 | kugel | it doesn't block (as in ask the scheduler to block it) the thread, but it busy loops for the lock to get free |
| 00:58:36 | kugel | so it's much more like the spin lock, isn't it? |
| 00:58:38 | | Quit thomasjfox (Remote host closed the connection) |
| 00:59:13 | TheSeven | yeah, it looks like a latency-optimized lightweight mutex to me |
| 00:59:13 | kugel | if so we should instead call it spin lock and move it to the other kernel primitives |
| 00:59:49 | kugel | but why does the bigger ipod video have the lightweight one, while the others use normal mutexes? |
| 01:00 |
| 01:01:39 | CIA-70 | r29470 build result: All green |
| 01:01:42 | | Quit Jerom (Quit: Leaving.) |
| 01:02:56 | sideral | stripwax: Please be sure to post your results. You'll find your metadata-access log in /metadata.log. I need to go offline now. |
| 01:03:10 | stripwax | sideral - will do. thanks |
| 01:03:36 | stripwax | i'm guessing metadata.log is sync'd while building db - |
| 01:03:48 | sideral | Yes it is. Is it slow? :) |
| 01:03:58 | stripwax | so it contains the last metadata at the point of the data abort (when it gets there)? |
| 01:04:05 | sideral | yep |
| 01:04:20 | stripwax | should i post just the last part of the metadata.log then, or all of it? |
| 01:05:13 | sideral | Just the last file name, along with the file if possible |
| 01:05:16 | TheSeven | hm, looking at the places where it is used, I really don't understand what the matter is with a regular one |
| 01:05:17 | kugel | mutexes aren't interrupt safe anyway, I wonder why they deal with them |
| 01:05:40 | TheSeven | kugel: not interrupt safe in terms of you may not use them in IRQ handlers |
| 01:05:40 | sideral | stripwax: Thanks for helping debug this! |
| 01:05:54 | | Join DJeXeCute [0] (DJeXeCute@ip68-105-199-134.cl.ri.cox.net) |
| 01:05:56 | sideral | Bye |
| 01:05:56 | stripwax | thank you! |
| 01:06:00 | DJeXeCute | Hello |
| 01:06:07 | DJeXeCute | I have a question |
| 01:06:35 | TheSeven | and as we have a cooperative multitasking kernel, I don't see why they would need to care about IRQs on singlecore systems |
| 01:07:08 | | Quit sideral (Quit: Leaving.) |
| 01:07:13 | TheSeven | DJeXeCute: well, seems like my crystal ball is broken, it failed to guess what your question is :) |
| 01:07:17 | DJeXeCute | Bolth my Onboard and my USB soundcard are fried. I was woundering if I could somehow use my Ipod Mini 1st gen as a USB soundcard? |
| 01:07:22 | kugel | TheSeven: exactly |
| 01:07:28 | kugel | dealing with corelocks should be sufficient |
| 01:07:31 | | Quit pamaury_ (Remote host closed the connection) |
| 01:07:54 | kugel | the normal mutex disables IRQ before switch_thread(), but I can't see how |
| 01:07:58 | TheSeven | DJeXeCute: in theory that might be possible. someone worked on that some time ago, but i don't think it ever got far enough to be really usable |
| 01:08:02 | kugel | I mean why it's needed |
| 01:08:12 | kugel | jhMikeS: ? |
| 01:08:15 | DJeXeCute | Oh:/ |
| 01:08:25 | TheSeven | kugel: maybe it's acutally switch_thread that needs this? |
| 01:08:55 | kugel | enabling IRQ is the first thing switch_thread() does |
| 01:09:06 | TheSeven | that seems to be pretty much pointless then :) |
| 01:09:27 | kugel | oops no |
| 01:09:31 | | Quit liar (Ping timeout: 240 seconds) |
| 01:10:55 | kugel | it disables irq itself rather early, and not all callers of switch_thread() disable irq so I still don't see the point |
| 01:11:35 | kugel | the mutex has the advantage that threads blocked on the mutex are unblocked in order, so they should be better latency wise |
| 01:12:22 | kugel | with that spin lock it's random which thread is unlocked first, and high proprity threads might get penalties because of over yielding |
| 01:12:53 | jhMikeS | kugel: ?? |
| 01:13:57 | kugel | jhMikeS: do you know why ata.c has this custom mutex implementation? and why mutex_lock disables irqs? |
| 01:14:35 | DJeXeCute | http://www.rockbox.org/tracker/task/11108?string=USB+Soundcard&project=1&type[0]=&sev[0]=&pri[0]=&due[0]=&reported[0]=&cat[0]=&status[0]=open&percent[0]=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto= Is that the project Id be looking for to use my ipod as a usb soundcard? |
| 01:15:04 | jhMikeS | 1) yes, because there is an odd problem with iPod video that's yet to be tracked down 2) all scheduling disables IRQs because of interaction with interrupt wakeups |
| 01:15:32 | stripwax | sideral - for the logs - how annoying, it now seems to be aborting while committing database |
| 01:15:44 | | Quit mudd1 (Read error: Operation timed out) |
| 01:16:10 | kugel | jhMikeS: I can understand that for event_queues but not for a mutex |
| 01:16:34 | stripwax | but it sortof seemed ok right up until the moment I enabled Auto Update = Yes and rebooted. I got a data abort right after the reboot, then on a subsequent reboot I got a data abort at committing database step 4/9 (reproducibly). |
| 01:17:02 | jhMikeS | kugel: yes, for a mutex when sleeping because of interaction with the run lists and other parts |
| 01:17:49 | jhMikeS | also, intaction of corelocks and interrupts on > 1 core |
| 01:18:35 | jhMikeS | one can't look at one function and infer because it's not called in ISR context or use by them that the disable is unimportant since things connect more broadly |
| 01:18:41 | kugel | corelock should take care of multi issues, no? |
| 01:19:17 | jhMikeS | no, you don't want a corelock that is locked by one core to deadlock on itself if an ISR on that same core happens to try to claim it |
| 01:19:40 | kugel | IMO block_thread() and friends should disable irqs, not their callers in kernel.c |
| 01:20:30 | | Quit DerPapst (Quit: Leaving.) |
| 01:20:38 | jhMikeS | then we'd be doing alot more disables/enables |
| 01:20:41 | kugel | if a mutex is locked from an isr things go wild anyway |
| 01:21:48 | jhMikeS | true, but things are woken from an ISR, things that locking a mutex also touches. the connections are farther down |
| 01:23:33 | kugel | jhMikeS: do you happen to know why this custom mutex is used on a 64mb ipod? I'd expect it's used on all, or a standard mutex is used on all |
| 01:24:00 | kugel | I can't see a difference from normal mutexes except that it doesn't disable irq and busy waits for the lock to get free |
| 01:26:01 | | Quit robin0800 (Quit: Leaving) |
| 01:26:02 | kugel | your commit message is a bit unclear to me |
| 01:27:55 | DJeXeCute | Can someone please help me I found the project for using the ipod as a USB Soundcard but need assistance in getting it set up? |
| 01:28:07 | * | TheSeven wonders if mpegplayer can take advantage of LCD DMA |
| 01:28:16 | jhMikeS | kugel: because 80MB ipod video had a problem with the UI becoming unresponsive that the object hack seemed to alleviate. I suspect its to do with sleeping the core at a particular time but I'm not sure _why_ it's effective. |
| 01:29:22 | stripwax | 80GB rather than 80MB? (i.e. large physical sector size) |
| 01:29:24 | jhMikeS | kugel: yeah, it's not different from normal other than it doesn't do true blocking and doesn't invoke prio inheritance |
| 01:29:48 | kugel | it also doesn't disable irqs |
| 01:30:38 | jhMikeS | the yield will of course but it doesn't alter the contents of the run list so it doesn't do it there |
| 01:30:38 | TheSeven | so it basically prevents the core it's running on from sleeping |
| 01:30:42 | kugel | does the ipod video use dma or so for lcd updates? |
| 01:30:53 | kugel | perhaps the standard mutex makes irqs disabled for too |
| 01:30:54 | kugel | long |
| 01:31:05 | TheSeven | maybe this is to alleviate a similar problem like the one I just had with ce-ata where latencies while waiting for something were way too long |
| 01:31:30 | jhMikeS | they shouldn't be disabled for more than a microsecond, no |
| 01:31:42 | TheSeven | what about the following |
| 01:31:48 | TheSeven | -storage can be accessed from both cores |
| 01:32:11 | DJeXeCute | Thanks for the help everyone bye:P |
| 01:32:13 | | Quit DJeXeCute () |
| 01:32:34 | TheSeven | -if both cores access it, it's likely that control of the lock alternates between them very often |
| 01:32:44 | jhMikeS | TheSeven: on PP I wouldn't do that, but that because of lack of cache coherency |
| 01:33:00 | TheSeven | -if the waiting core is sleeping, it might be possible that it will only wake up on the next tick |
| 01:33:26 | jhMikeS | it won't sleep if waiting for a spinlock |
| 01:33:50 | jhMikeS | how could it? there's a thread running |
| 01:33:51 | TheSeven | it won't sleep if it's waiting for a corelock or that ata lock, but it will sleep if it's waiting for a mutex, right? |
| 01:34:10 | TheSeven | (if the mutex is locked on the other core) |
| 01:34:10 | jhMikeS | interrupt will be enabled immediately upon waking it though |
| 01:34:26 | TheSeven | how are cores woken up on PP? |
| 01:34:30 | jhMikeS | the other core explicitly wakes the other when it unblocks one of its threads |
| 01:35:06 | kugel | jhMikeS: if this one doesn't deal with sleeping and priority inheritance I can imagine it works better in some situations. shouldn't we move it into kernel.c as spin lock? |
| 01:35:10 | jhMikeS | thread-pp.c, by setting the processor control registers to wake up the other core |
| 01:35:10 | TheSeven | so it can actively wake it, and doesn't need to wait for some tick or something similar? |
| 01:36:01 | jhMikeS | no, nothing waits for ticks. if a thread is made runnable, the core is always immediatly woken and any interrupt races between ISR serving and going back to sleep are also avoided |
| 01:36:28 | TheSeven | heck, how can mpegplayer get more fps than test_fps? :) |
| 01:37:17 | jhMikeS | two cores sending and acking messages to each other through a queue on PP takes ~12 microseconds |
| 01:37:20 | | Join krazykit [0] (~krazykit@99-126-205-52.lightspeed.cicril.sbcglobal.net) |
| 01:37:53 | TheSeven | ah, boosting :/ |
| 01:38:03 | TheSeven | linuxstb_: still around? |
| 01:38:08 | jhMikeS | boosting? |
| 01:38:19 | TheSeven | jhMikeS: 01:36] <TheSeven> heck, how can mpegplayer get more fps than test_fps? :) |
| 01:38:30 | jhMikeS | does it? :) |
| 01:38:39 | TheSeven | yes, if mpegplayer boosts and test_fps doesn't |
| 01:38:51 | jhMikeS | ah, ok :) |
| 01:38:56 | kugel | I also find it suspicious that it works better for the 64mb ipod only. I strongly suspect it works better on all (assuming it works indeed better) |
| 01:39:06 | * | TheSeven wonders if LCD DMA pays off if the frame rate in test_fps drops from ~42 to ~27fps when activating it |
| 01:39:27 | kugel | anyway, IIRC all ipod video builds are 64MB with MAX_PHYS_SECTOR_SIZE enabled, IIUC |
| 01:39:41 | jhMikeS | kugel: I think only the 64MB also had the 80MB drive. I know the 30MB is ok with the regular mutex |
| 01:39:58 | kugel | the builds are unified now |
| 01:40:00 | jhMikeS | iirc it wasn't always so |
| 01:40:02 | jhMikeS | right |
| 01:40:26 | gevaerts | jhMikeS: except IIRC some refurbished players have random boards basically |
| 01:40:36 | jhMikeS | gigabeat S uses ATA DMA and not the hacky object |
| 01:41:28 | kugel | well, it's possibly not hacky. spinlocks are a generally accepted barrier |
| 01:41:50 | jhMikeS | gevaerts: interesting. this all started years ago and the only thing showing symptoms needing the hack was 80MB video. it's got nothing to do with large sector support either. one can enable that on anything and not have a problem with the mutex. |
| 01:42:32 | gevaerts | jhMikeS: I mean, if it's related to the disk, I'm pretty sure people were having problems before the build unification |
| 01:42:55 | jhMikeS | they were indeed |
| 01:45:01 | jhMikeS | kugel: If the 80MB issue gets fixed, I'll delete that stuff from ata.c in a second and clean things back up |
| 01:45:19 | TheSeven | woah |
| 01:45:25 | TheSeven | test_fps is going nuts! |
| 01:45:26 | * | kugel swaps jhMikeS G and M key ;) |
| 01:45:36 | TheSeven | 121864.122888fps RGB full screen |
| 01:45:54 | TheSeven | CPU frequency: -443338684 MHz |
| 01:46:09 | jhMikeS | lol...what's that about? |
| 01:46:22 | kugel | jhMikeS: do you think it's fixed now? effecively that "hack" is active on all ipod video builds now isn't it? |
| 01:47:36 | jhMikeS | kugel: Noone's tested without it to my knowledge lately. I've tried several times and the fs tasks quickly follow for the 80GB users |
| 01:47:42 | * | TheSeven suggests just trying it |
| 01:48:11 | * | kugel has little hope |
| 01:48:33 | TheSeven | drop a few testing builds somewhere and have some volunteers check if something starts acting up |
| 01:48:59 | * | TheSeven wonders who originally wrote that hack, and why |
| 01:49:09 | TheSeven | or rather how it was determined that that thing was needed originally |
| 01:49:12 | jhMikeS | kugel: Jiggabytes it is :) |
| 01:49:42 | iamben | 80MB ipod... you got me excited that it might work on my rio pmp300 (64MB) player |
| 01:49:43 | * | jhMikeS wrote the object hack in ata.c (for the reasons we've been talking about) |
| 01:50:24 | TheSeven | yeah, but how did you determine that this is what was needed to fix the problems? |
| 01:50:49 | | Quit [Saint] (Disconnected by services) |
| 01:50:51 | | Join S_a_i_n_t [0] (S_a_i_n_t@203.184.1.96) |
| 01:50:58 | TheSeven | i mean, if I was hunting for a bug, I wouldn't just try and slap a bunch of mutex re-implementations at it |
| 01:51:24 | kugel | I'd call you crazy if you did :p |
| 01:51:45 | TheSeven | yeah, but what would trigger someone to even suspect that the mutexes might be involved? |
| 01:51:56 | jhMikeS | because of an earlier implementation of something that didn't sleep (before prio inherit) that was used in ata.c. when going back to pure mutex, the problem showed up. I then wrote the hack to immitate what was going on before and the problem mysteriously disappeared again. |
| 01:52:22 | TheSeven | ah, so you basically locally reverted a kernel change for the ata driver... |
| 01:52:26 | jhMikeS | yes |
| 01:52:59 | kugel | so it's the priority inheritance that exposes this behavior? |
| 01:53:09 | jhMikeS | I had a hunch, spit that out, and said, "please try this". |
| 01:53:54 | | Quit stripwax (Quit: http://miranda-im.org) |
| 01:54:06 | kugel | jhMikeS: what do you say to my earlier question? |
| 01:54:20 | jhMikeS | I think it's the possibility of the core sleeping while running ata code on that particular device. I believe I even tried priority disabled entirely without effect. |
| 01:54:51 | jhMikeS | was that one one? |
| 01:55:32 | | Quit S_a_i_n_t (Ping timeout: 264 seconds) |
| 01:55:53 | kugel | "if this one doesn't deal with sleeping and priority inheritance I can imagine it works better in some situations. shouldn't we move it into kernel.c as spin lock |
| 01:56:00 | kugel | "if this one doesn't deal with sleeping and priority inheritance I can imagine it works better in some situations. shouldn't we move it into kernel.c as spin lock |
| 01:56:03 | jhMikeS | I tried alot of crap, threw it at the owners and gave up until somehow I got an 80GB video in my possession to track it down. |
| 01:56:06 | DBUG | Enqueued KICK kugel |
| 01:56:06 | kugel | "if this one doesn't deal with sleeping and priority inheritance I can imagine it works better in some situations. shouldn't we move it into kernel.c as spin lock |
| 01:56:20 | kugel | "if this one doesn't deal with sleeping and priority inheritance I can imagine it works better in some situations. shouldn't we move it into kernel.c as spin lock?" |
| 01:56:26 | kugel | oooooops |
| 01:56:39 | jhMikeS | oh, we did have that in the first place |
| 01:57:25 | jhMikeS | Alot of fast CPU waste cycles if they just spin, esp. with a slow thing like a disk. They could save power instead. |
| 01:57:55 | kugel | it shouldn't replace mutexes, but in certain cases spin locks are the better choice |
| 01:58:01 | TheSeven | ...which brings up last week's argument again... |
| 01:59:26 | jhMikeS | I'm not sure they'll save anything since the scheduler isn't really much overhead and we'll have just another damned object in the kernel (the fewer the better imo) |
| 01:59:56 | | Join [Saint] [0] (S_a_i_n_t@203.184.1.96) |
| 02:00 |
| 02:00:13 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 02:00:13 | * | TheSeven asks for a tick-less high-resolution scheduler once again :) |
| 02:00:31 | TheSeven | this could save us quite a bunch of yielding loops |
| 02:02:00 | jhMikeS | why are the an issue? most of the time threads are asleep anyway unless the codec thread is busy |
| 02:02:09 | jhMikeS | *is there an |
| 02:02:13 | kugel | jhMikeS: obviously it works better in at least one case, and there are quite possibly more |
| 02:02:55 | kugel | and this is in fact a kernel object, whether or not it's in kernel.c. so unless it's removed entirely it should be in kernel.c (perhaps with a HAVE_SPINLOCK_OBJECT) |
| 02:03:38 | jhMikeS | oy, we're going all the way back to 2006/7 ?? :) |
| 02:04:09 | kugel | the cases where you'd consider a spin lock are the cases where it's not likely a second thread enters the critical section anyway (because the critical section is supposed to be short) |
| 02:05:15 | kugel | no we aren't |
| 02:05:30 | jhMikeS | true, but then a mutex doesn't do much either if not contended (quite on purpose) |
| 02:06:36 | | Nick Unhelpful_ is now known as Unhelpful (~quassel@rockbox/developer/Unhelpful) |
| 02:06:55 | kugel | the current mutex is still the better choice in most cases |
| 02:08:38 | | Join DJeXeCute [0] (DJeXeCute@ip68-105-199-134.cl.ri.cox.net) |
| 02:08:40 | DJeXeCute | Hello |
| 02:08:51 | kugel | jhMikeS: but if it's contended it does a lot more |
| 02:08:52 | jhMikeS | kugel: a disk access sure isn't a short cs though :) |
| 02:09:25 | kugel | right. that confuses me also. why is that spinlock working better in this situation? |
| 02:10:03 | jhMikeS | kugel: obscure hardware issue I think since it's unique to one setup |
| 02:10:15 | DJeXeCute | Can someone point me in the right direction for making changes like adding the Ipod USB Soundcard project to my ipod mini 1st gen? |
| 02:10:26 | *** | Saving seen data "./dancer.seen" |
| 02:10:37 | DJeXeCute | I already found the project and gitpulled the branch |
| 02:11:08 | jhMikeS | kugel: of course storage priority might have changed the game a bit |
| 02:12:22 | kugel | ah right, so disabling could be worth a try |
| 02:12:45 | * | jhMikeS is up for it |
| 02:14:37 | kugel | but I maintain that if it's not removed entirely it should be in kernel.c |
| 02:15:00 | DJeXeCute | :/ i give up |
| 02:15:02 | | Quit DJeXeCute () |
| 02:19:14 | TheSeven | kugel: if you do that, you'll need to make it singlecore aware |
| 02:19:23 | TheSeven | => more ifdef hell |
| 02:19:42 | jhMikeS | kugel: I wanted to discourage its growing tendrils into everything, making dumping it harder if the reason for its existence goes away. |
| 02:20:12 | kugel | TheSeven: core_lock/unlock is stubbed for single core |
| 02:21:16 | jhMikeS | that wakeup object is now everywhere when I could have just extended semaphores properly and made them ISR compatible |
| 02:21:50 | * | jhMikeS does have a patch for that too |
| 02:23:41 | kugel | jhMikeS: it's not everywhere. only few targets use it |
| 02:24:32 | | Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) |
| 02:25:12 | kugel | isn't it just the potential thread_switch() that makes semaphore_release isr incompatible? |
| 02:25:14 | | Quit evilnick_B (Quit: Page closed) |
| 02:27:04 | jhMikeS | kugel: that and it doesn't disable them when claiming the object. for some situations semaphore_wait_w_tmo is also needed (already did it though). they are a bit bigger per object and it's a little bit more code, but not much. |
| 02:28:30 | kugel | wakeup_wait has more code than semaphore_wait |
| 02:29:02 | jhMikeS | but it does both timeout and infinite blocks |
| 02:30:17 | kugel | anyway, go for isr safe semaphores! :) |
| 02:30:29 | kugel | I already wondered why they can't be used |
| 02:30:33 | jhMikeS | the experimental patch: http://pastebin.com/tvT7juBY (not sure it would apply now) |
| 02:31:05 | CIA-70 | New commit by gevaerts (r29471): Recalibrate build costs |
| 02:31:18 | jhMikeS | kugel: because things took a strange turn :) |
| 02:31:21 | * | TheSeven wwonders how irq-safe mutexes or semaphores are supposed to work |
| 02:31:50 | JdGordon | dont they disable the irq when you get a lock that needs to worry about that? |
| 02:31:59 | jhMikeS | the IRQ can up the sem, not down it |
| 02:32:32 | jhMikeS | It can also poll it with a timeout of zero |
| 02:32:44 | CIA-70 | New commit by gevaerts (r29472): Add sdl application to the build system |
| 02:33:27 | | Quit dfkt (Read error: Connection reset by peer) |
| 02:34:51 | kugel | semaphore_try_wait()= |
| 02:34:54 | kugel | ? |
| 02:36:58 | jhMikeS | or semaphore_wait_w_timeout(&sem, 0) (same thing) |
| 02:37:24 | kugel | but the semaphores lose the ability to switch the thread if a higher prio one was waiting on it, that's a bit sad isn't it? |
| 02:37:35 | jhMikeS | so yeah, ISR can poll it down but won't block |
| 02:37:58 | jhMikeS | The patch should have a solution by not doing it if IRQ is disabled already |
| 02:39:04 | kugel | ah nice |
| 02:40:35 | kugel | is that safe? |
| 02:41:00 | * | kugel doesn't know |
| 02:41:03 | jhMikeS | for ARM it is, sine IRQ is always disabled by the core |
| 02:41:27 | jhMikeS | older arm anyway, not the newer stacked IRQ stuff |
| 02:41:40 | kugel | that's not easy on RaaA I'm afraid |
| 02:42:53 | kugel | but on RaaA you can check whether you're in an "irq" or not (pthread_self() == main_thread) |
| 02:43:54 | jhMikeS | the detect should be a target implementation I expect |
| 02:45:19 | kugel | or perhaps just an semaphore_release_from_irq()? |
| 02:45:30 | jhMikeS | on coldfire the sr should have the current ISR priority, which doesn't match the fully-enabled value |
| 02:45:56 | | Quit linuxguy3 (Ping timeout: 264 seconds) |
| 02:45:56 | | Quit T44 (Ping timeout: 264 seconds) |
| 02:46:13 | jhMikeS | yes, I had considered that as well |
| 02:47:35 | | Join linuxguy3 [0] (~timj@adsl-75-57-168-1.dsl.emhril.sbcglobal.net) |
| 02:47:51 | kugel | the (pthread_self() == main_thread) doesnt work with sdl threads |
| 02:48:30 | jhMikeS | isn't there a current thread id function on SDL? |
| 02:48:57 | jhMikeS | or just the current thread pointer? |
| 02:50:00 | kugel | the rockbox threads just sdl threads as well as the isrs |
| 02:50:03 | jhMikeS | iirc, one problem I had was having a pointer for the main thread since it was never created through SDL in the first place. |
| 02:50:21 | kugel | you can get it with pthread_self() in any event |
| 02:51:11 | kugel | in fact we do it already (thread-unix.c) |
| 02:51:32 | CIA-70 | New commit by theseven (r29473): iPod Classic: Disable boosting, it seems to cause random lockups |
| 02:51:37 | kugel | that only works on unix of course |
| 02:51:53 | jhMikeS | and fibers on Windows? |
| 02:52:19 | CIA-70 | New commit by theseven (r29474): iPod Classic: Use DMA (and double buffering) for LCD updates |
| 02:52:45 | | Quit GeekShadow (Quit: The cake is a lie !) |
| 02:52:56 | kugel | jhMikeS: yes, fibers are used on windows. but I meant you can call pthread_self() even if you're only dealing with SDL threads |
| 02:52:57 | | Quit linuxguy3 (Ping timeout: 252 seconds) |
| 02:52:59 | jhMikeS | of course, sim_enter_irq_handler can set a flag (I think I removed it doing that) |
| 02:53:20 | kugel | not implemented on android ;) |
| 02:54:03 | kugel | the android port doesn't lock out interrupts but that hasn't been a problem so far |
| 02:54:21 | jhMikeS | is it preemptive? |
| 02:54:56 | | Join linuxguy3 [0] (~timj@adsl-75-57-167-24.dsl.emhril.sbcglobal.net) |
| 02:54:57 | kugel | well, partly, the rockbox threads of course aren't, but the tick handler and inpute events are |
| 02:55:07 | kugel | audio callback also |
| 02:56:04 | jhMikeS | that could corrupt the linked lists and other things |
| 02:56:37 | CIA-70 | r29473 build result: All green |
| 02:59:38 | kugel | only the tick handler can possibly deal with kernel objects, the others can't |
| 02:59:56 | TheSeven | kugel: sure? |
| 03:00 |
| 03:00:01 | TheSeven | what about wakeups? |
| 03:00:03 | kugel | on android, yes |
| 03:00:37 | kugel | there's no wakeups involved in the other handlers |
| 03:00:47 | jhMikeS | the scheduler has mysterious internal dependencies (but that's not unusual for the sort of thing) |
| 03:01:20 | | Quit MethoS- (Remote host closed the connection) |
| 03:01:29 | TheSeven | kugel: how does the audio callback acquire more data then? |
| 03:01:59 | kugel | get_more_callback? is there a wakeup involved? |
| 03:02:25 | jhMikeS | audio callback priority is not handled by the scheduler because it's not usually disabled on target except through pcm_play_lock/unlock |
| 03:03:09 | TheSeven | hm, that's a unidirectional ring buffer, which can in theory be done without kernel primitives |
| 03:03:13 | jhMikeS | on arm, it's often FIQ, and on coldfire it's priority 6 |
| 03:03:42 | jhMikeS | it's an overcomplicated one :\ |
| 03:04:48 | CIA-70 | r29474 build result: All green |
| 03:05:11 | TheSeven | nevertheless it might involve a wakeup to signal the codec thread that it may continue working |
| 03:06:55 | TheSeven | so if the codec thread starts blocking for that wakeup while it's being signalled, it might possibly get lost and block infinitely long, depending on whether there's a timeout |
| 03:07:21 | kugel | codecs don't use wakeups |
| 03:07:41 | kugel | nothing in the core does, they're only used in a target specific way |
| 03:08:05 | TheSeven | how are the buffering and codec threads and the pcm callback communicating then? |
| 03:09:09 | kugel | don't ask me :) |
| 03:09:21 | | Part iamben |
| 03:09:27 | TheSeven | spinlock-like yielding loops!? |
| 03:09:59 | jhMikeS | codec thread just polls the buffer and calls sleep() |
| 03:11:15 | jhMikeS | mpegplayer, same thing but much simpler |
| 03:13:53 | | Quit mystica555 (Ping timeout: 240 seconds) |
| 03:14:44 | | Quit mystica555_ (Ping timeout: 264 seconds) |
| 03:16:32 | | Quit linuxguy3 (Read error: Operation timed out) |
| 03:18:25 | | Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201) |
| 03:19:02 | | Join mystica555_ [0] (~mike@71-208-201-1.hlrn.qwest.net) |
| 03:19:34 | | Join linuxguy3 [0] (~timj@adsl-75-57-165-167.dsl.emhril.sbcglobal.net) |
| 03:26:57 | | Join mystica555 [0] (~Mike@71-208-201-1.hlrn.qwest.net) |
| 03:27:21 | * | jhMikeS finds 26 files with wakeup_init |
| 03:27:43 | kugel | so much? |
| 03:28:04 | jhMikeS | mips and arm files |
| 03:29:36 | * | jhMikeS wonders if that was meant as irony relative to his "everywhere" comment :) |
| 04:00 |
| 04:04:05 | | Quit Keripo (Quit: Leaving.) |
| 04:05:16 | | Join Keripo [0] (~Keripo@eng103.wireless-resnet.upenn.edu) |
| 04:06:14 | | Nick froggyman_ is now known as froggyman (~seth@98.115.0.7) |
| 04:06:24 | | Quit froggyman (Changing host) |
| 04:06:24 | | Join froggyman [0] (~seth@unaffiliated/froggyman) |
| 04:08:49 | | Join kugel_ [0] (~kugel@rockbox/developer/kugel) |
| 04:10:30 | *** | Saving seen data "./dancer.seen" |
| 04:10:44 | | Join Topy44 [0] (~Topy44@89.204.153.155) |
| 04:11:58 | | Quit kugel (Ping timeout: 240 seconds) |
| 04:18:43 | JdGordon | damn I hate being at work when i have an epiphany :p |
| 04:19:01 | JdGordon | OK, 2 more tiny changes to the touchscreen tags: |
| 04:19:27 | JdGordon | 1) Add an "action" which does nothing so we can know if a region is pressed but that region is used to control the wps and not really do anything else |
| 04:20:16 | JdGordon | 2) Add a "setting set" action which will let a touch region set a specific setting to a given value instead of just the next/prev value which we have now |
| 04:20:43 | JdGordon | this would allow awesome stuff like popping up a submenu with the 4 replay modes and being able to press the one you want instead of having to cycle them |
| 04:22:44 | JdGordon | 1) is simple to add, 2) is going to be interesting... |
| 04:23:26 | JdGordon | it might even make sense to make a new tag completly for that one so %T doesnt get too confusing (although i don't tihnk it is) |
| 04:24:32 | | Join amiconn_ [0] (quassel@rockbox/developer/amiconn) |
| 04:24:32 | | Quit amiconn (Disconnected by services) |
| 04:24:32 | | Quit pixelma (Disconnected by services) |
| 04:24:34 | | Join pixelma_ [0] (quassel@rockbox/staff/pixelma) |
| 04:24:36 | | Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) |
| 04:24:52 | | Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) |
| 04:25:05 | JdGordon | %T(label, x, y, width, height, *setting_set*, *repeat_mode*, *off*) |
| 04:25:43 | JdGordon | [Saint]: ^ |
| 04:25:47 | jhMikeS | ouch in usb-drv-as3525.c !! |
| 04:27:26 | jhMikeS | one should not signal then immediately re-init the object :\ |
| 04:42:07 | | Join The_Pwny [0] (~IceChat7@220-244-201-145.tpgi.com.au) |
| 04:47:07 | | Quit Topy44 (Read error: Connection reset by peer) |
| 04:47:08 | | Quit Barahir (Ping timeout: 250 seconds) |
| 04:48:47 | | Join Barahir [0] (~jonathan@frnk-590f41ed.pool.mediaWays.net) |
| 04:51:52 | | Quit TheSeven (Ping timeout: 260 seconds) |
| 04:52:42 | | Join Topy44 [0] (~Topy44@89.204.153.158) |
| 04:52:43 | | Quit Keripo (Quit: Leaving.) |
| 04:57:01 | | Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) |
| 05:00 |
| 05:01:06 | CIA-70 | New commit by jdgordon (r29475): Add a touchaction "none" which does nothing when pressed. This will allow some fancy controls to skins in combination with recent %T/%Tl changes |
| 05:05:06 | JdGordon | 8min builds :( |
| 05:09:29 | CIA-70 | r29475 build result: All green |
| 05:15:55 | jhMikeS | whatever happened to the < 2 min builds? |
| 05:16:20 | JdGordon | For these 181 builds, the following 31 build clients participated: |
| 05:16:40 | JdGordon | Effective round speed was 4225 points/second, making us 70% efficient. |
| 05:16:44 | JdGordon | we need more servers |
| 05:16:51 | jhMikeS | moar servers! |
| 05:17:56 | | Join Rob2223 [0] (~Miranda@p4FFF26BD.dip.t-dialin.net) |
| 05:21:13 | | Quit Rob2222 (Ping timeout: 240 seconds) |
| 05:37:22 | | Quit GodEater (Ping timeout: 260 seconds) |
| 05:38:06 | | Join GodEater [0] (~bibble@5ac83ea1.bb.sky.com) |
| 05:38:06 | | Quit GodEater (Changing host) |
| 05:38:06 | | Join GodEater [0] (~bibble@rockbox/staff/GodEater) |
| 05:43:08 | | Join Keripo [0] (~Keripo@eng052.wireless-resnet.upenn.edu) |
| 05:59:04 | | Join L-Strife89 [0] (~Strife89@168.16.226.187) |
| 06:00 |
| 06:10:34 | *** | Saving seen data "./dancer.seen" |
| 06:10:48 | | Quit timccc (Quit: Leaving.) |
| 06:11:08 | | Join timccc [0] (~timccc@112.166.15.141) |
| 06:24:31 | | Join Keripo1 [0] (~Keripo@eng052.wireless-resnet.upenn.edu) |
| 06:27:14 | | Quit Keripo (Ping timeout: 241 seconds) |
| 06:29:43 | | Join Horschti [0] (~Horscht@xbmc/user/horscht) |
| 06:32:50 | | Quit Horscht (Ping timeout: 240 seconds) |
| 06:47:40 | | Quit bzed (Ping timeout: 272 seconds) |
| 06:48:35 | | Join bzed [0] (~bzed@devel.recluse.de) |
| 06:56:43 | | Join stoffel [0] (~quassel@p57B4AF8C.dip.t-dialin.net) |
| 07:00 |
| 07:01:28 | | Join Xerion_ [0] (~xerion@5419A4D7.cm-5-2c.dynamic.ziggo.nl) |
| 07:02:50 | | Quit Xerion (Ping timeout: 240 seconds) |
| 07:02:51 | | Nick Xerion_ is now known as Xerion (~xerion@5419A4D7.cm-5-2c.dynamic.ziggo.nl) |
| 07:11:34 | | Quit L-Strife89 (Ping timeout: 240 seconds) |
| 07:28:55 | | Quit BHSPitMonkey (Remote host closed the connection) |
| 07:33:41 | | Quit [Saint] (Ping timeout: 246 seconds) |
| 07:34:31 | | Quit stoffel (Ping timeout: 250 seconds) |
| 07:41:15 | | Join Buschel [0] (~chatzilla@p54A3ABF5.dip.t-dialin.net) |
| 07:59:35 | | Join leavittx [0] (~lev@89.221.199.187) |
| 08:00 |
| 08:04:34 | | Join [Saint] [0] (S_a_i_n_t@203.184.2.134) |
| 08:05:22 | CIA-70 | New commit by Buschel (r29476): Switch off ATA DMA for all PP targets. There is sufficient evidence that ATA DMA causes sporadic lockups and static noise on several PP based players. ... |
| 08:05:32 | Buschel | [Saint]: hi, could you test the nano1g audio stuff? |
| 08:09:15 | JdGordon | Buschel: going to backport that for 3.8.1? |
| 08:09:53 | Buschel | JdGordon: yes. but not before Thursday evening. I am leaving for a short business trip today |
| 08:10:38 | *** | Saving seen data "./dancer.seen" |
| 08:10:47 | | Join mudd1 [0] (~cmertes@ip-78-94-203-49.unitymediagroup.de) |
| 08:11:04 | JdGordon | ok |
| 08:11:54 | | Quit [Saint] (Ping timeout: 272 seconds) |
| 08:12:05 | Buschel | same for FS #11973 as soon as it is verified |
| 08:13:58 | | Join Zagor [0] (~bjst@rockbox/developer/Zagor) |
| 08:15:01 | | Join [Saint] [0] (S_a_i_n_t@203.184.2.134) |
| 08:15:45 | | Quit bluebroth3r (Read error: Operation timed out) |
| 08:18:09 | | Join bluebrother [0] (~dom@f053152143.adsl.alicedsl.de) |
| 08:18:09 | | Quit bluebrother (Changing host) |
| 08:18:09 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 08:20:04 | | Quit Buschel (Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014]) |
| 08:21:39 | | Join fyrestorm [0] (~nnscript@cpe-24-90-81-248.nyc.res.rr.com) |
| 08:24:02 | | Join LinusN [0] (~linus@rockbox/developer/LinusN) |
| 08:26:16 | CIA-70 | New commit by jdgordon (r29477): Remove code duplication in some generic skin touch action handling. ... |
| 08:28:21 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 08:34:19 | amiconn | Hmm, seems like the big build boxes have fallen off the buildserver network |
| 08:34:30 | amiconn | My two clients are working like mad. |
| 08:34:49 | JdGordon | I'm reinstalling ubunutu on my desktop and will reconnect it up |
| 08:35:00 | JdGordon | dunno how much it wil help, but hopefully a bit |
| 08:35:47 | amiconn | "6 builds remaining" That's still Buschel's commit |
| 08:36:30 | JdGordon | :O |
| 08:39:56 | CIA-70 | r29476 build result: All green |
| 08:41:55 | Zagor | yeah we lost all roolku's machines |
| 08:42:27 | amiconn | I hope the hard timeout isn't set too low then, at least |
| 08:43:13 | amiconn | Last round took almost 35 minutes |
| 08:48:36 | | Quit amee2k (Ping timeout: 250 seconds) |
| 08:51:43 | | Quit t0rc (Quit: Give someone code, help them with one project. Teach someone to code, help them rule the world.) |
| 08:52:24 | JdGordon | time to drop some builds also? |
| 08:52:35 | JdGordon | 35min is the bad old days :) |
| 08:53:08 | Zagor | if roolku is permanently gone, we need to do a recruiting drive and perhaps prune the build list a bit |
| 08:53:19 | Zagor | but we should first see if that is the case |
| 08:53:51 | CIA-70 | New commit by wodz (r29478): Move ata_mmc.c into target tree as it is SH (ondio) specific. Associated header file is left intact as it seems to be used in many places for ... |
| 08:53:58 | | Join wodz [0] (~wodz@87-206-240-131.dynamic.chello.pl) |
| 08:55:13 | | Join amee2k [0] (~thomas@ve504.cugnet.net) |
| 08:57:31 | amiconn | Build speed should be a bit better for subsequent builds due to ccache |
| 09:00 |
| 09:19:22 | | Quit amee2k (Ping timeout: 246 seconds) |
| 09:20:49 | | Nick crwll is now known as crwl (~crwlll@dsl-jklbrasgw1-fe8edf00-29.dhcp.inet.fi) |
| 09:26:08 | wodz | damn this build rund takes ages |
| 09:26:35 | Zagor | 1 build remaining... |
| 09:27:07 | CIA-70 | r29477 build result: 0 errors, 4 warnings (jdgordon committed) |
| 09:27:19 | wodz | hmm |
| 09:33:41 | GodEater | Just wanted to pop in to say I thought kugel's suggestions for GSOC were all great ideas. They all look to be around the right amount of work - he's clearly inspired! |
| 09:38:45 | wodz | Zagor: any estimated time for the current rund - I have to leave soon unfortunately |
| 09:39:27 | | Quit mystica555_ (Ping timeout: 260 seconds) |
| 09:39:44 | wodz | I think TheSeven's idea about test layer is also very interesting and can be turned into GSOC proposal as well |
| 09:39:52 | Zagor | I'm afraid not. I added an additional client but I wouldn't bet below 30 mintues |
| 09:40:02 | wodz | :/ |
| 09:40:51 | wodz | Maybe we should prepare vm machine to serve as build client. This will attract windows users maybe? |
| 09:41:21 | | Quit Keripo1 (Quit: Leaving.) |
| 09:42:36 | Zagor | first we need to know if roolku's machines are gone permantently or not |
| 09:43:36 | Zagor | of course, more clients is *always* good. but I don't know if we really have a lot of windows users wishing to run build client vms? |
| 09:44:39 | Zagor | it certainly can't hurt though, if someone fancies preparing it |
| 09:46:06 | wodz | Zagor: The question is more if our build system is prepared for this. This should be as much automated as possible meaning that server side should assign unique name for example |
| 09:46:25 | Zagor | but there's a whole list of other clients that have dissappeared as well. not just roolku. |
| 09:46:59 | Zagor | wodz: ah, no we're not prepared for "cloned clients". |
| 09:47:24 | wodz | Zagor: maybe worth considering |
| 09:47:30 | | Quit factor (Read error: Connection reset by peer) |
| 09:47:51 | | Join amee2k [0] (~thomas@ve504.cugnet.net) |
| 09:50:48 | | Quit Topy44 (Read error: Connection reset by peer) |
| 09:50:58 | Zagor | I wonder if a simple start/install script isn't a better idea. I think people are likely to want to be able to follow their contribution in the lists. |
| 09:52:01 | wodz | that's an option yes |
| 09:52:47 | JdGordon | would vm's even give us a worthwhile speed bump? |
| 09:52:59 | * | JdGordon will fix his warnings shortly |
| 09:53:04 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 09:53:14 | wodz | JdGordon: that depends how many people will run it |
| 09:54:00 | Zagor | JdGordon: right now, every sheeva box or atom netbook would help |
| 09:54:46 | wodz | JdGordon: but currently running build client need some afford which may discourage people from contributing to our distributed build system |
| 09:55:11 | | Quit amee2k (Ping timeout: 260 seconds) |
| 09:55:16 | wodz | running vm is cheap solution this days |
| 09:55:40 | Zagor | at midnight we had 15 non-roolku clients, now we have 7 (and that is only because I just added a new!) |
| 09:57:42 | pixelma | a pity I don't have time to update or prepare my VMs before today in the evening or so |
| 09:57:49 | CIA-70 | r29478 build result: 0 errors, 4 warnings (wodz committed) |
| 09:57:49 | | Join roolku [0] (~roolku@cpc1-sgyl16-0-0-cust145.sgyl.cable.virginmedia.com) |
| 09:58:05 | wodz | Zagor: About clonned clients - build server may mark machine with cleverly build hash which will be written on first run in some config file. People will be able to track down their contribution by this |
| 09:58:22 | | Join n1s [0] (~n1s@sb-fw.bmc.uu.se) |
| 09:58:22 | | Quit n1s (Changing host) |
| 09:58:22 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
| 09:58:26 | wodz | Not my warnings :-) |
| 09:58:30 | JdGordon | does anyone know why the sim builds arent warning like they used to? |
| 09:58:38 | pixelma | ah roolku, welcome :) |
| 09:58:46 | roolku | hi :) |
| 09:59:17 | roolku | it looks to me that some change on the build server may have killed all my clients? |
| 09:59:45 | roolku | they hang and the last message is: 2011-03-01 04:09:21 Killed build sdlapplication |
| 09:59:47 | Zagor | roolku: I don't know what has happened. the server is unchanged. |
| 09:59:58 | Zagor | but it appears to have affected a lot of clients. |
| 10:00 |
| 10:00:00 | pixelma | or connection problems? |
| 10:01:04 | JdGordon | the required toolchain config stuff got messed up? |
| 10:01:04 | roolku | what is sdlapplication? it is not a simulator build? |
| 10:01:06 | | Part LinusN |
| 10:01:22 | Zagor | pixelma: no, I can connect to for example bagder's build client but it still absent |
| 10:01:41 | pixelma | it's to do with the Rockbox as an app port - one for SDL |
| 10:01:49 | CIA-70 | New commit by jdgordon (r29479): fix yellow |
| 10:01:56 | | Join Topy44 [0] (~Topy44@89.204.153.208) |
| 10:02:23 | roolku | they didn't drop all at once, but starting from 29473 - as if they got something they couldn't chew |
| 10:02:36 | Zagor | oh, gevaerts added that in 29472. that looks like it could the problem. |
| 10:02:59 | Zagor | *be |
| 10:03:38 | roolku | I started b38 again and it seems to work - I'll wait a bit before I go through the trouble of restarting them all |
| 10:04:01 | Zagor | roolku: yes, we'll need to verify the sdlapp addition |
| 10:04:43 | | Join factor [0] (~factor@75.108.68.114) |
| 10:05:04 | pixelma | ah, the SDL app needs to set aprefix during configure, maybe that causes the trouble |
| 10:05:11 | Zagor | yes, "../tools/configure −−target=sdlapp −−type=n" blocks waiting for LCD width ... |
| 10:05:22 | * | Zagor whips gevaerts |
| 10:05:23 | pixelma | and that |
| 10:05:44 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
| 10:06:06 | JdGordon | he did say something about blaming other people if anything went pear shaped last night :) |
| 10:07:53 | JdGordon | whats the package to get makeinfo? |
| 10:08:12 | Zagor | JdGordon: texinfo |
| 10:08:22 | JdGordon | ta |
| 10:08:55 | JdGordon | and do any targets still use the old arm toolchain? |
| 10:09:14 | Zagor | no |
| 10:09:31 | Zagor | we should take that out of the "all" option in rockboxdev |
| 10:10:42 | *** | Saving seen data "./dancer.seen" |
| 10:13:51 | CIA-70 | New commit by wodz (r29480): Move drivers/i2c.c into target tree as it contains SH specific bits. Leave associated header file intact as it is used in many places for historical ... |
| 10:16:16 | wodz | Ok, that's my 0.02$ to make codebase a bit cleaner |
| 10:16:22 | | Quit mudd1 (Ping timeout: 264 seconds) |
| 10:20:41 | CIA-70 | New commit by zagor (r29481): Add LCD width and height to sdlapplication. |
| 10:23:05 | Zagor | roolku: now you can restart your clients |
| 10:23:14 | Zagor | I'll send a mail to the rbclient list |
| 10:25:32 | CIA-70 | r29479 build result: All green |
| 10:26:20 | | Join The_Pwny_ [0] (~IceChat7@220-244-201-145.tpgi.com.au) |
| 10:27:34 | | Quit The_Pwny (Ping timeout: 276 seconds) |
| 10:29:42 | | Join amee2k [0] (~thomas@ve504.cugnet.net) |
| 10:29:49 | roolku | Zagor: I have restarted the n?? clients ... will do the rest later today |
| 10:30:06 | Zagor | excellent |
| 10:31:28 | | Quit The_Pwny_ (Ping timeout: 276 seconds) |
| 10:33:30 | wodz | damn this sd/mmc things are scattered across target tree files, firmware/export/sd.h, firmware/export/sdmmc.h, firmware/export/ata_mmc.h |
| 10:33:37 | JdGordon | oh, the install paths got changed? |
| 10:33:43 | CIA-70 | r29480 build result: All green |
| 10:34:09 | wodz | what a mess |
| 10:35:40 | | Join DerPapst [0] (~Alexander@dslb-088-069-145-073.pools.arcor-ip.net) |
| 10:36:00 | | Quit wodz (Quit: Leaving) |
| 10:37:49 | | Join bicyclerepairman [0] (~Sam@2.100.254.232) |
| 10:39:29 | bicyclerepairman | how do I go about donating some hardware? |
| 10:39:43 | bicyclerepairman | I have an old creative Zen that's not useful to me, |
| 10:39:52 | bicyclerepairman | and I know you chaps are working on a port to it, so... |
| 10:39:59 | bicyclerepairman | it's yours if you want it. |
| 10:42:17 | Zagor | that's nice. are you in the uk? |
| 10:43:24 | Zagor | which model is it? |
| 10:47:48 | CIA-70 | New commit by gevaerts (r29482): Fix the builds file properly now. I'll never do this stuff again after my regular bed time! |
| 10:49:06 | JdGordon | is the wiki outdated? is arm in the arch list eabi? |
| 10:49:07 | Zagor | oops :) |
| 10:49:15 | Zagor | JdGordon: eabi |
| 10:51:03 | JdGordon | and m68k? saying i've got the wrong version (which i just installed with rockboxdev.sh) |
| 10:53:40 | * | gevaerts doesn't understand why his calibration script didn't choke on that bad line |
| 10:53:56 | JdGordon | m68k-gcc452 apparently |
| 10:54:03 | JdGordon | runclient.sh shold prob be updated :) |
| 10:54:51 | gevaerts | JdGordon: the instructions say that you should tweak runclient.sh according to your local setup IIRC :) |
| 10:55:07 | JdGordon | yes, but it doesnt say what the excpeted arch's are |
| 10:55:17 | JdGordon | or legal ones |
| 10:55:19 | * | JdGordon is in |
| 10:56:40 | bicyclerepairman | Yeah I'm in the UK. |
| 10:57:32 | bicyclerepairman | Zagor, it's a Creative Zen Micro |
| 10:57:58 | bicyclerepairman | firmware version is 2.21.02, |
| 10:58:11 | | Join LinusN [0] (~linus@rockbox/developer/LinusN) |
| 10:58:12 | bicyclerepairman | storage capacity is 2 gig incase you care :-) |
| 10:58:41 | bicyclerepairman | and it works OK but the headphone jack is a bit squoogley |
| 10:58:54 | bicyclerepairman | so that you have to hold the wire to get any sound. |
| 10:59:11 | bicyclerepairman | But I tihnk this doesn't matter from a developer's point of view |
| 10:59:13 | bicyclerepairman | :-) |
| 11:00 |
| 11:00:25 | [Saint] | "squoogley"...nice. |
| 11:00:36 | [Saint] | ;) |
| 11:03:34 | | Join GodEater_ [0] (~bibble@5ac9b8c7.bb.sky.com) |
| 11:03:34 | | Quit GodEater_ (Changing host) |
| 11:03:34 | | Join GodEater_ [0] (~bibble@rockbox/staff/GodEater) |
| 11:06:24 | | Quit GodEater (Ping timeout: 250 seconds) |
| 11:17:04 | Zagor | any brit volunteering to be mail drop? |
| 11:18:42 | bicyclerepairman | brb, got an appointment at the bank. |
| 11:20:08 | | Join mudd1 [0] (~cmertes@2001:638:504:20e0:221:70ff:fe83:655e) |
| 11:28:02 | | Quit panni_ (Read error: Connection reset by peer) |
| 11:28:13 | | Join panni_ [0] (hannes@ip-178-203-73-7.unitymediagroup.de) |
| 11:30:36 | | Join MethoS- [0] (~clemens@134.102.106.250) |
| 11:36:07 | | Join francesco_ [0] (~francesco@93-41-147-152.ip82.fastwebnet.it) |
| 11:36:40 | francesco_ | can i set crossfading playback and relative settings from config file or similar? |
| 11:37:04 | n1s | francesco_: yes |
| 11:37:51 | francesco_ | n1s: can u point me to the relative docs/how to? |
| 11:39:00 | n1s | francesco_: see the "Config file options" section in the manual's appendix |
| 11:43:17 | francesco_ | n1s: thx |
| 11:47:50 | | Quit roolku () |
| 11:49:11 | | Quit simonrvn (Read error: Connection reset by peer) |
| 11:49:50 | | Quit [Saint] (Quit: I'm only going to Heaven if it feels like Hell, I'm only going to Heaven if it tastes like caramel...) |
| 11:53:06 | bicyclerepairman | I'm back |
| 11:53:13 | bicyclerepairman | Zagor, did you find anyone? |
| 11:54:24 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
| 11:55:49 | pamaury | Zagor: what do you mean by "mail drop" ? |
| 11:57:24 | Zagor | pamaury: to recieve the device. and forward it to any developer who expresses interest. |
| 11:58:07 | pamaury | ok, I guess it's better if it's someone in UK |
| 11:59:48 | Zagor | I just thought it would be easiest. but if nobody volunteers, and if bicyclerepairman doesn't mind sending it internationally, I can take it |
| 12:00 |
| 12:00:12 | bicyclerepairman | well where do you live, Zagor? |
| 12:00:16 | Zagor | sweden |
| 12:00:29 | bicyclerepairman | oh that's simply beautifu :-) |
| 12:00:31 | pamaury | I don't min too, France is not too far also :) |
| 12:00:32 | bicyclerepairman | I love Sweden |
| 12:01:00 | pamaury | *mind |
| 12:01:37 | bicyclerepairman | well I don't really mind sending it internationally, but I wonder if you could help me out with the postage? |
| 12:01:43 | bicyclerepairman | whoever's interested |
| 12:04:04 | Zagor | possibly. but let's wait a bit to see if someone local raises a hand. |
| 12:10:45 | *** | Saving seen data "./dancer.seen" |
| 12:13:08 | francesco_ | i have a feat request (or better a bug fix) for which i'll be ready to pay a (small) amount of money for. A free player would be also provided to the interested developer. Anyone? |
| 12:13:53 | JdGordon | why dont you say what it is? |
| 12:14:13 | francesco_ | jdGordon: it's task #11664 |
| 12:14:16 | JdGordon | and bare in mind we dont code for money, we do it to have fun |
| 12:14:32 | francesco_ | jdGordon: sure. |
| 12:17:31 | Torne | francesco_: That's a bug that a lot of people already care about and are working on |
| 12:17:36 | Torne | If we knew how to fix it it would be fixed already |
| 12:17:50 | Torne | Offering money/players is not likely to make any difference |
| 12:17:56 | Torne | it'll get fixed when we work out what the problem is |
| 12:22:34 | | Join swilde [0] (~wilde@aktaia.intevation.org) |
| 12:27:00 | francesco_ | Torne: ok, i was just trying to offer some help to speed things up. Maybe i've choosen the wrong mean. Anything else i can do to help? (apart from coding...) |
| 12:27:35 | Torne | there is almost certainly no way to help without making a technical contribution |
| 12:27:42 | Torne | when a new patch is proposed, test it |
| 12:27:58 | Torne | but other than that.. probably not |
| 12:29:57 | francesco_ | Torne: ok thanks |
| 12:30:50 | n1s | verifying bugs can also be helpful if they are only affecting certain hardware for example |
| 12:31:06 | Torne | add the bug to your watchlist and it'll email you whenever soemone adds a comment |
| 12:31:16 | Torne | n1s: this is "usb doesn't work on amsv2" |
| 12:31:28 | Torne | n1s: so there's not a lot of verification to do :) |
| 12:32:10 | n1s | i understood him as asking how to help in a wider sense, not just for that particluar bug |
| 12:34:20 | TheSeven | Torne: do you know what exactly the matter with amsv2 usb is? |
| 12:34:58 | n1s | why is logoswapper in our wiki? |
| 12:34:59 | TheSeven | IIRC this is the same OTG that I am working with in several ipods, and I've had some funky behavior with these recently as well |
| 12:35:00 | Torne | sometimes the device hard locks and can't be reset |
| 12:35:12 | Torne | since there's no hardware reset on those devices |
| 12:35:20 | Torne | you have to wait for the battery to run all the way down |
| 12:35:31 | Torne | This is why USB is still disabled on them :) |
| 12:35:37 | TheSeven | which luckily happens a lot faster than on an ipod :) |
| 12:35:43 | Torne | hehe |
| 12:35:58 | Torne | that's all i know about it anyway |
| 12:36:15 | TheSeven | ok, so this is actually a pure software bug in the driver? |
| 12:36:20 | Torne | no idea. |
| 12:36:46 | TheSeven | the behavior i recently experienced was linux having trouble to communicate with that OTG, while windows was working fine |
| 12:37:06 | TheSeven | and sometimes some lockups as well, but these apparently went away after raising Vcore a bit |
| 12:39:25 | | Join [Saint] [0] (S_a_i_n_t@203.184.0.138) |
| 12:44:23 | JdGordon | hey [Saint] |
| 12:47:46 | | Join wodz|work [0] (~5f303f8a@giant.haxx.se) |
| 12:48:01 | | Quit rasher (Ping timeout: 272 seconds) |
| 12:48:07 | | Quit [Saint] (Ping timeout: 250 seconds) |
| 12:49:08 | wodz|work | About amsv2 lockups - why don't set watchdog? This at least may make the problem less harmfull and make testing safer |
| 12:50:13 | wodz|work | we will know at least if tick tasks are still running in locked up state |
| 12:50:21 | | Quit panni_ (Quit: ( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )) |
| 12:50:33 | | Join Jerom [0] (~jerome@79.132.59.245) |
| 12:51:49 | | Join [Saint] [0] (S_a_i_n_t@203.184.0.138) |
| 12:52:16 | wodz|work | TheSeven: I experience various funny effects with USB on linux with receintish kernel. This is surly problem on linux side. |
| 12:52:39 | TheSeven | yeah, but it doesn't happen with other hardware, so we must be triggering it somehow |
| 12:52:45 | TheSeven | and thus we must be able to work around it |
| 12:53:38 | wodz|work | TheSeven: not true - I have problem with PP5020E for example and some cardreaders\ |
| 12:54:12 | francesco_ | ok, i throw my 2 cents, based on my experiences: OF boots up even if player powered after it gets connected to power trough the usb cable+power adapter |
| 12:54:14 | TheSeven | yeah, but it doesn't happen to every single pendrive out there |
| 12:54:41 | TheSeven | so there must be something we can do about it |
| 12:54:47 | | Join rasher [0] (~rasher@0x5550f5a3.adsl.cybercity.dk) |
| 12:54:47 | | Quit rasher (Changing host) |
| 12:54:47 | | Join rasher [0] (~rasher@rockbox/developer/rasher) |
| 12:55:00 | pamaury | I think jhMikeS suggested that #11664 was a SD bug and not a USB one, after all the usb fixes committed to trunk |
| 12:55:50 | wodz|work | TheSeven: Maybe we trigger it somehow but the bug *IS* in linux ehci driver |
| 12:56:08 | TheSeven | pamaury: that would be easy to check |
| 12:56:12 | TheSeven | just remove SD? |
| 12:56:34 | TheSeven | wodz|work: nevertheless we need to get rid of it somehow |
| 12:57:37 | wodz|work | TheSeven: I'd love to see this fixed unloading (or unbinding) ehci when I want to access my ipod is a bit silly |
| 12:58:00 | TheSeven | if possible without a reboot at all |
| 12:58:06 | pamaury | I haven't tested my usb patch for quite some time, perhaps I should see what is the current state |
| 12:58:32 | wodz|work | TheSeven: But on my mini1g even disk mode exhibits the same problem |
| 12:59:09 | TheSeven | that problem being that it works, but is terribly slow because of bus resets after every couple of bulk packets? |
| 12:59:38 | TheSeven | (often observed as mount locking up because scanning the FAT may take like an hour) |
| 12:59:53 | | Join simonrvn [0] (simon@2001:470:8c85:11fe::c0a8:195) |
| 13:00 |
| 13:00:26 | wodz|work | TheSeven: yes but I think it sometimes goes as bad as hard usb disconnect |
| 13:02:54 | wodz|work | TheSeven: Do you know something about the root of this behaviour? Google isn't very verbose about it |
| 13:03:30 | TheSeven | IIRC it has been bisected, so we might want to have a look at the diff |
| 13:04:16 | wodz|work | TheSeven: could you provide the source of this info? |
| 13:04:33 | TheSeven | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/256767 |
| 13:05:23 | TheSeven | not exactly our behavior, but similar enough to be caused by the same issue |
| 13:06:22 | | Part LinusN |
| 13:08:28 | TheSeven | especially https://bugs.launchpad.net/ubuntu/+source/linux/+bug/256767/comments/64 sounds interesting |
| 13:10:04 | pamaury | that looks really similar to our problem |
| 13:13:54 | | Quit wodz|work (Ping timeout: 240 seconds) |
| 13:13:54 | | Part Zagor |
| 13:14:37 | | Join Zagor [0] (~bjst@rockbox/developer/Zagor) |
| 13:16:07 | TheSeven | yeah, but sadly seems to be off-topic in that launchpad-thread |
| 13:16:21 | * | TheSeven just spotted a possible build system flaw! |
| 13:16:27 | | Join wodz [0] (~5f303f8a@giant.haxx.se) |
| 13:16:35 | TheSeven | it doesn't seem to notice if svn up fails because of e.g. insufficient permissions |
| 13:16:48 | TheSeven | does that mean that it will produce old builds without anyone noticing? |
| 13:17:05 | wodz | still the only solution provided is to unload ehci |
| 13:18:17 | n1s | unloading ehci is kind of annoying with usb connected mouse and keyboard |
| 13:19:06 | pamaury | you need to get the command line right if you don't want to reboot :) |
| 13:19:50 | TheSeven | in theory you can just unbind that one device and pass it over to uhci |
| 13:19:51 | Zagor | doesn't svn return non-zero on bad permissions? |
| 13:21:02 | wodz | even worse on ubuntu where they decided to compile this into kernel |
| 13:22:11 | | Quit sasquatch (Quit: WeeChat 0.3.2) |
| 13:23:09 | | Join sasquatch [0] (~username@p4FF2CBE6.dip.t-dialin.net) |
| 13:23:09 | | Quit scorche (Disconnected by services) |
| 13:23:09 | | Join scorche` [0] (~scorche@rockbox/administrator/scorche) |
| 13:26:19 | | Quit Zagor (Read error: Connection reset by peer) |
| 13:26:26 | | Quit wodz (Quit: CGI:IRC (Ping timeout)) |
| 13:28:38 | | Join Guest85077 [0] (~bjst@giant.haxx.se) |
| 13:28:45 | | Quit Guest85077 (Changing host) |
| 13:28:45 | | Join Guest85077 [0] (~bjst@rockbox/developer/Zagor) |
| 13:31:10 | CIA-70 | New commit by jdgordon (r29483): Add an ability to set a setting to a specific value with a touchscreen action. ... |
| 13:33:17 | | Join TheLemonMan [0] (~lem0n@ppp-135-147.98-62.inwind.it) |
| 13:34:35 | JdGordon | can we convert genlang to c? it really slows down the builds :/ |
| 13:34:35 | * | JdGordon is an impatient bugger |
| 13:35:37 | | Part Guest85077 |
| 13:36:59 | | Quit Jerom (Quit: Leaving.) |
| 13:36:59 | n1s | yeah genlang is slow and i have been thinking about doing that but i don't want to :) |
| 13:36:59 | | Quit timccc (Ping timeout: 240 seconds) |
| 13:38:01 | n1s | iirc someone said it could be made faster while still remaining perl but i don't know how |
| 13:38:01 | JdGordon | Zagor: gevaerts: is http://pastebin.com/uW6tx7uH sane? |
| 13:38:06 | JdGordon | I keep getting these server connection stalled errors :( |
| 13:39:08 | | Join timccc [0] (~timccc@112.166.15.141) |
| 13:40:58 | DEBUG | Received signal 15 (SIGTERM), terminating (snapshot: fplrun.c line 385) |
| 13:40:58 | *** | Cleanup |
| 13:40:58 | *** | Saving seen data "./dancer.seen" |
| 13:40:58 | *** | Exit |
| 13:45:46 | *** | Started Dancer V4.16 |
| 13:45:46 | *** | Connected to irc.freenode.net on port 6667 |
| 13:45:46 | *** | Logfile for #rockbox started |
| 13:45:47 | Mode | "logbot :+i" by logbot |
| 13:45:51 | *** | Server message 501: 'logbot :Unknown MODE flag' |
| 13:45:51 | | Join logbot [0] (~rockbox@giant.haxx.se) |
| 13:45:51 | | Join timccc [0] (~timccc@112.166.15.141) |
| 13:45:51 | | Join TheLemonMan [0] (~lem0n@ppp-135-147.98-62.inwind.it) |
| 13:45:51 | | Join scorche` [0] (~scorche@rockbox/administrator/scorche) |
| 13:45:51 | | Join sasquatch [0] (~username@p4FF2CBE6.dip.t-dialin.net) |
| 13:45:51 | | Join simonrvn [0] (simon@2001:470:8c85:11fe::c0a8:195) |
| 13:45:51 | | Join rasher [0] (~rasher@rockbox/developer/rasher) |
| 13:45:51 | | Join [Saint] [0] (S_a_i_n_t@203.184.0.138) |
| 13:45:51 | | Join swilde [0] (~wilde@aktaia.intevation.org) |
| 13:45:51 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
| 13:45:51 | | Join francesco_ [0] (~francesco@93-41-147-152.ip82.fastwebnet.it) |
| 13:45:51 | | Join MethoS- [0] (~clemens@134.102.106.250) |
| 13:45:51 | | Join mudd1 [0] (~cmertes@2001:638:504:20e0:221:70ff:fe83:655e) |
| 13:45:51 | | Join GodEater_ [0] (~bibble@rockbox/staff/GodEater) |
| 13:45:51 | | Join bicyclerepairman [0] (~Sam@2.100.254.232) |
| 13:45:51 | | Join DerPapst [0] (~Alexander@dslb-088-069-145-073.pools.arcor-ip.net) |
| 13:45:51 | | Join amee2k [0] (~thomas@ve504.cugnet.net) |
| 13:45:51 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
| 13:45:51 | | Join factor [0] (~factor@75.108.68.114) |
| 13:45:51 | | Join Topy44 [0] (~Topy44@89.204.153.208) |
| 13:45:51 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
| 13:45:51 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 13:45:51 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 13:45:51 | | Join fyrestorm [0] (~nnscript@cpe-24-90-81-248.nyc.res.rr.com) |
| 13:45:51 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 13:45:51 | | Join leavittx [0] (~lev@89.221.199.187) |
| 13:45:51 | | Join Xerion [0] (~xerion@5419A4D7.cm-5-2c.dynamic.ziggo.nl) |
| 13:45:51 | | Join bzed [0] (~bzed@devel.recluse.de) |
| 13:45:51 | | Join Horschti [0] (~Horscht@xbmc/user/horscht) |
| 13:45:51 | | Join Rob2223 [0] (~Miranda@p4FFF26BD.dip.t-dialin.net) |
| 13:45:51 | | Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) |
| 13:45:51 | | Join Barahir [0] (~jonathan@frnk-590f41ed.pool.mediaWays.net) |
| 13:45:51 | | Join pixelma [0] (quassel@rockbox/staff/pixelma) |
| 13:45:51 | | Join amiconn [0] (quassel@rockbox/developer/amiconn) |
| 13:45:51 | | Join kugel_ [0] (~kugel@rockbox/developer/kugel) |
| 13:45:51 | | Join mystica555 [0] (~Mike@71-208-201-1.hlrn.qwest.net) |
| 13:45:51 | | Join linuxguy3 [0] (~timj@adsl-75-57-165-167.dsl.emhril.sbcglobal.net) |
| 13:45:51 | | Join krazykit [0] (~krazykit@99-126-205-52.lightspeed.cicril.sbcglobal.net) |
| 13:45:51 | | Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) |
| 13:45:51 | | Join YPSY [0] (~ypsy@geekpadawan.de) |
| 13:45:51 | | Join froggyman [0] (~seth@unaffiliated/froggyman) |
| 13:45:51 | | Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) |
| 13:45:51 | | Join ehntoo [0] (~ehntoo@lug.mtu.edu) |
| 13:45:51 | | Join saratoga [0] (9803c6dd@gateway/web/freenode/ip.152.3.198.221) |
| 13:45:51 | | Join MagusG [0] (magusg@c-71-59-57-46.hsd1.ga.comcast.net) |
| 13:45:51 | | Join crwl [0] (~crwlll@dsl-jklbrasgw1-fe8edf00-29.dhcp.inet.fi) |
| 13:45:51 | | Join n17ikh [0] (~n17ikh@c-68-59-25-51.hsd1.sc.comcast.net) |
| 13:45:51 | | Join linuxstb_ [0] (~linuxstb@rockbox/developer/linuxstb) |
| 13:45:51 | | Join Robdgreat [0] (~rob@unaffiliated/robdgreat) |
| 13:45:51 | | Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) |
| 13:45:51 | | Join tchan1 [0] (~tchan@c-69-243-144-187.hsd1.il.comcast.net) |
| 13:45:51 | | Join balintx [0] (~quassel@szerver1.gulyasp-koll.sulinet.hu) |
| 13:45:51 | | Join Dr_Agasa [0] (uno@host135-126-dynamic.20-79-r.retail.telecomitalia.it) |
| 13:45:51 | | Join antil33t [0] (antil33t@124-197-51-80.callplus.net.nz) |
| 13:45:51 | | Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) |
| 13:45:51 | | Join parafin [0] (parafin@paraf.in) |
| 13:45:51 | | Join eGen_ [0] (generat0r@gate.mmdecin.cz) |
| 13:45:51 | | Join cjcopi [0] (~craig@adsl-76-241-72-119.dsl.bcvloh.sbcglobal.net) |
| 13:45:51 | | Join jepler [0] (~jepler@emc/developer/pdpc.professional.jepler) |
| 13:45:51 | | Join Loto [0] (~nfs@xbmc/user/Loto) |
| 13:45:51 | | Join CapsAdmin [0] (CapsAdmin@ti0143a340-dhcp0163.bb.online.no) |
| 13:45:51 | | Join knittl [0] (~knittl@unaffiliated/knittl) |
| 13:45:51 | | Join Mephistopheles [0] (fuzzylomba@S0106485b3917092d.vs.shawcable.net) |
| 13:45:51 | | Join AlexP [0] (~alex@rockbox/staff/AlexP) |
| 13:45:51 | | Join jordan` [0] (~jordan@jem75-13-78-235-252-137.fbx.proxad.net) |
| 13:45:51 | | Join FOAD [0] (~dok@83.161.135.61) |
| 13:45:51 | | Join logiclost [0] (~lostlogic@erudite.lostlogicx.com) |
| 13:45:51 | | Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) |
| 13:45:51 | | Join olejorgenb [0] (bronner@caracal.stud.ntnu.no) |
| 13:45:51 | | Join avacore [0] (~avacore@1008ds1-rdo.0.fullrate.dk) |
| 13:45:51 | | Join alexbobp [0] (~alex@adsl-75-34-101-211.dsl.austtx.sbcglobal.net) |
| 13:45:51 | | Join guymann [0] (~charles@66-159-148-187.adsl.snet.net) |
| 13:45:51 | | Join FoolOnHill [0] (~foh@adsl-71-69-118.bhm.bellsouth.net) |
| 13:45:51 | | Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) |
| 13:45:51 | | Join niekie [0] (~niek@CAcert/Assurer/niekie) |
| 13:45:51 | | Join literal [0] (hinrik@w.nix.is) |
| 13:45:51 | | Join kkit|sh [0] (~kkit@li135-248.members.linode.com) |
| 13:45:51 | | Join Rondom [0] (~rondom@lvps178-77-79-47.dedicated.hosteurope.de) |
| 13:45:51 | | Join Zarggg [0] (~zarggg@24.229.139.169.res-cmts.sm.ptd.net) |
| 13:45:51 | | Join maraz [0] (maraz@kapsi.fi) |
| 13:45:51 | | Join plux [0] (~yogurt@h-34-156.A238.priv.bahnhof.se) |
| 13:45:51 | | Join Dreamxtreme [0] (~Dre@92.18.99.114) |
| 13:45:51 | | Join markun [0] (~markun@rockbox/developer/markun) |
| 13:45:51 | | Join Zambezi [0] (Zulu@80.67.9.2) |
| 13:45:51 | | Join Galois [0] (djao@efnet-math.org) |
| 13:45:51 | | Join Torne [0] (~torne@rockbox/developer/Torne) |
| 13:45:51 | | Join soap_ [0] (~soap@rockbox/staff/soap) |
| 13:45:51 | | Join z35 [0] (~z35@ool-18bdad71.dyn.optonline.net) |
| 13:45:51 | | Join tmzt [0] (~tmzt@76.211.0.152) |
| 13:45:51 | | Join aevin [0] (eivindsy@unaffiliated/aevin) |
| 13:45:51 | | Join Utchy [0] (~Utchy@rps6752.ovh.net) |
| 13:45:51 | | Join ps-auxw [0] (~arneb@2001:470:c807:0:1532:4e5f:2ad3:4123) |
| 13:45:51 | | Join Elfish [0] (amba@2a01:4f8:100:90a1:abc:abc:abc:abc) |
| 13:45:51 | | Join ranmachan [0] (ranma@yumi.tdiedrich.de) |
| 13:45:51 | | Join gevaerts [0] (~fg@rockbox/developer/gevaerts) |
| 13:45:51 | | Join ack` [0] (~ack@mingbai.org) |
| 13:45:51 | | Join yosafbridge [0] (~yosafbrid@li125-242.members.linode.com) |
| 13:45:51 | | Join Kohlrabi [0] (~kohlrabi@kohlio.de) |
| 13:45:51 | | Join ved [0] (ved@ddsbox.co.cc) |
| 13:45:51 | | Join Battousai [0] (~bryan@gentoo/developer/battousai) |
| 13:45:51 | | Join simabeis [0] (~simabeis@lobmenschen.de) |
| 13:45:51 | | Join Hadaka [0] (~naked@naked.iki.fi) |
| 13:45:51 | | Join Guinness [0] (Slayer@c-68-55-111-159.hsd1.va.comcast.net) |
| 13:45:51 | | Join Farthen [0] (~Farthen@static.225.178.40.188.clients.your-server.de) |
| 13:45:51 | | Join zu_ [0] (~zu@ks355000.kimsufi.com) |
| 13:45:51 | | Join dionoea [0] (~dionoea@videolan/developer/dionoea) |
| 13:45:51 | | Join feisar- [0] (jljhook@ihq.in) |
| 13:45:51 | | Join Strife89 [0] (~Strife89@168.16.226.187) |
| 13:45:51 | | Join merbanan [0] (~banan@c-94-255-218-11.cust.bredband2.com) |
| 13:45:51 | | Join ThomasAH [0] (~thomas@aktaia.intevation.org) |
| 13:45:51 | | Join CIA-70 [0] (~CIA@208.69.182.149) |
| 13:45:51 | | Join preglow [0] (thomj@rockbox/developer/preglow) |
| 13:45:51 | | Join TBCOOL [0] (~tb@c-3c3671d5.09-42-73746f22.cust.bredbandsbolaget.se) |
| 13:45:51 | | Join Slasheri_ [0] (miipekk@xen.ihme.org) |
| 13:45:51 | | Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) |
| 13:45:51 | | Join @ChanServ [0] (ChanServ@services.) |
| 13:45:51 | | Join jae_ [0] (~jae@dedicated.jaerhard.com) |
| 13:45:51 | | Join yawny [0] (user36@pr0.us) |
| 13:45:51 | | Join 45PABT3DY [0] (~iq@unaffiliated/iq) |
| 13:45:51 | | Join Kuitsi [0] (~Kuitsi@a88-113-118-171.elisa-laajakaista.fi) |
| 13:45:51 | | Join pikytcus1 [0] (~bigd@failbox.co.cc) |
| 13:45:51 | | Join pjm0616 [0] (~user@sigfpe-1-pt.tunnel.tserv15.lax1.ipv6.he.net) |
| 13:45:51 | | Join scorche|sh [0] (~scorche@squisch.net) |
| 13:45:51 | | Join B4gder [0] (~daniel@rockbox/developer/bagder) |
| 13:45:51 | | Join jfc [0] (~john@pool-72-73-80-12.ptldme.east.myfairpoint.net) |
| 13:45:51 | | Join [fred] [0] (fred@81.169.178.40) |
| 13:46:47 | | Join _Zagor [0] (~bjst@giant.haxx.se) |
| 13:46:47 | | Quit _Zagor (Changing host) |
| 13:46:47 | | Join _Zagor [0] (~bjst@rockbox/developer/Zagor) |
| 13:47:22 | TheSeven | JdGordon: http://pastie.org/1620483 |
| 13:47:28 | | Nick _Zagor is now known as Zagor (~bjst@rockbox/developer/Zagor) |
| 13:48:37 | JdGordon | although the ordering is what might be interesting... it drops the server and continues to build, then the server comes back, tries to delete the build dir then asks for that build |
| 13:50:38 | | Join hebz0rl [0] (~hebz0rl@dslb-092-075-125-248.pools.arcor-ip.net) |
| 13:53:26 | | Join kronflux [0] (~kronflux@142.68.79.229) |
| 13:55:19 | | Join wodz [0] (~5f303f8a@giant.haxx.se) |
| 13:55:49 | wodz | n1s: About genlang - profiling will be the very first step: http://search.cpan.org/dist/Devel-NYTProf/lib/Devel/NYTProf.pm |
| 13:58:42 | CIA-70 | r29483 build result: 15 errors, 0 warnings (jdgordon committed) |
| 14:00 |
| 14:02:03 | CIA-70 | New commit by jdgordon (r29484): fix red |
| 14:05:14 | | Quit wodz (Quit: CGI:IRC) |
| 14:06:37 | | Join Sochiro [0] (~Sochiro@194.90.222.165) |
| 14:08:37 | CIA-70 | r29484 build result: All green |
| 14:12:54 | | Quit antil33t (Read error: Connection reset by peer) |
| 14:13:04 | | Join antil33t [0] (antil33t@124-197-51-80.callplus.net.nz) |
| 14:13:30 | | Quit shai (Ping timeout: 250 seconds) |
| 14:23:10 | | Quit francesco_ (Remote host closed the connection) |
| 14:25:47 | | Quit linuxguy3 (Read error: Operation timed out) |
| 14:29:50 | | Join linuxguy3 [0] (~timj@adsl-75-57-177-0.dsl.emhril.sbcglobal.net) |
| 14:32:21 | | Join ender| [0] (krneki@foo.eternallybored.org) |
| 14:34:18 | | Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) |
| 14:36:13 | | Quit krazykit (Quit: awe yeeeeeee) |
| 14:55:12 | | Quit Sochiro (Read error: Connection reset by peer) |
| 14:55:40 | | Join Sochiro [0] (~Sochiro@194.90.222.165) |
| 15:00 |
| 15:02:58 | | Join komputes [0] (~komputes@ubuntu/member/komputes) |
| 15:05:34 | | Join evilnick_B [0] (0c140464@rockbox/staff/evilnick) |
| 15:08:35 | | Quit Sochiro (Ping timeout: 240 seconds) |
| 15:15:06 | | Join LinusN [0] (~linus@giant.haxx.se) |
| 15:15:06 | | Quit LinusN (Changing host) |
| 15:15:06 | | Join LinusN [0] (~linus@rockbox/developer/LinusN) |
| 15:25:45 | | Join _jhMikeS_ [0] (~jethead71@adsl-99-65-125-116.dsl.sfldmi.sbcglobal.net) |
| 15:25:45 | | Quit _jhMikeS_ (Changing host) |
| 15:25:45 | | Join _jhMikeS_ [0] (~jethead71@rockbox/developer/jhMikeS) |
| 15:25:45 | | Quit jhMikeS (Disconnected by services) |
| 15:25:46 | | Nick _jhMikeS_ is now known as jhMikeS (~jethead71@rockbox/developer/jhMikeS) |
| 15:35:04 | | Quit linuxguy3 (Read error: Operation timed out) |
| 15:36:16 | | Join linuxguy3 [0] (~timj@adsl-75-57-176-170.dsl.emhril.sbcglobal.net) |
| 15:45:48 | *** | Saving seen data "./dancer.seen" |
| 15:47:02 | | Quit mudd1 (Quit: Ex-Chat) |
| 15:48:08 | | Quit linuxguy3 (Read error: Operation timed out) |
| 15:50:41 | | Join linuxguy3 [0] (~timj@adsl-76-202-209-207.dsl.emhril.sbcglobal.net) |
| 15:51:28 | | Join Sochiro [0] (~Sochiro@194.90.222.165) |
| 16:00 |
| 16:01:17 | | Quit n1s (Quit: Lämnar) |
| 16:02:04 | | Join panni_ [0] (hannes@ip-178-203-73-7.unitymediagroup.de) |
| 16:06:39 | | Quit FoolOnHill (Remote host closed the connection) |
| 16:06:59 | | Quit leavittx (Read error: Operation timed out) |
| 16:18:01 | | Quit sasquatch (Quit: WeeChat 0.3.2) |
| 16:18:26 | | Join sasquatch [0] (~username@p4FF2DC5D.dip.t-dialin.net) |
| 16:36:52 | | Part LinusN |
| 16:40:18 | | Join FoH [0] (~foh@adsl-71-69-118.bhm.bellsouth.net) |
| 16:41:09 | | Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201) |
| 16:51:36 | | Join Sochiro_ [0] (~Sochiro@194.90.222.165) |
| 16:51:45 | | Quit Xerion (Read error: Connection reset by peer) |
| 16:52:18 | | Quit pamaury (Remote host closed the connection) |
| 16:52:34 | | Join Xerion [0] (~xerion@5419A4D7.cm-5-2c.dynamic.ziggo.nl) |
| 16:55:26 | | Quit Sochiro (Ping timeout: 240 seconds) |
| 16:59:15 | | Part swilde ("ERC Version 5.3 (IRC client for Emacs)") |
| 17:00 |
| 17:00:57 | | Quit t0rc (Quit: Give someone code, help them with one project. Teach someone to code, help them rule the world.) |
| 17:02:56 | | Part Zagor |
| 17:03:21 | | Join user890104 [0] (~Venci@6bez10.info) |
| 17:04:00 | | Quit Sochiro_ (Read error: Connection reset by peer) |
| 17:04:25 | | Join Sochiro_ [0] (~Sochiro@194.90.222.165) |
| 17:07:09 | | Quit TheLemonMan (Quit: free(me)) |
| 17:11:10 | | Join toffe82 [0] (~chatzilla@maf.wirelesstcp.net) |
| 17:13:37 | | Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 17:15:07 | | Join pyro_maniac_ [0] (foobar@p4FC0166E.dip0.t-ipconnect.de) |
| 17:16:45 | | Quit Sochiro_ (Ping timeout: 240 seconds) |
| 17:19:06 | saratoga | TheSeven: the problem with AMSv2 USB seems to be that the controller isn't initialized or clocked right, and so occasionally drops the USB connection (IIRC) |
| 17:19:54 | | Quit antil33t (Read error: Connection reset by peer) |
| 17:20:06 | | Join antil33t [0] (antil33t@124-197-51-80.callplus.net.nz) |
| 17:20:46 | TheSeven | saratoga: but why would that cause a software lockup? |
| 17:21:19 | saratoga | i don't think it locks up |
| 17:21:30 | saratoga | i think the transfer just times out and the host resets the connection |
| 17:23:11 | | Nick tchan1 is now known as tchan (~tchan@c-69-243-144-187.hsd1.il.comcast.net) |
| 17:23:22 | | Quit tchan (Changing host) |
| 17:23:22 | | Join tchan [0] (~tchan@lunar-linux/developer/tchan) |
| 17:26:53 | TheSeven | saratoga: some hours earler someone claimed that they hard lock in a way where they can't even be rebooted, unless you let the battery run down |
| 17:27:21 | saratoga | that happened when we tried to reboot into the OF from rockbox to use its USB mode |
| 17:29:39 | TheSeven | huh? that chat sounded like we are rebooting into the OF to prevent exactly that behavior when trying to use RB usb |
| 17:29:45 | | Join sideral [0] (~sideral@rockbox/developer/sideral) |
| 17:30:33 | Torne | Oh, er, yes. i am mistaken :) |
| 17:30:45 | Torne | we are currently requiring that people manually boot the OF to get USB |
| 17:31:05 | Torne | because rebooting locks it up sometimes and using the rockbox usb stack is unreliable |
| 17:31:10 | saratoga | automatically rebooting tending to hard lock players |
| 17:31:21 | sideral | As a data point, I've been running my ClipV2 with enabled USB for more than a month now, and it's perfectly stable. Caveat: I needed to revert r29169 |
| 17:31:33 | saratoga | AFAIK USB transfers don't freeze the player, but they don't work all that well on a lot of systems, particularly windows IIRC |
| 17:32:24 | TheSeven | do we have more precise information about how those transfers fail? |
| 17:32:51 | TheSeven | is it CRC errors on the connection or similar things? or some higher-level problem? |
| 17:33:19 | TheSeven | also, which transfer directions are affected? |
| 17:33:35 | TheSeven | any difference between the two available drivers? |
| 17:33:36 | sideral | TheSeven: Don't think so. I remember people reporting the occasional "usual nonresponsive Windows system", and retrying the connection fixed it |
| 17:35:59 | saratoga | you should ping pamaury about it |
| 17:41:44 | sideral | saratoga: r29169 is jhMikeS' commit, and pamaury doesn't want to have anything to do with the SD driver :) |
| 17:45:30 | | Join Xerion_ [0] (~xerion@5419A4D7.cm-5-2c.dynamic.ziggo.nl) |
| 17:45:51 | *** | Saving seen data "./dancer.seen" |
| 17:47:37 | | Quit Xerion (Ping timeout: 276 seconds) |
| 17:47:39 | | Nick Xerion_ is now known as Xerion (~xerion@5419A4D7.cm-5-2c.dynamic.ziggo.nl) |
| 17:49:59 | | Quit timccc (Ping timeout: 252 seconds) |
| 17:51:29 | | Join u42p [0] (~v35b@d095083.adsl.hansenet.de) |
| 17:54:10 | | Join n1s [0] (~n1s@nl118-175-108.student.uu.se) |
| 17:54:10 | | Quit n1s (Changing host) |
| 17:54:10 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
| 17:54:15 | u42p | aloha. i half bricked my sansa clip+ or something. it was acting goofy the past days, not starting or hanging/crashing. this morning i had the great idea of using RockboxUtility (linux) to install the latest rockbox on it. the window kinda froze, the sansa said writing every now and then but it seemed to be very slow. well, i had to go so i killed it... i could boot the sansa firmware afterwards, gui froze every now and then but i could listen well |
| 17:54:16 | u42p | to music. |
| 17:54:47 | u42p | now the player was off over the day and wont display anything anymore. i held power or power+home for ages with no luck. if i plug it in i get "Disk /dev/sdf: 4 MB, 4231680 bytes" |
| 17:54:53 | u42p | "Disk /dev/sdf doesn't contain a valid partition table" |
| 17:55:08 | u42p | any idea how to recover from this? |
| 17:57:18 | gevaerts | u42p: http://www.rockbox.org/wiki/SansaAMSUnbrick may help |
| 17:57:29 | gevaerts | Be careful with those things though |
| 17:57:48 | u42p | i really really really do not want to open it up :\ |
| 17:59:43 | Torne | You don't have a choice. |
| 18:00 |
| 18:00:08 | Torne | Interrupting the flashing process is pretty much guaranteed to be fatal |
| 18:00:19 | Torne | to unbrick it you need to short two terminals inside. |
| 18:01:08 | | Quit Xerion (Quit: ) |
| 18:01:11 | u42p | i was not flashing the bootloader, so that might not be damaged |
| 18:01:25 | Torne | You must have been flashing the bootloader :) |
| 18:01:31 | | Join fkhodkov [0] (~fedor76@ppp-78-24-26-55-bras0.istra.ru) |
| 18:01:44 | Torne | the state it's in now is the state it goes into when it gets a bad flash |
| 18:01:54 | Torne | Pretty sure nothing else causes that |
| 18:01:57 | u42p | oh, i should have said. i used rockbox for ages on it. |
| 18:01:58 | * | TheSeven wonders what that 4MB volume is good for if it doesn't allow to recover |
| 18:01:59 | u42p | oh :( |
| 18:02:16 | Torne | TheSeven: It's probably the original DFU supported by the silicon |
| 18:02:32 | TheSeven | sounds like we should find a way to use it for our purposes |
| 18:02:38 | Torne | TheSeven: lots of people like to make devices where the actual boot flash is not the kind of device the SoC is intended to be used with |
| 18:03:06 | Torne | I suspect whatever mode that is, it's probably an on-chip rom that may well not have any clue how to write to the actual flash |
| 18:03:18 | Torne | there's probably another memory somewhere which has teh actual recovery mode in it |
| 18:03:26 | Torne | which is selected by shorting those pins |
| 18:04:15 | | Join krazykit [0] (~krazykit@99-126-205-52.lightspeed.cicril.sbcglobal.net) |
| 18:04:23 | Torne | alternatively it might be a two-stage thing where it expects to have a small recovery image written to it |
| 18:04:32 | Torne | which it then boots and presents a better recovery system. |
| 18:05:28 | Torne | the onchip rom might only be smart enough to let you write an image to RAM |
| 18:05:45 | TheSeven | Torne: aren't those SoCs documented? |
| 18:05:51 | Torne | er, maybe. |
| 18:06:00 | Torne | It's also possible that the situation is the other way around |
| 18:06:03 | TheSeven | and 4MB sounds like a ramdisk, yes |
| 18:06:08 | Torne | and the *working* recovery mode is the one in the bootrom |
| 18:06:18 | Torne | and the useless one is some stub on the actual firmware |
| 18:06:41 | Torne | which doesn't normally get overwritten/corrupted during flashing and thus ends up running by default if the main image is broken |
| 18:06:42 | TheSeven | how do we know that it's useless? |
| 18:06:48 | Torne | useless to us at present, then |
| 18:07:18 | Torne | what actually are the terminals that get shorted? |
| 18:07:44 | Torne | it's presumably connected to some kind of boot select pseudoregister, or to the flash (and thus shorting it kills the flash's ability to respond to reads) |
| 18:08:06 | TheSeven | has anyone dumped the content of that 4MB volume? |
| 18:08:16 | Torne | i hope so ;) |
| 18:08:18 | TheSeven | is it zeroed? random? or something static? |
| 18:08:32 | Torne | maybe i'll take my clipv2 apart sometime and see what i can work out |
| 18:08:36 | Torne | i never use it for anything |
| 18:09:01 | TheSeven | how stable is that unbricking method? |
| 18:09:12 | Torne | i don't think anyone who's actually tried it has failed |
| 18:09:14 | Torne | :) |
| 18:09:17 | TheSeven | is there a way to brick it even more, so that this shorting trick doesn't work any more? |
| 18:09:40 | TheSeven | I remember people jtagging these devices because that was the only means of access left |
| 18:10:32 | Torne | hm, maybe. |
| 18:10:41 | gevaerts | TheSeven: it took a while for people to discover those pins |
| 18:11:14 | Torne | so these devices have just one flash, and some portion of it is used as bootflash and is hidden from normal use? |
| 18:11:24 | TheSeven | apparently |
| 18:11:41 | TheSeven | I remember older sansas (pre-ams?) having some i2c flash as well |
| 18:12:01 | TheSeven | but that's probably a completely different story |
| 18:12:28 | Torne | so is anyone likely to know what those pins are actually connected to? |
| 18:12:39 | TheSeven | shouldn't be hard to figure that out |
| 18:12:43 | TheSeven | anyway, if someone throws a bricked sansa and a rom image of it at me, I'll see what I can do :) |
| 18:12:55 | TheSeven | there must be something useful we can do with that 4MB volume mode |
| 18:13:13 | Torne | well, funman or someone may know more |
| 18:13:17 | Torne | i'm curious now, tbh :) |
| 18:13:28 | TheSeven | it strongly smells like the UMSboot thing i've written for the ipods :) |
| 18:13:48 | TheSeven | just that mine works on top of FAT16 to make it more convenient |
| 18:16:53 | | Quit aevin (Ping timeout: 240 seconds) |
| 18:16:53 | u42p | i guess the player needs to be glued together after taking it apart? |
| 18:18:22 | | Quit [Saint] (Ping timeout: 264 seconds) |
| 18:18:41 | Torne | the as3525 manual mentions how the internal boot thing works vaguely |
| 18:19:01 | Torne | it doesn't actually explain how the usb boot prommer mode works, only what bits to set to enter it. |
| 18:19:12 | | Join [Saint] [0] (S_a_i_n_t@203.184.0.44) |
| 18:19:13 | Torne | so i think my first guess is right, one way around or the other |
| 18:19:28 | Torne | there's a stub in the NAND which doesn't get touched by a normal flash |
| 18:19:31 | Torne | probably. |
| 18:19:39 | | Part rasher |
| 18:19:44 | | Join rasher [0] (~rasher@rockbox/developer/rasher) |
| 18:21:40 | | Join Xerion [0] (~xerion@5419A4D7.cm-5-2c.dynamic.ziggo.nl) |
| 18:23:39 | TheSeven | Torne: do you know how we are writing firmware? |
| 18:23:49 | Torne | hm? |
| 18:23:55 | Torne | you mean when we do a normal upgrade? |
| 18:24:03 | TheSeven | do we access the flash directly? or do we update it through the OF somehow? |
| 18:24:05 | Torne | the existing firmware does it for us |
| 18:24:12 | Torne | detects presence of file on usb unplug |
| 18:24:33 | TheSeven | how can we brick them that way then? |
| 18:24:50 | TheSeven | wouldn't the OF do some CRC check or something with the firmware file dropped onto it before flashing it? |
| 18:24:57 | Torne | You might think |
| 18:24:59 | Torne | I have no idea. |
| 18:25:15 | | Join leavittx [0] (~lev@89.221.199.187) |
| 18:25:27 | TheSeven | a half-written firmware file certainly is no rare problem |
| 18:25:39 | TheSeven | no way such a thing can brick a device |
| 18:25:52 | Torne | i'm not sure i'd assume that :) |
| 18:26:28 | TheSeven | btw, is this a raw nand chip or some kind of emmc? |
| 18:26:39 | TheSeven | the package looks like just nand |
| 18:27:04 | TheSeven | is there some hardware bridge in between, or is there no wear leveling at all? |
| 18:27:52 | Torne | it's an eMMC |
| 18:28:02 | Torne | or at least has the interface of one |
| 18:28:56 | Torne | not all eMMC chips are equal :) |
| 18:29:05 | Torne | some have magic hidden boot areas and the like |
| 18:29:16 | TheSeven | why does an emmc have that many pins? |
| 18:29:41 | Torne | maybe there's an interface inbetween somewhere |
| 18:29:47 | Torne | or maybe the SoC itself has that logic in. |
| 18:30:05 | Torne | the datasheet is terrible |
| 18:31:20 | Torne | ask someone who actually knows about the port :) |
| 18:32:34 | Torne | so yeah. the part is a regular ONFI NAND part |
| 18:32:37 | | Join LambdaCalculus37 [0] (~3f74f70d@rockbox/staff/LambdaCalculus37) |
| 18:32:44 | Torne | but we definately drive it using an SD interface |
| 18:34:25 | | Join Stummi [0] (~Stummi@rockbox/developer/Stummi) |
| 18:35:06 | Torne | I would guess that Sandisk's ASIC has one of their own flash controllers onboard |
| 18:35:43 | TheSeven | do they have some asic on board? i thought it was just some standard soc from ams? |
| 18:36:00 | TheSeven | or do you mean a different chip? |
| 18:36:01 | Torne | The SoC is the ASCI |
| 18:36:08 | Torne | it's not an actual AMS part |
| 18:36:17 | Torne | it'll be based on the AMS soft IP |
| 18:36:25 | Torne | so, customised any way sandisk feel like |
| 18:36:30 | | Join Sochiro_ [0] (~Sochiro@194.90.222.165) |
| 18:36:37 | TheSeven | hm, so a similar mess like those Samsung S5L87xx things |
| 18:36:48 | | Quit MagusG (Read error: Connection reset by peer) |
| 18:36:49 | Torne | large vendors like that never actually use the *parts* from SoC vendors |
| 18:36:51 | | Join MagusG [0] (magusg@c-71-59-57-46.hsd1.ga.comcast.net) |
| 18:37:00 | Torne | they just make their own ASIC from the silicon IP |
| 18:37:19 | Torne | so yeah, that's a *third* possible source for the alternate recovery/flash mode |
| 18:37:42 | Torne | the chip might actually have *two* bootroms in it, one from the AMS design and one added by Sandisk |
| 18:38:35 | Torne | in which case yeah. the AMS manual makes no reference to being able to boot directly from SD/MMC. |
| 18:39:23 | Torne | so it wouldn't be surprising if it also can't write to SD/MMC in its USB prommer mode |
| 18:39:27 | TheSeven | do you happen to have a link to that manual around? |
| 18:39:48 | TheSeven | Torne: I've rarely ever seen DFU modes really write to flash |
| 18:39:58 | Torne | Yah, but it's not DFU |
| 18:40:02 | TheSeven | most of them operate on ramdisks that are then booted and do the actual flashing operation |
| 18:40:06 | Torne | DFU is a standard protocol |
| 18:40:27 | TheSeven | yeah, but it's for a similar purpose in a similar situation, so it will probably use a similar approach |
| 18:40:43 | TheSeven | you usually don't trust the flash access layer at that stage |
| 18:40:45 | Torne | the tiny amount of text in the AMS manual suggests that it is literally a flashprogrammer |
| 18:40:53 | Torne | i.e. it's for manufacturing, not recovery |
| 18:41:02 | TheSeven | if you decide to use a different flash chip, you might have to make new asic masks |
| 18:41:16 | TheSeven | manufacturers usually don't like that :) |
| 18:41:18 | Torne | http://www.austriamicrosystems.com/eng/content/download/16763/295720/467 is the thing i'm looking at |
| 18:41:39 | Torne | Well, there *are* versions of the clip/etc that are different ASICs, it seems |
| 18:41:49 | | Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) |
| 18:41:53 | Torne | note the wiki: teh sd device identifies itself differently on different devices |
| 18:42:05 | Torne | which suggests that the silicon that's presenting the NAND as if it were SD is not the same |
| 18:42:34 | Torne | also i think you have entirely too rational assumptions about the motivations of ASIC designers :0 |
| 18:44:37 | | Quit sideral (Quit: Leaving.) |
| 18:45:37 | TheSeven | sounds like we should have a look at a dump of that on-chip rom |
| 18:45:46 | TheSeven | that will most certainly provide some more detailed information |
| 18:47:23 | Torne | I don't know about the AMS but normally they are undumpable |
| 18:47:38 | * | TheSeven doubts that |
| 18:47:46 | Torne | Most SoCs use their bootrom as the anchor for their secure boot chain of trust |
| 18:47:51 | TheSeven | even those apple SoC's roms are dumpable! |
| 18:48:14 | Torne | really? that's odd. |
| 18:48:16 | TheSeven | accessing the ROM doesn't break the chain of trust if it's implemented correctly |
| 18:48:30 | Torne | TheSeven: ..and? :) |
| 18:49:01 | TheSeven | is there even a way to hide a ROM away? |
| 18:49:12 | Torne | anyway, most SoCs i've worked with not only is it impossible to dump the rom, but even the *interface8 to the rom is super confidential and secret and isn't in the regular docs, requiring special contracts to read |
| 18:49:26 | Torne | Of course there is |
| 18:49:42 | TheSeven | well, maybe by setting some kill-bit in the SoC that removes access to it once it's finished |
| 18:49:46 | Torne | hack the silicon that implements the bus |
| 18:50:10 | TheSeven | apple actually had that kind of thing for the hardware AES keys, but they didn't bother using it :) |
| 18:50:27 | Torne | The GBA only lets you read from ROM when the program counter is inside the ROM :) |
| 18:50:36 | Torne | that one was entertaining |
| 18:50:59 | Torne | on modern ARMs the bootrom is normally only accessible in secure mode |
| 18:51:09 | Torne | which is a much easier and more reliable way of doing it |
| 18:51:09 | TheSeven | you can't do that kind of hack without modifying the ARM core, and sandisk doesn't have a license for that |
| 18:51:20 | Torne | TheSeven: You can if you have an ancient ARM with no cache |
| 18:51:33 | Torne | you can have the rom itself detect the isntruction fetches to know where the PC is :) |
| 18:52:09 | TheSeven | are people designing that kind of thing masochists? |
| 18:52:28 | Torne | I suspect so, but Nintendo did it anyway |
| 18:52:42 | Torne | And then forgot to bounds check the MIDI key number to frequency conversion table |
| 18:52:47 | TheSeven | well, DAP OS developers are lazy, we know that |
| 18:52:59 | Torne | so you can dump teh whole rom in a mangled roundabout fashion by asking for unusually high/negative MIDI key numbers |
| 18:53:04 | TheSeven | so the OF will probably running in the secure world's supervisor mode all the time (at least apple did that) |
| 18:53:14 | Torne | AS3525 is ARM9, nos ecure mode anyway |
| 18:53:16 | TheSeven | I would be very surprised if we can't get at that rom somehow |
| 18:53:35 | Torne | only ARM1176 and later has secure mode. |
| 18:53:54 | Torne | TheSeven: There is another option, actually ;) |
| 18:54:04 | Torne | The rom might not be *in the physical memory map* when it's not selected as the boot source |
| 18:54:16 | Torne | the internal/external boot switch might actually just disconnect the rom from the bus entirely. |
| 18:54:29 | Torne | and if itnernal boot doesn't go anywhere useful that you can run code in, there's then no way to dump it |
| 18:54:36 | Torne | without anyone making any deliberate attempt to make it hard. |
| 18:55:24 | Torne | some of these boot roms work by overriding what would normally be at physical address 0 |
| 18:55:26 | TheSeven | i'd assume that it always boots from the internal rom |
| 18:55:41 | Torne | you're *probably* wrong. |
| 18:55:48 | Torne | It has a switch for it |
| 18:56:05 | Torne | booting from external would require something attached that was sufficiently memorylike to be used by a GPMC |
| 18:56:17 | Torne | but whatever mystical device it is that's doing the nand->sd remap might include one |
| 18:56:28 | Torne | since that's a pretty standard thing to do for diskonchip type stuff. |
| 18:56:49 | Torne | the internal rom doesn't know how to boot from SD either, so unless sandisk modified it it wouldn't be any use |
| 18:56:53 | * | TheSeven suspects that the internal rom is just reading the OF through the SD interface |
| 18:57:07 | Torne | Well, the docs don't lsit that as a boot option |
| 18:57:19 | Torne | so, sandisk would've had to have modified it probably |
| 18:57:20 | TheSeven | i strongly assume that they modified it in one way or another, if they did their own SoC anyway |
| 18:58:07 | Torne | i seriously think it'sm ore likely that the internal boot rom is just ignored entirely and whatever block implements teh SD interface to flash also offers itself as a bootable memory device |
| 18:58:19 | Torne | whcih probably just reads sector 0 from the flash into a boot memory |
| 18:58:37 | Torne | there's loads of boot flash devices that are actualyl NAND and just load the first sector of the NAND into a temporary memory to fake being real mapped memory |
| 18:58:50 | Torne | so that a "dumb" processor can boot off them directly withotu needing a smart bootrom |
| 18:59:16 | | Join ajb_oe [0] (~user@cbnluk-gw0.cambridgebroadband.com) |
| 18:59:44 | Torne | people who make ASICs arrange this stuff based on "what copypastable blocks do we already have" |
| 18:59:48 | Torne | not what's actually a clean design |
| 18:59:49 | | Part ajb_oe |
| 19:00 |
| 19:00:20 | Torne | anyway. maybe someone knows already. |
| 19:00:38 | Torne | so it's probably easier to check if they do rather than speculating :) |
| 19:00:52 | Torne | Knowing what the recovery thing is connected to would be a good hint |
| 19:01:06 | Torne | if it's connected to one of the boot select pins documented in the as3525 manual then that's a big hint :0 |
| 19:01:17 | saratoga | TheSeven: i believe shorting those pins actually powers down teh NAND chip, and the disk you see is the rom on the SOC going into some kind of failsafe mode |
| 19:01:27 | saratoga | when it can't init the NAND chip |
| 19:01:35 | saratoga | thats why you short it, then quickly unshort it as it boots |
| 19:01:38 | Torne | saratoga: yes, but that could be more than one choice of what "rom" is doing it |
| 19:03:13 | saratoga | anyway, given how simple the SOC is, i suspect you can just read out the ROM over jtag if you really want |
| 19:03:51 | Torne | yes, someone with jtag set up could just look and see what it does. |
| 19:05:33 | | Join pamaury [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net) |
| 19:05:34 | | Quit pamaury (Changing host) |
| 19:05:34 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 19:08:02 | saratoga | In the case that a USB connection is present and either an update button is pressed or there is no bootable device, the USB promer is started (see Figure 7 Boot decision between normal boot and USB boot promer†for details). The USB boot promer allows update of the firmware by using an USB mass storage class device. This update can be used either for initial programming (factory programming) or as mechanism for an in-field firmwa |
| 19:08:08 | saratoga | sounds like thats the mode we end up in by shorting those pins |
| 19:08:10 | * | TheSeven has a jtag adapter, but no sansa |
| 19:08:28 | Torne | saratoga: Except the bootrom described there doesn't know how to boot from SD/MMC |
| 19:08:38 | Torne | so it's very unlikely that it knows how to write to SD/MMC either :) |
| 19:09:04 | Torne | so either there's an external rom which is the real boot device, or the internal rom runs something written by sandisk instead and thus the manual doesn't apply |
| 19:09:28 | Torne | or something much weirder is going on |
| 19:10:02 | saratoga | they customized the chip, so they probably updated the bootloader to work with the SD controller |
| 19:10:06 | saratoga | they'd have to right? |
| 19:10:09 | Torne | no |
| 19:10:14 | Torne | you just turn it off |
| 19:10:22 | Torne | and have the SD interface also be a boot flash |
| 19:10:39 | Torne | because that's probably a piece of silicon IP you already have lying around |
| 19:10:43 | saratoga | how would the bootloader get code off the SD interface if it didn't know how to talk to it? |
| 19:10:53 | Torne | You don't use the bootloader |
| 19:11:02 | Torne | You just have the chip boot directly from whatever is at physical address 0 |
| 19:11:11 | Torne | the onchip bootrom is optional |
| 19:11:18 | TheSeven | saratoga: using some steppingstone-like construct, that loads the first SD block into some internal RAM and emulates that as an external ROM to boot from |
| 19:11:44 | TheSeven | the code in that first block will then setup the SD controller and possibly SDRAM and load more code |
| 19:11:45 | | Quit linuxguy3 (Ping timeout: 264 seconds) |
| 19:11:57 | saratoga | well either way that construct is going to have to end up on the SOC's internal memory unless their SD controller is intelligent enough to memory map things into the CPU without any asisistance |
| 19:12:10 | Torne | saratoga: Yes, it probably is |
| 19:12:17 | Torne | There are loads of NAND flash controllers that are that smart |
| 19:12:20 | Torne | It's a common block :) |
| 19:12:47 | Torne | and it's often easier to just copypaste soemthing liek that into your design rather than go anywhere near touching the existing boot logic in a SoC design you licensed |
| 19:13:01 | Torne | It's not really an SD controller, remember |
| 19:13:07 | Torne | The SoC alerady has an SD controller |
| 19:13:13 | | Join linuxguy3 [0] (~timj@adsl-75-57-170-64.dsl.emhril.sbcglobal.net) |
| 19:13:20 | saratoga | so you think the code we end up in for recovery mode is just the start of the NAND? |
| 19:13:27 | Torne | the extra block of logic that must be there somewhere is implementing an SD card interface using a NAND flash |
| 19:13:40 | Torne | it could trivially also implement a bootflash interface. |
| 19:14:01 | Torne | I think *one* of the two modes you can boot into when it's bricked is just the start of the NAND. |
| 19:14:10 | Torne | Maybe it'st he one you can recover from, maybe it's the one that doesn't seem to be usable |
| 19:14:49 | Torne | So yes, if shorting the pins just cripples the NAND then maybe *not* shorting the pins gives you whatever's at the start of the NAND and that's a bit of logic that is either nonfunctional or we just don't know how to talk to it right |
| 19:15:01 | Torne | whereas if you cripple the nand you get something that's actually in a ROM somewhere |
| 19:15:29 | Torne | anyway. my point was there's a very large number of ways this could be implemented and even really illogical seeming ones are quite plausible/likely |
| 19:15:34 | * | TheSeven wonders if anyone has tried just slapping arbitrary data at that 4MB volume |
| 19:15:44 | Torne | so if we want to know someone should actually experiment |
| 19:15:53 | Torne | TheSeven: i would hope so |
| 19:16:19 | Torne | JTAG is probably the best way to try this if possible, since you can just trap reset and walk throught he entire boot process |
| 19:17:18 | Torne | but a handy shortcut to narrow down the possibilities would be if someone knows what the pins-to-be-shorted are actually connected to |
| 19:17:21 | TheSeven | well, I've managed to do so on locked-down devices that don't even have working jtag, so with jtag it should be piece of cake |
| 19:17:21 | Torne | :) |
| 19:21:16 | | Quit DerPapst (Quit: Leaving.) |
| 19:25:04 | | Quit tchan (Quit: WeeChat 0.3.4) |
| 19:25:14 | | Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) |
| 19:26:12 | | Quit LambdaCalculus37 (Quit: back to work!) |
| 19:29:40 | saratoga | TheSeven: you should probably try and get an e200v2 then since its the easiest to jtag |
| 19:30:01 | | Join tchan [0] (~tchan@lunar-linux/developer/tchan) |
| 19:30:07 | TheSeven | easiest in terms of connecting? |
| 19:30:09 | | Join Keripo [0] (~Keripo@SEAS358.wlan.seas.upenn.edu) |
| 19:35:10 | saratoga | yeah |
| 19:35:16 | saratoga | the solder points are fairly large |
| 19:35:21 | saratoga | i think the m200v4 is similar |
| 19:35:28 | saratoga | the clip has a tiny board with tiny, tiny points |
| 19:38:54 | TheSeven | well, I've managed to solder inside an ipod nano 2g, that can't be much worse |
| 19:43:21 | saratoga | are you in the EU or US? I could probably just send you my old e200v2 |
| 19:43:57 | | Join stoffel [0] (~quassel@p57B4A101.dip.t-dialin.net) |
| 19:45:52 | *** | Saving seen data "./dancer.seen" |
| 19:47:09 | | Quit linuxguy3 (Ping timeout: 264 seconds) |
| 19:49:01 | | Join linuxguy3 [0] (~timj@adsl-76-202-208-17.dsl.emhril.sbcglobal.net) |
| 19:55:22 | | Join DerPapst [0] (~Alexander@p4FE8FC61.dip.t-dialin.net) |
| 19:56:38 | [Saint] | TheSeven: You're quite correct...you soldered a pad in the Nano2G...jtag in this case can't be much worse, if at all. |
| 19:57:12 | [Saint] | just, more of them. |
| 19:59:14 | TheSeven | saratoga: germany |
| 19:59:37 | TheSeven | [Saint]: swapping the NAND certainly *is* worse though |
| 19:59:55 | [Saint] | Ok, yess..indeed. ;) |
| 20:00 |
| 20:00:25 | [Saint] | And I'll quite happily tell anyone that mentions that very thing to avoid it at all costs if they're considering it :P |
| 20:00:45 | [Saint] | s/Ok/Oh/ |
| 20:05:00 | | Join Zagor [0] (~bjst@rockbox/developer/Zagor) |
| 20:05:27 | | Quit Sochiro_ (Ping timeout: 240 seconds) |
| 20:05:41 | | Quit stoffel (Remote host closed the connection) |
| 20:14:18 | | Join kevku [0] (~kevku@2001:7d0:0:f9af:feed:feed:feed:feed) |
| 20:17:16 | | Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) |
| 20:21:40 | | Quit Zarggg (Quit: Zarggg) |
| 20:28:30 | | Nick kugel_ is now known as kugel (~kugel@rockbox/developer/kugel) |
| 20:29:34 | | Join sideral [0] (~sideral@rockbox/developer/sideral) |
| 20:34:06 | | Quit saratoga (Ping timeout: 272 seconds) |
| 20:38:41 | | Quit benedikt93 (Ping timeout: 246 seconds) |
| 20:41:04 | | Join TheLemonMan [0] (~lem0n@ppp-135-147.98-62.inwind.it) |
| 20:41:41 | | Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) |
| 20:42:58 | | Quit Keripo (Quit: Leaving.) |
| 20:43:34 | gevaerts | hrmm |
| 20:44:20 | gevaerts | kugel: do I guess right when I suspect that make apk needs make and make zip first mainly because it needs the zip and make zip doesn't force a build? |
| 20:45:23 | kugel | the reason is that make zip forces libmisc.so to be unpacked on start up, very annoying during development |
| 20:46:00 | kugel | make apk only makes the binary and re-uses the existing zip |
| 20:47:36 | gevaerts | I know what it does :) |
| 20:47:59 | gevaerts | I just want to understand what would need to be done to get the build system to build it |
| 20:48:27 | gevaerts | (step one: make sure it compiler :) |
| 20:48:32 | kugel | make zip doesn't force a build because it has no dependencies. if it had could work without make zip |
| 20:49:46 | kugel | I suppose we could have a new make zipapk which always makes zip (or repurpose make apk, but still retain the current behavior with another target) |
| 20:49:54 | kugel | is the apk the problem, or the 3 steps? |
| 20:50:11 | gevaerts | the three steps, mainly. I think |
| 20:50:33 | gevaerts | "Normal" builds run make and make zip, and then upload the zip |
| 20:50:49 | gevaerts | We could add a special case to the script of course... |
| 20:53:08 | | Quit pamaury (Ping timeout: 272 seconds) |
| 20:53:42 | | Join L-Strife89 [0] (~Strife89@207.144.201.128) |
| 20:54:20 | gevaerts | kugel: by the way, are you aware that it currently doesn't build? |
| 20:54:22 | u42p | i am this close to ordering a new clip+, dammit, why did i rush things in the morning... |
| 20:54:31 | kugel | gevaerts: no |
| 20:54:44 | gevaerts | kugel: it seems to be missing sys_poweroff() |
| 20:55:14 | Zagor | gevaerts: my modified rockbuild version has a more generic build command line |
| 20:55:38 | gevaerts | Zagor: ah, so we could do make && make zip && make apk? |
| 20:55:42 | Zagor | yes |
| 20:55:57 | gevaerts | ok, then we probably should migrate |
| 20:55:58 | Torne | why doesn't make zip depend on having done a build, anyway? |
| 20:56:08 | Torne | that seems bad |
| 20:56:25 | gevaerts | Torne: because that makes building with broken source impossible :) |
| 20:56:56 | * | Torne is personally a fan of makefiles which guarantee exactly correct output all the time :) |
| 20:56:58 | gevaerts | Basically because it's annoying that make zip doesn't work while you're trying to get plugins to build on a new port |
| 21:00 |
| 21:02:09 | | Join Zarggg [0] (~zarggg@24.229.139.169.res-cmts.sm.ptd.net) |
| 21:04:22 | gevaerts | thomasjfox: you broke the android build with r29467 |
| 21:04:37 | | Quit fyrestorm (Quit: Ur skills' fireproof like a wooden panel -- U got feds talking leet on your IRC channel!) |
| 21:05:15 | gevaerts | android doesn't do sys_poweroff() |
| 21:05:53 | thomasjfox | gevaerts: Ups. Is there an alternative or should we just add a stub for now? |
| 21:06:06 | gevaerts | no idea. Discuss with kugel I'd say :) |
| 21:06:19 | thomasjfox | kugel to the rescue! |
| 21:07:32 | kugel | does the sleep timer work now? |
| 21:08:16 | thomasjfox | kugel: Still needs the power thread to work properly. Just did a quick hack in my local tree yesterday |
| 21:08:42 | thomasjfox | kugel: Though I'm still thinking what code we would put in the dedicated power thread |
| 21:10:26 | kugel | stubbing sys_poweroff is fine |
| 21:11:24 | * | gevaerts doesn't like things that work by coincidence... |
| 21:12:12 | kugel | thomasjfox: you can also move the sys_poweroff() in powermgmt.c down so it's seen by the app ports |
| 21:12:18 | gevaerts | Right now arm and android seem to be able to coexist because our toolchain is prefixed with arm-elf-eabi while android has arm-eabi |
| 21:12:31 | gevaerts | That sounds *just* a bit too fragile to me |
| 21:12:40 | thomasjfox | kugel: That's what I wanted to try ;) |
| 21:13:10 | * | thomasjfox just installed meego as my SD card arrived today. New target? ;) |
| 21:13:19 | kugel | gevaerts: android has arm-linux-androideabi- |
| 21:13:24 | gevaerts | oh |
| 21:13:33 | gevaerts | I looked in the wrong directory then... |
| 21:13:39 | TheSeven | sounds safer :) |
| 21:13:39 | kugel | arm-eabi is from the old ndk, that's obsolete |
| 21:14:17 | gevaerts | That's fine then |
| 21:14:45 | kugel | android-linux-androideabi- is almost upstream gcc (with a few patches, including the android target) backported from 4.5/6 |
| 21:14:47 | | Join Stephen___ [0] (~S@86.45.50.21) |
| 21:15:33 | gevaerts | I wonder if we could just have the build network *build* the android bits (i.e. the standard make), without uploading. That would only require one more architecture string in the server, and of course build clients exporting ANDROID_NDK_PATH |
| 21:15:51 | gevaerts | At least we'd get notice on breakages then |
| 21:16:18 | | Quit L-Strife89 (Quit: Standby) |
| 21:16:37 | | Quit benedikt93 (Quit: Bye ;)) |
| 21:19:50 | TheSeven | gevaerts: what about doing the signing stuff on the build server? |
| 21:20:09 | gevaerts | TheSeven: that would be out of scope :) |
| 21:21:57 | gevaerts | I'm just thinking that one of the reasons that we don't have android autobuilt is that we seem to always want to cover the entire chain from source to market in one go. I'm basically proposing to break it down into simple steps |
| 21:24:23 | u42p | TheSeven: unless my clip+ magically starts working again in the next few days, you will receive it ;-} |
| 21:24:44 | TheSeven | u42p: where are you located? |
| 21:24:48 | u42p | hamburg |
| 21:24:55 | TheSeven | that sounds like a plan then :) |
| 21:25:02 | u42p | yeah, just ordered a new one |
| 21:27:14 | | Quit [fred] (Remote host closed the connection) |
| 21:30:51 | | Join [fred] [0] (fred@ircop.efnet.at) |
| 21:31:33 | * | thomasjfox is looking forward to android in the build system |
| 21:34:23 | | Join pamaury [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net) |
| 21:34:23 | | Quit pamaury (Changing host) |
| 21:34:23 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 21:34:41 | CIA-70 | New commit by thomasjfox (r29485): Expose sys_poweroff() and cancel_shutdown() to RaaA. Hopefully fixes android build |
| 21:36:10 | CIA-70 | r29485 build result: 15 errors, 3 warnings (thomasjfox committed) |
| 21:37:58 | | Join Sochiro_ [0] (~Sochiro@194.90.222.165) |
| 21:45:53 | *** | Saving seen data "./dancer.seen" |
| 21:50:03 | | Quit Stummi (Quit: Bye!) |
| 21:51:03 | | Quit u42p (Quit: Leaving) |
| 21:52:49 | | Join dfkt|x [0] (~dfkt@chello062178002170.1.11.univie.teleweb.at) |
| 21:52:49 | | Quit dfkt|x (Changing host) |
| 21:52:49 | | Join dfkt|x [0] (~dfkt@unaffiliated/dfkt) |
| 21:57:07 | | Quit Zarggg (Quit: Zarggg) |
| 22:00 |
| 22:01:39 | | Quit Stephen___ (Read error: Connection reset by peer) |
| 22:02:09 | | Quit dfkt|x (Remote host closed the connection) |
| 22:05:08 | | Quit tchan (Quit: WeeChat 0.3.4) |
| 22:06:57 | CIA-70 | New commit by thomasjfox (r29486): Fix red |
| 22:09:01 | | Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 22:09:01 | | Quit bertrik (Changing host) |
| 22:09:01 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 22:10:07 | | Quit [Saint] (Disconnected by services) |
| 22:10:09 | | Join S_a_i_n_t [0] (S_a_i_n_t@203.184.2.85) |
| 22:11:33 | | Quit Sochiro_ (Ping timeout: 264 seconds) |
| 22:12:01 | CIA-70 | r29486 build result: 15 errors, 3 warnings (thomasjfox committed) |
| 22:19:38 | CIA-70 | New commit by thomasjfox (r29487): Fix red - 2nd try. Use same ifdef style as in firmware/drivers/pcf50606.c |
| 22:19:47 | | Join mystica555_ [0] (~mike@71-208-201-1.hlrn.qwest.net) |
| 22:22:02 | | Join sampattuzzi [0] (~sam@global-1-100.nat.csx.cam.ac.uk) |
| 22:24:31 | CIA-70 | r29487 build result: All green |
| 22:24:31 | | Quit factor (Read error: Connection reset by peer) |
| 22:26:11 | | Join factor [0] (~factor@75.108.68.114) |
| 22:26:55 | | Quit Rob2223 (Read error: Connection reset by peer) |
| 22:27:09 | | Join Rob2222 [0] (~Miranda@p4FFF26BD.dip.t-dialin.net) |
| 22:27:54 | | Quit leavittx (Ping timeout: 250 seconds) |
| 22:30:40 | | Join Keripo [0] (~Keripo@SEAS015.wlan.seas.upenn.edu) |
| 22:41:44 | | Join aevin [0] (eivindsy@unaffiliated/aevin) |
| 22:44:42 | | Join Jerom [0] (~jerome@79.132.59.245) |
| 22:45:07 | | Join gamefreak264 [0] (~KING@unaffiliated/gamefreak264) |
| 22:46:19 | | Quit maraz (Ping timeout: 240 seconds) |
| 22:46:28 | | Join mudd1 [0] (~cmertes@ip-78-94-203-49.unitymediagroup.de) |
| 22:46:56 | gamefreak264 | Is one likely to get better or worse battery life on the 5.5G iPod on rockbox firmware than default? |
| 22:47:15 | | Join maraz [0] (maraz@kapsi.fi) |
| 22:51:32 | | Quit evilnick_B (Ping timeout: 272 seconds) |
| 22:52:02 | | Quit pamaury (Remote host closed the connection) |
| 22:53:07 | | Quit bicyclerepairman (Ping timeout: 240 seconds) |
| 22:53:36 | | Join bicyclerepairman [0] (~Sam@2.100.254.232) |
| 22:56:13 | Llorean | gamefreak264: I think we expect better battery life now, assuming similar use patterns. |
| 22:56:35 | Llorean | Some people switch to Rockbox but also take advantage of lossless files, or caption backlights, or other things that end up using a lot more battery life. |
| 22:56:58 | gamefreak264 | Llorean: Well, I was mostly intending to playback oggs and MP3 files |
| 22:57:42 | gamefreak264 | up until a month or so ago I was using my Sansa Clip on default firmware for that, but now that it's lost my library is mostly unplayable due to it being ogg |
| 22:58:36 | gamefreak264 | I thought that my old iPod on rockbox would be a good substitute |
| 22:59:09 | n1s | it should play mp3 and ogg vorbis efficiently |
| 22:59:13 | gamefreak264 | Llorean: Also, thanks for the swift response |
| 22:59:40 | n1s | battery time with aac would probably be slightly worse |
| 23:00 |
| 23:00:11 | gamefreak264 | By the way, is there any way to play back audible files in Rockbox or would I have to dual boot or something? |
| 23:00:26 | gamefreak264 | I'm assuming it's propritary so it's a no-go |
| 23:00:28 | Llorean | Dual boot. |
| 23:00:36 | Llorean | It's not just proprietary, it's encrypted and we can't do DRM. |
| 23:02:19 | gamefreak264 | " Very stable. Is lacking support for the video decoder chip. " Does this mean video playback would suck up extra battery life or be hiccup-y or what? |
| 23:02:25 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 23:02:55 | Llorean | Probably a bit of both |
| 23:03:05 | Llorean | And we can't do AVC video, only MPEG1/2 like other Rockbox players |
| 23:04:18 | thomasjfox | gevaerts: Where would we add Meego/Pandora packaging specific files in rockbox? I don't want to pollute the top level source directory |
| 23:04:52 | | Quit Keripo (Quit: Leaving.) |
| 23:05:14 | gamefreak264 | thomasjfox: What's the benefit of running rockbox on something like a Pandora over say mplayer or cmus or whatever? |
| 23:05:24 | | Quit bertrik (Quit: :tiuQ) |
| 23:06:15 | gevaerts | gamefreak264: that's an interesting question, but let me ask another one: what's the advantage of running mplayer or cmus or whatever over say rockbox? :) |
| 23:06:18 | thomasjfox | gamefreak264: All the features that make rockbox great on other platforms, too: Support for 20+ codecs, gapless, crossfade, browse by folders or database, highly themable and so on |
| 23:06:37 | thomasjfox | gevaerts: how about "packaging"? |
| 23:06:54 | | Quit stripwax (Client Quit) |
| 23:07:16 | gamefreak264 | thomasjfox: I don't actually have any experience with rockbox first hand, I've kind of been following the project from a distance for a few years, but never actually ried it |
| 23:07:23 | gamefreak264 | *tried |
| 23:07:28 | thomasjfox | gevaerts: I also thought we could move the "debian" directory in there and have a "make maemo" copy it from packaging/maemo to debian/ during the build process |
| 23:07:59 | gevaerts | thomasjfox: making directories in the root during build is *ugly*... |
| 23:08:06 | gevaerts | thomasjfox: I really don't know enough about meego and pandora packaging systems to have a serious idea |
| 23:08:26 | thomasjfox | gevaerts: All of them need some platform specific support file |
| 23:08:38 | thomasjfox | gevaerts: Some kind of "how do I packages this" file |
| 23:08:59 | gevaerts | thomasjfox: well yes, but is it one file, or several, and does the packaging system care where they are? |
| 23:09:06 | thomasjfox | gamefreak264: There are packages for android or maemo (Nokia N900) if that is any help |
| 23:09:32 | thomasjfox | gevaerts: for the Pandora it's maybe four files |
| 23:09:48 | thomasjfox | gamefreak264: So you could try it without flashing anything |
| 23:09:52 | gamefreak264 | thomasjfox: I was actually considering putting it on my 5th gen ipod, don't know if you saw that |
| 23:09:56 | thomasjfox | gevaerts: Meego will be about the same |
| 23:10:06 | gamefreak264 | Is it just in the android market or do I need to look elsewhere? |
| 23:10:15 | thomasjfox | gamefreak264: I never tried rockbox on real hardware :o) |
| 23:11:18 | gamefreak264 | thomasjfox: I thought you were a developer! :O |
| 23:11:40 | gamefreak264 | I actually was inspired to come here after I saw your part message on #openpandora |
| 23:11:45 | gamefreak264 | and your little cloak |
| 23:12:04 | gevaerts | gamefreak264: developers develop. If you want people who actually *use* it, you need users :) |
| 23:12:29 | gamefreak264 | Personally, I tend to only want to develop stuff that I use myself :P |
| 23:12:39 | thomasjfox | gamefreak264: Well, I have a .pnd for it ;) |
| 23:12:49 | gevaerts | Seriously though, thomasjfox only works on Rockbox as an Application, not on regular DAPs |
| 23:12:58 | gamefreak264 | thomasjfox: I'm still waiting for my Pandora :( |
| 23:12:58 | gevaerts | So far :) |
| 23:13:14 | gamefreak264 | I ordered back in January of 2009 I think |
| 23:14:07 | thomasjfox | gamefreak264: Waiting for it is part of the joy ;) Just put rockbox on your ipod then |
| 23:14:27 | | Quit kronflux (Quit: Leaving) |
| 23:14:28 | gamefreak264 | thomasjfox: it just makes me depressed, personally |
| 23:14:49 | gamefreak264 | thomasjfox: Do you have your unit yet? |
| 23:15:17 | thomasjfox | gamefreak264: Yes. But please stay on topic (=rockbox) as the channel logs are read by the developers |
| 23:15:36 | gamefreak264 | Alright, will do. Didn't mean to get offtopic. |
| 23:16:47 | thomasjfox | kugel: Are somewhat current android images available somewhere? |
| 23:17:21 | kugel | you mean rockbox builds? |
| 23:17:29 | | Quit TheLemonMan (Quit: free(me)) |
| 23:18:05 | gamefreak264 | My android phone is in pretty much dire need of space, I think I'll just put it straight ontop the ipod |
| 23:19:03 | thomasjfox | kugel: Yes |
| 23:19:24 | thomasjfox | kugel: Or are the files in the wiki updated from time to time? |
| 23:19:36 | kugel | there's some more or less outdated ones on the forum |
| 23:20:00 | gamefreak264 | Would I benefit much feature wise from running r29487 or would I likely be better off running a stable build? |
| 23:20:42 | gevaerts | gamefreak264: since the latest stable release is only two days old, I'd say pick 3.8 |
| 23:20:49 | Llorean | I'm not sure our latest release *is* that stable, given the number of bugs reported since it came out. Not that a newer build is likely to be too much better at the moment, since it just was released. |
| 23:21:05 | gevaerts | We haven't had time yet to implement lots of new stuff |
| 23:21:56 | gamefreak264 | Llorean: Any nasty bugs I'm likely to encounter? |
| 23:22:20 | gamefreak264 | Anyway, I'm going with 3.8 |
| 23:22:30 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
| 23:22:41 | | Quit S_a_i_n_t (Ping timeout: 252 seconds) |
| 23:22:59 | n1s | mostly the usual crashes with files that have odd metadata is my guess |
| 23:23:01 | Llorean | gamefreak264: Nothing harmful that I've heard about. And given that it's generally individuals reporting it without others saying "hey, me too" they may not be 3.8 issues at all, but rather the kinds of problems people occasionally run into. |
| 23:23:19 | Llorean | Since a new release brings a lot of updates, a lot of people can have the chance for one-off issues. |
| 23:23:36 | gevaerts | New releases also can bring new users, with new corrupted filesystems :) |
| 23:23:51 | n1s | and new exotcily broken files :) |
| 23:23:57 | | Nick linuxstb_ is now known as linuxstb (~linuxstb@rockbox/developer/linuxstb) |
| 23:23:58 | | Join faemir [0] (~tarq@109.224.138.11) |
| 23:24:14 | gevaerts | And new dodgy USB cables |
| 23:24:41 | Llorean | gevaerts: I wish they'd try the RC and find the bugs *then*. |
| 23:24:44 | gamefreak264 | What motivates you guys to do this? It seems like a dreadful hobby to me |
| 23:24:54 | faemir | Hey all, I was wondering whether I can tell how loud I'm playing my music in terms of dbA? |
| 23:25:02 | gamefreak264 | Anyway, thanks for devoting your time to making my life more convenient :P |
| 23:25:17 | stripwax | Llorean - to be honest, I didn't see a lot of advertisement for the RC. |
| 23:25:40 | Llorean | stripwax: True. |
| 23:25:50 | Llorean | stripwax: I'm hoping for next time we can put the RC in RBUtil somehow |
| 23:25:56 | stripwax | faemir - in rockbox, the volume is in terms of dB where 0 is line levels. the actual loudness depends on your headphones (which obviously rockbox cannot know about) |
| 23:26:09 | faemir | stripwax, I guessed as much, is there a way to measure it? |
| 23:26:37 | faemir | I mean, -25 is good and -20 is loud for me, which suggests they are rather loud |
| 23:26:53 | faemir | I think |
| 23:27:39 | stripwax | -20 is almost 4x the loudness of -25. (sortof) |
| 23:28:16 | thomasjfox | gamefreak264: When you've used rockbox for some days, you'll know ;) |
| 23:28:31 | | Join [Saint] [0] (S_a_i_n_t@203.184.2.85) |
| 23:28:47 | faemir | stripwax, the headphones say 96db @1khz if that helps? |
| 23:29:12 | sideral | AlexP: Where do we store .map files for the 3.8 builds? I'd like to investigate one of the 3.8 DB commit crashes reported here last night |
| 23:29:44 | Llorean | faemir: That's noise. There's really no way to know outside of getting something that actually measures loudness. |
| 23:30:24 | AlexP | sideral: I don't know where Zagor put them (or if he even took them actually). One mo, I'll get you another link to it |
| 23:30:55 | faemir | Llorean, thought so, well I'll just keep it low and hope for the best I guess, I listen to about an hour a day so I'm sure I couldnt be damaging my ears toooo much |
| 23:31:43 | gamefreak264 | Are there any sorts of things you think I should know as a newcomer to rockbox about to do his first install? I'm using the rockbox utility and not the manual install method, by the way. |
| 23:31:49 | Llorean | At -25 I wouldn't imagine an hour a day is doing any real damage. |
| 23:32:01 | stripwax | faemir - to be honest, if it feels loud, it probably is, so turn it down to a level that is quiet enough to still hear fine. -32 works fine for me, sometimes quieter. i have pretty sensitive headphones though. |
| 23:32:21 | * | Llorean listends at -30 to -70 depending on the time of day. |
| 23:32:48 | AlexP | sideral: check PM |
| 23:32:57 | faemir | stripwax, yeah mine are pretty amazing at isolation, but I reckon I damaged my hearing pretty badly a few years back on the school bus with a cd player on max to just hear through the racket :( |
| 23:34:06 | AlexP | Zagor: Did you take the elf and map zips from the debug folder for the release? If not, they are still where the builds were, is it possible to stick them on rockbox.org somewhere? |
| 23:34:46 | faemir | Llorean, yeah if I fall asleep to music I'll have it way down in the 70s, but I don't like rolling and damaging/tangling my earphones |
| 23:35:05 | | Quit sampattuzzi (Remote host closed the connection) |
| 23:35:24 | | Join ReT [0] (ReT@c-24-218-228-246.hsd1.ct.comcast.net) |
| 23:35:29 | ReT | hey good afternoon folks |
| 23:36:09 | stripwax | ReT - depends on your timezone :) |
| 23:36:13 | ReT | I just got an iTrip FM transmitter for my iPod video but it dosen't work on rockbox, which is a major bummer because rockbox is awesome |
| 23:36:37 | stripwax | ReT - with Accessory Power enabled? |
| 23:37:11 | ReT | Err good question |
| 23:37:32 | sideral | stripwax, AlexP: Strange, stripwax reported a 3.8 bug for iPod 5G, but the link you sent me doesn't seem to contain a build for a 5G iPod. Does that target go by another name? |
| 23:37:36 | stripwax | ReT - http://www.rockbox.org/wiki/IpodAccessories |
| 23:37:47 | stripwax | sideral - ipodvideo |
| 23:37:53 | sideral | Ah, OK |
| 23:39:35 | ReT | Stripwax: Thanks man I will try that out |
| 23:40:25 | ReT | Stripwax: I would be super bummed if I couldn't get it to work heh ;) |
| 23:40:58 | faemir | stripwax, scrap that, fitted in different size inners and even -30 sounds loud |
| 23:41:23 | stripwax | faemir - :-) |
| 23:41:45 | faemir | crazy how much that counts for, -20 was painfully loud suddenly |
| 23:43:26 | Zagor | AlexP: no, I didn't take them. I guess we could put them in a debug dir. |
| 23:43:49 | AlexP | Zagor: It might be useful for some, and everyone else will never see them |
| 23:45:57 | *** | Saving seen data "./dancer.seen" |
| 23:46:04 | | Join tchan [0] (~tchan@lunar-linux/developer/tchan) |
| 23:46:16 | Zagor | http://download.rockbox.org/release/3.8/debug/ |
| 23:47:26 | | Join wodz [0] (~wodz@87-206-240-131.dynamic.chello.pl) |
| 23:48:17 | wodz | n1s: genlang profiling -> wodz.prv.pl/">http://wodz.prv.pl/ |
| 23:48:52 | n1s | wodz: i didn't look into it because i try not to toutch perl unless i have to :) |
| 23:49:24 | ReT | Stripwax: Still not working. Accessory power is on and the itrip appears to be working but no FM modulation |
| 23:49:32 | wodz | I understood you want to speed up genlang |
| 23:49:43 | stripwax | ReT - you might also need to turn on Line Out! |
| 23:49:52 | | Quit gamefreak264 (Quit: I QUIT!) |
| 23:50:00 | ReT | Stripwax: That is on |
| 23:50:33 | stripwax | ReT - sorry I can't help more :-( I don't have any ipod accessories personally |
| 23:50:58 | [Saint] | If accessory power and line out are both on, I would expect it to work. |
| 23:51:08 | n1s | wodz: i'd like it to be faster and have thought abotu it but i'm not good enough at perl and don't want to rewrite the whole thing in c |
| 23:52:26 | wodz | n1s: from profiling it seems that clever rewritten regexp could help |
| 23:53:19 | sideral | stripwax: Re FS #11976: The 4e??? address you reported is in tagcache_search, which AFAICT isn't used in DB commit. So either that address is wrong, or the DB wasn't committing |
| 23:53:21 | | Quit komputes (Remote host closed the connection) |
| 23:53:56 | ReT | Odd |
| 23:53:58 | ReT | Ugh |
| 23:54:03 | ReT | Oh well |
| 23:54:17 | n1s | wodz: yes |
| 23:55:05 | stripwax | sideral - does Auto Update use that function? |
| 23:55:32 | stripwax | sideral - if not, maybe some bad interaction between whatever was happening with my menu interaction and whatever the database was doing at that moment in time? |
| 23:55:41 | stripwax | could it be WPS perhaps? |
| 23:55:59 | sideral | stripwax: It's likely used in DB generation −− checking... |
| 23:56:10 | stripwax | oh. well in that case... that makes sense |
| 23:56:15 | sideral | BTW, the path name in your metadata log looks odd. |
| 23:56:22 | | Join Keripo [0] (~Keripo@eng249.wireless-resnet.upenn.edu) |
| 23:56:24 | stripwax | it would have had to have happened at pretty much the very last step of db generation though. |
| 23:57:03 | stripwax | sideral - the path name of which file(s)? |
| 23:57:19 | stripwax | oh, the last ones. yes, I agree. that seems odd. |
| 23:57:30 | sideral | Have you tried removing this directory? |
| 23:57:35 | stripwax | in file browser the path just says The Magic Numbers. I have no idea what that weird stuff is. |
| 23:58:11 | stripwax | sideral - no, I haven't tried removing it. The database built successfully when I just used Initialise Database from the menu. |
| 23:58:48 | stripwax | hang on a minute |
| 23:58:51 | sideral | stripwax: Interesting taste of music BTW :) |
| 23:58:57 | stripwax | that stuff at the end of the metadata log is my *playlist* |
icon identifies that the person is a core developer (has commit access).