--- Log for 11.08.104 Server: zelazny.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16p1 Started: 13 days and 21 hours ago 00.00.47 # 3) The i2c drivers were developed when there were no recorders 00.02.23 # To (1): If this is old code, I'll try to move the mas_reset() into the startup code (only), and try if the dsp reset/ codec reset bits in MAS_CONTROL are of any use. 00.02.50 # do so 00.03.08 # funny though, i have had the opposite experience 00.03.29 # In what respect? 00.03.44 # i had to go to the recording screen, back to playback and then back to recording 00.04.12 # Did you read my bug description at the bottom of the RomBox wiki page? 00.04.15 # if i just went to the rec screen, it would record 30 bytes 00.05.10 # just read it now 00.06.51 # Btw: I'm just doing a long-term test recording - 24 hours at q=7, 44.1 kHz stereo. Will check that for frame errors 00.07.31 # Next will be a frequent time-split recording (several hours in 1 minute chunks) 00.10.07 # how big are your FAT clusters? 00.11.36 # amiconn: bad news from Paul on the mailing list 00.13.47 # LinusN: fat_cluster_size == 32768 (80 GB drive) 00.14.03 # What bad news? :( 00.14.25 # big clusters == better recording performance 00.14.34 # so you should try smaller clusters 00.15.03 # bad news == Paul's recording problems went away when he tried the non-optimized ATA version 00.15.53 # Iirc 32 KB is the default size for fat32 for partitions >32 GB. I can't choose the cluster size with Win98, and WinXP doesn't even let me format such a large fat32 partition... 00.17.17 # Concerning the ATA problem: Did he also try versions with only fast reading/ fast writing disabled? Disk model? hd firmware? hw mask? Archos model? 00.18.04 # no more info yet 00.18.52 # To (2): Did you do logic analyses of the i2c drivers? If yes, do you have them still available? 00.19.22 # yes i did, but i didn't keep them 00.19.34 # i can do new ones, i have my kit with me 00.20.14 # If this doesn't cause too much hassle, it could be interesting. I still have the viewer installed... 00.21.06 # As it gets to logic analyzing: Do you think this may shed some light on the recording init problem after mas_reset() too? 00.21.27 # not sure 00.22.28 # Remember that I even managed to trigger the bug once when running from ram. Others did also report that this 30-byte free happens occasionally... 00.22.37 # s/free/freeze/ 00.23.09 # i got it a few times when running with gdb 00.24.23 # your latest stack fix, was that to munge the entire stack with DEADBEEF? 00.25.21 # Yes, because otherwise the main thread panics with stov after using "create directory" 00.25.31 # s/stov/stkov/ 00.25.46 # ok, but you didn't reply to the bug report 00.26.38 # Sorry, I didn't realise that there was one. Two users reported it to me on the channel 00.26.45 # i'm replying now 00.26.57 # nice catch, btw! 00.27.16 # I didn't manage to get this myself, because my stack area was a little larger due to using my geek bitswap, so my .iram is smaller 00.27.43 # However, I got very high stack usage readings after trying that (96..97%) 00.28.05 # badness 00.28.45 # I wonder why you changed the linker script in the first place... 00.29.28 # there is a bug in older binutils versions that allows sections to overlap 00.29.46 # it is now fixed, so i changed the script to comply with that 00.30.53 # from the CVS commit log: "Major fixes to please newer versions of the linker" 00.30.55 # Ah ok. So my fix was "intuitively" right. I also tried defining the start position of the .stack section differently, so that it overlaps with .iram. This worked for me too... 00.32.21 # Strangely, I once tried to compile gcc 3.4.1 and current binutils under cygwin (successfully) and then built rockbox with that. This did work too, even without your linker script fixes... 00.33.07 # which binutils version? 00.33.57 # 2.15 00.34.04 # weird 00.37.05 # For fixing (3): Should there be an additional config define, HAVE_MAS_ENABLE or such? 00.38.14 # nah, move the code somewhere else, with #ifdef HAVE_MAS3507D 00.38.47 # it'll break the neo, but frankly, i don't care 00.39.03 # but yes, your approach is cleaner 00.39.38 # Iirc the neo is broken anyway (still builds without warning, but most probably won't run) 00.42.12 # and that's why i don't care... :-) 00.42.51 *** Saving seen data "./dancer.seen" 00.43.56 Quit zeekoe ("quit...") 00.44.17 # The latest bug in the tracker looks like another "classic" rld case... 00.44.44 # not really 00.45.16 # well,maybe it is... 00.47.02 # A propos CVS commit log: is there a way to show older entries than those listed on the web page, in chronological order? 00.47.48 # "cvs log" 00.48.22 # And a completely different thing: Why http://rockbox.haxx.se/docs/contributing.html says "Also, avoid using 'const'." 00.48.35 # yes 00.49.34 # ? 00.49.35 # can you guess why it says so? 00.49.42 # No 00.50.13 # because life is a lot easier if you don't care 00.51.36 # Imho using 'const' helps to write cleaner code: if you intend to have a read-only variable, declare it 'const', and then later on assign something to it, the compiler will warn you. 00.53.09 # i mostly use #define for constants 00.53.11 # Other than that, it does have no effect unless the code is running from rom... 00.53.39 # ...and rockbox was never intended to run from rom 00.55.12 # ...at the time it was designed. As you said some time ago, thorough checking for proper 'const' use may help in case rockbox gets ported to some other hardware some day 00.55.55 # yes, and back then we didn't intend to port rockbox to another platform 00.56.07 # ...and using 'const' instead of #define may save some memory in case the compiler doesn't do proper constant folding 00.57.21 # So my point is not knowing why the document said so in the past, but why it _still_ does. 00.57.44 # because we haven't bothered changing them 00.59.09 # Perhaps this sentence should be taken out then 01.01.11 # one main problem with "const" is that C++ programmers think that const works the same way in C as well 01.01.30 # (i just removed the sentence) 01.06.02 Join sethians [0] (~jirc@200.87.77.112) 01.12.59 Join Nibbler [0] (~andrer@port-212-202-78-112.dynamic.qsc.de) 01.17.42 Quit sethians ("Leaving") 01.20.48 # LinusN: (i2c timing) Both mas' want at least 1250 ns SCL high according to the specs. When running from ram, the current implementation of i2c_outb() holds SCL high for only 270 ns (recorders)/ 250 ns (players) [possibly 360 ns/ 333 ns due to pipeline contention] 01.38.59 # ic 01.40.53 # ok so there's no iptables rules, hosts.allow and hosts.deny are set to allow my network, the services are started, the network's up, the box is pingable, nmap accross the network to the box's network ip shows a handful of open ports, nmap on the local box to the box's network ip show all the ports that should be open, all the important services (web, samba, ssh) are set to bind to the box's network ip and are available on the local box 01.41.57 # ze: wrong channel 01.42.27 # well whats the right one 01.42.29 # heh 01.42.39 # this is the only active one with linux people i'm in 01.42.57 # if you got no idea thats ok, but if you do don't just say wrong channel hehe 01.45.27 # ze: so what's your problem? 01.45.45 # can't connect to web/ssh/samba from accross the network 01.46.50 # what happens if you do telnet to port 80? 01.47.21 # hmm 01.47.26 # well it was giving me connection refused 01.47.31 # and now it's spontaneously decided to work 01.47.57 # both ssh and web gave me connection refused every time i tried 01.48.15 # is there something that'd cause that to be like that for some period of time and then after a while it'd kick in? heh 01.48.33 # i dunno, it's weird 01.49.01 # LinusN: My 24 h recording finished - bad news :( 01.49.28 # after the box boots up, the only open ports are 135, 139, 445, 1025 (as reported by nmap) ... but nmap'ing locally, or now after whatever spontaneously happened, i get 22, 80, 111, 139, 445, 6543, and 6544 as i should 01.50.24 # ze: weird indeed 01.50.31 # amiconn: corrupt frames? 01.51.42 # Mp3utility reports a sync error a little above 3 minutes in the 24h file, and right at the beginning of the file started after the 24 h split. Unfortunately it stops analyzing after encountering the first error 01.53.04 # Vbrfixer tells me there are 4 mpeg version changes in the short file (this is only 314 KB !). It is unable to analyze the big one: runtime error - out of memory 01.53.11 # err scratch 6534 and 6544.. those only show up locally, which is probably right, but the rest is as i said 01.53.30 # it's like it doesn't start working till the uptime reaches 10 or 15 minutes 01.53.30 # heh 01.55.02 # amiconn: could be disk related problems 01.55.29 # er! it's doing it again 01.55.34 # Read from remote host pvr: Connection reset by peer 01.55.34 # Connection to pvr closed. 01.55.44 # * ze checks the crontab 01.58.20 # amiconn: gotta sleep now 01.58.39 # nite LinusN 01.59.12 # hmm i bet it's this 'shaper' crap whatever it is 01.59.16 # (Just checking with mp3fixer, although I know that the windows version isn't always reliable) 01.59.25 # seems to run every 10 minutes and is something about traffic control 02.00.06 # and all i had to do was wait 20 minutes 02.00.06 # :p 02.00.32 # if thats actually it 02.00.47 # ok, nite all 02.00.50 Part LinusN 02.01.25 # er doh... well if you see the longs, Thanks and goodnight heh 02.01.31 # s/longs/logs/ 02.12.13 # haha it might not be though, apparently i'm using an ip address thats already in use :p 02.17.58 # teehee that was it... how stupid 02.18.17 # that'll teach me to leave out an /etc/hosts entry for a new system 02.24.38 # nite all 02.25.26 Part amiconn 02.42.54 *** Saving seen data "./dancer.seen" 02.45.24 Quit AciD (Read error: 104 (Connection reset by peer)) 02.46.01 Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) 03.05.45 Quit Nibbler (Read error: 104 (Connection reset by peer)) 03.24.35 Join Heil_Eri1 [0] (~centericq@p508B3B13.dip.t-dialin.net) 03.42.22 Quit Heil_Eris (Read error: 110 (Connection timed out)) 04.42.58 *** Saving seen data "./dancer.seen" 04.46.08 Join edx{code} [0] (edx@pD9EAB9F0.dip.t-dialin.net) 04.46.44 Join Nibbler [0] (~andrer@port-212-202-78-112.dynamic.qsc.de) 04.57.41 Quit edx{code} () 05.02.23 Quit edx (Read error: 110 (Connection timed out)) 05.03.55 Quit Hadaka (Read error: 110 (Connection timed out)) 05.19.01 Quit Nibbler (Read error: 54 (Connection reset by peer)) 06.42.59 *** Saving seen data "./dancer.seen" 06.59.28 Join Naked [0] (naked@naked.iki.fi) 06.59.49 Nick Naked is now known as Hadaka (naked@naked.iki.fi) 07.04.33 Join Nibbler [0] (~andrer@port-212-202-78-112.dynamic.qsc.de) 07.35.24 Quit AciD (Read error: 54 (Connection reset by peer)) 07.35.24 Quit Nibbler (Read error: 54 (Connection reset by peer)) 08.23.31 Join Madman [0] (~madmangor@69.107.248.21) 08.24.29 # cool, you fixed the stkov error when making a dir in the new build 08.24.58 # i was talking to amiconn and midk about it 08.30.45 Quit Madman () 08.43.02 *** Saving seen data "./dancer.seen" 09.00.29 Join Bagder [241] (~dast@labb.contactor.se) 09.00.40 # ok amp let me out 09.01.07 # hello good people 09.05.23 Join Nibbler [0] (~andrer@port-212-202-78-112.dynamic.qsc.de) 09.07.49 Join amiconn [0] (~jens@pD95D1D06.dip.t-dialin.net) 09.30.04 # Hello, fellow Bagder. The amp won't let you go \o/ 09.30.05 Quit Nibbler (Read error: 104 (Connection reset by peer)) 09.38.51 Join Zagor [242] (~bjst@labb.contactor.se) 09.41.19 Join edx [0] (edx@pD9EAB9F0.dip.t-dialin.net) 09.44.23 # http://www.opengroup.org/publications/graphics/n900cov.jpg 09.44.33 # now, can I have that on my car? ;-) 09.45.14 # :) 09.45.37 # i would guess both UNIX and LINUX are taken already 09.45.44 # yeps 09.46.19 # probably not CURL though ;) 09.46.38 # its just a bit too expensive to be worth it, imho 09.46.52 # how much is it? 09.47.07 # it used to be 5000 SEK 09.47.15 # for a few years only 09.47.25 # but I know they talked about raising the fee 09.47.26 # it's time limited? 09.47.28 # yes 09.47.32 # weird 09.47.51 # deduct it as a marketing expense ;) 09.48.00 # :-) 09.49.24 # that plate is available as a mug too ;-) 09.49.30 # * Bagder considers buying one 09.49.42 # :) 09.51.38 # http://www.opengroup.org/bookstore/catalog/n901.htm 09.51.44 # also a fun product 09.52.02 # "don't leave home without it" ;-) 09.52.36 # business card cdroms are always fun. rather useless content though 09.53.20 # the SUSV3! ;-) 09.53.36 # when you buy that in hardcopy, is 11kg! 09.54.45 # haha 09.54.51 # ...as we all do 09.55.06 # stupid google refused my app due to "bad postal address" 09.57.27 # but the mail was in swedish 09.57.42 # and they didn't say what was bad with it 09.59.43 # maybe it was in their pyramid scheme blacklist 10.00.32 # and then proceeded and said, if you want to fix it, fill in a new application with a DIFFERENT email adress since this one is now connected to the failed application 10.00.42 # hmm 10.01.07 # haha, and that failed application can never be fixed? 10.01.12 # yeps 10.01.13 # since you guys are ninjas when it comes to virtually anything, do you know what might cause a crc checksum failure with large packets? I'm testing a midlet ssh client which is driving me nuts :) 10.01.22 # and since I don't know what the problem was, I'm deemed to repeat it 10.01.22 # cute system 10.01.44 # there must be a contact address somewhere 10.01.48 # yes 10.01.52 # I mailed them 10.02.10 # dwihno: you're talking about crc problems on the network? 10.03.14 # Bagder: Not really... Larger packets seem to trigger the crc failure 10.03.25 # as long as the packets are small, it runs so smoothly! 10.03.33 # so the ssh client is what detects the checksum problems? 10.03.43 # yup 10.04.07 # there must be a problem in the client since the Z1010 is the only phone with this specific problem 10.04.26 # yes 10.04.38 # the traffic is checksumed already on the TCP layer 10.04.54 # it can't be bad when the app receives it, unless the server sent bad data 10.04.59 # yeah 10.05.27 # A couple of larger packets just trigger the internal crc failure 10.05.48 # it sounds like a good old application bug 10.06.13 # Rather strange it only occurs on my phon.e 10.08.25 # Well. I've contacted the author with my findings. Perhaps he has any ideas. 10.33.33 # Using the telnet-only version of the client, the same problems arise. I wonder what might be wrong 10.43.05 *** Saving seen data "./dancer.seen" 10.45.28 # possibly because you have an usual MTU? 10.49.40 # MTU? 10.50.00 # Telia felia lingonbär \o/ :) 10.50.06 # maximum transmission unit 10.51.40 # Changeable? 10.53.40 # Fixable? :) 10.53.42 # Repairable? 10.54.23 # MTU is the maximum block size your device sends. it can be changed, but generally you don't want to do that since it will affect retransmissions etc. 10.54.54 # Okay 10.55.15 # It is the receiving that breaks, afaik 10.55.20 # Perhaps MTU affects both? 10.56.42 # yes 10.59.02 # I'm just suggesting that the app might have some assumptions in the code that your situation breaks 11.01.44 # the application assumes larger buffers than the phone has to offer? (otherwise, it should work, huh?) 11.02.32 # well, I refrain from guessing exact details, but since it complains on bad checksums and it really shouldn't be any checksum errors... 11.04.01 # It isn't just the checksum 11.04.15 # I've tried the plain telnet version of the software and it still bangs 11.05.45 # So if I was to fix the telnet version, the same fix could most likely be applied on the ssh software 11.07.01 # perhaps the bug is in code used independent of the actual transport (ssh or plain telnet) 11.08.17 # could be 11.08.28 # might be 11.08.29 Join Nibbler [0] (~andrer@port-212-202-78-112.dynamic.qsc.de) 11.08.32 # must be 11.08.33 # :-) 11.49.50 Quit Nibbler (Read error: 104 (Connection reset by peer)) 11.53.58 # morning 12.10.03 # anyone here know if linux mass storage driver can take 2 disks on 1 usb-ata controller ? 12.13.15 # webmind: I guess this depends on the implementation of the usb-ata bridge. Usb mass storage uses the scsi protocol, so the os driver shouldn't be the limiting factor 12.13.46 # hmm 12.14.00 # any idea if it would work on the chip ? 12.36.59 # i guess it will work, since the ata bus handles two devices and thus the chip does not have to do anything special to support it 12.39.03 # have you checked the data sheet? 12.42.10 # just did.. chip claims to be fully ata/atapi compliant.. 12.42.14 # so should be no problem 12.43.09 *** Saving seen data "./dancer.seen" 12.43.10 # are you going to mount dual flash cards, or what is your plan? 12.44.42 # my HD on my laptop is dying... 12.44.56 # so i'm thinking of making a portable raid system 12.45.17 # raid I can do in software.. so just need 2 disks 12.46.02 # aha. battery powered or just movable? 12.46.10 # battery powered 12.46.16 # neat 12.46.21 # uhuh 12.46.59 # especially since I will probably will be able to combine it with my pda 12.48.33 # a zaurus? or does anyone else have usb host ports these days? 12.57.21 # uhuh 12.57.26 # zaurus sl-6000L 13.09.26 Join Nibbler [0] (~andrer@port-212-202-78-112.dynamic.qsc.de) 13.49.25 Quit Nibbler (Read error: 104 (Connection reset by peer)) 14.43.11 *** Saving seen data "./dancer.seen" 14.49.16 Part Zagor 14.49.27 Join Zagor [242] (~bjst@labb.contactor.se) 15.09.13 Quit gromit`` (Remote closed the connection) 15.22.33 Join Ericgoh [0] (~kapipo@p29150-adsau12honb7-acca.tokyo.ocn.ne.jp) 15.22.52 # is Zagor here? 15.23.24 # Zagor: BOOO 15.23.41 # ah... 15.23.50 # got something wanna ask him 15.23.55 # * Bagder tries to scare him awake 15.24.59 # i am trying to find the datasheets for portalplayer IC, heard that Zagor has it 15.25.14 # wonder is anyone here has the datasheet too? 15.25.23 # he doesn't have that 15.25.27 # ?? 15.25.29 # I don't think anyone has 15.25.40 # unless they chop off an arm and a leg 15.26.03 # coz i saw the irc log in rockbox homepage saying that he got it from someone else 15.26.20 # then I'm wrong 15.26.33 # but I don't think I am 15.26.50 # i'm here 15.26.58 # * Bagder jumps 15.27.06 # don't scare us like that 15.27.09 # bagder is right, i don't have the sheets. 15.27.15 # ohh 15.27.32 # i got an agreement to sign that required me to be their eternal soul slave and sign off my firstborn. 15.27.32 # maybe i misunderstood 15.27.43 # haha 15.29.45 # the stupid portalplayer keep their IC so secret that nobody knows wtf they doing 15.30.18 # the question is why companies buy it 15.31.17 # ?? 15.31.54 # do you mean LSI Logic? 15.32.01 # why do companies build players based on portalplayer 15.32.34 # maybe this shows why I don't run a company that does that ;-) 15.33.03 Join Nibbler [0] (~andrer@port-212-202-78-112.dynamic.qsc.de) 15.33.22 # oh... 15.33.51 # but portalplayer eating the battery power like hell 15.34.22 # also the reason why player based on portalplayer sucks on their playtime 15.34.46 # i'm guessing the portalplayer chip is part of an attractive package with nearly complete firmware and so on. 15.35.04 # <--agree 15.35.04 # most likely, yes 15.35.12 # which means less work for the manufacturer == less risk == easier to calculate for the bean counters 15.35.19 # portalplayer actually selling their solution but not IC 15.35.26 # right 15.35.41 # jumping off a cliff is cheap too ;-) 15.36.01 # :) 15.36.23 # yap, hope ipod jumping off the cliff one day 15.36.28 # really hate ipod 15.37.35 # <--anti-apple 15.37.45 # i can't say i hate ipod. i more dislike uncritical consumers 15.38.47 # \o/ 15.39.04 # Regular hard disk players with NORMAL batteries si teh bestest! :) 15.39.24 # they will be history soon 15.39.56 # hope such day comes as early as possible 15.41.54 # Bagder: hush! don't say that! 15.42.25 # ipod is now trying to do like microsoft to monopolize the market 15.43.22 # every company would want to do that 15.43.46 # but as Zagor said, its the consumers that let them 15.44.06 # That reminds me. Any of you guys have a cheap 512 meg memorystick duo for sale? ) 15.44.10 # :) 15.44.30 # so consumers should think wise before they buy, not just buying through advertisements 15.44.48 # ??MS DUO 15.44.57 # you want that for what? 15.45.11 # you never get MS for cheap 15.46.29 # My cell phone 15.46.34 # I want to keep some music in it. 15.46.40 # 256 meg chips are affordable 15.47.18 # when talking about not buying crappy products, memorystick sure is a good thing to mention ;-) 15.47.23 # does your phone use memorystick? is it a sony? 15.47.25 # that's rare 15.47.45 # haha, what else other than sony use MS 15.47.47 # Zagor: yep. and the chip is 100% covered as well 15.47.55 # Ericgoh: Behave :) 15.48.34 # MS license almost double of SD Card, only rich company afford to use that 15.48.36 # rule #1: never buy sony hardware 15.48.51 # Zagor: how come? 15.49.18 # proprietary crap 15.49.20 # they always use crappy proprietary things like memory stick to force you to buy everything else from sony too 15.49.20 # Sony is throwing all the useless rubbish into MS causing it to be so much bigger than SD 15.49.45 # also increasing the development cost for MS 15.59.39 # Zagor: well, I'm really satisfied with my phone anyhow :) 15.59.55 # which model is it? 16.01.04 # z1010 16.02.31 # how many hours of music can you play with it? 16.02.41 # Dunno really... 16.02.55 # I only fit 4 tracks on the chip :) 16.03.38 # haha...wonder what happened to the phone when you find out battery ends becoz of playing music 16.03.52 # :-) 16.03.56 # I can live with that 16.05.20 # ??then what the purpose of getting a cell phone? 16.05.40 # Ericgoh: so your phone never runs out of batteries? 16.06.16 # Ericgoh: I charge my phone regularly 16.07.15 # my phone can stand for more than 1week 16.07.32 # even i talk frequently, it can still stands for 2-3days 16.08.24 # actually i bought a very stupid phone, 16.08.43 # but the battery life is very long 16.09.24 # Well, people should do as they see fit :) 16.09.37 # And not critisize everyone everytime they think differently 16.09.42 # Perhaps I should run for president 16.09.45 # ;) 16.09.50 # * Bagder votes for dwihno 16.10.22 # Yay! 16.10.27 # thats not critisize, i am just giving opinion 16.10.30 # Watch out Kerry - here I come! :) 16.10.57 # coz already got lots of customer complaining about the battery life while playing music on cell phone 16.11.31 # even though they already know how long they can play the music on their cell phone 16.11.31 # Keeping the phone charged and doubling it as a mp3 player works for me 16.12.00 # everyone thinks like that then we wont get any complain, haha... 16.14.05 # :-) 16.22.28 # time to go swimming! 16.22.30 Part Bagder 16.30.43 Part Zagor 16.34.05 Join dstar5 [0] (Lee@ACC2BA2C.ipt.aol.com) 16.43.15 *** Saving seen data "./dancer.seen" 16.58.54 Quit Nibbler (Read error: 104 (Connection reset by peer)) 17.20.42 Quit dstar5 (Read error: 104 (Connection reset by peer)) 17.21.19 Join dstar5 [0] (Lee@ACC2E45A.ipt.aol.com) 17.36.14 Join sethians [0] (~jirc@200.87.78.53) 17.54.42 Quit Ericgoh () 18.22.54 Quit sethians ("Leaving") 18.34.43 Join Nibbler [0] (~andrer@port-212-202-78-112.dynamic.qsc.de) 18.43.16 *** Saving seen data "./dancer.seen" 19.17.26 Join nevs [0] (nevs@ACBD5A76.ipt.aol.com) 19.20.10 # hi 19.26.29 Quit nevs () 19.26.45 Quit dstar5 ("Leaving") 19.44.25 Quit Nibbler (Read error: 104 (Connection reset by peer)) 20.43.20 *** Saving seen data "./dancer.seen" 21.17.54 Join scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) 21.17.55 Quit scott666 (Read error: 54 (Connection reset by peer)) 21.18.00 Nick scott666_ is now known as scott666 (~scott666@c-24-245-58-48.mn.client2.attbi.com) 21.27.26 Join Nibbler [0] (~andrer@port-212-202-78-112.dynamic.qsc.de) 21.44.08 Join jakesir [0] (solaris@pool-70-16-28-73.balt.east.verizon.net) 21.44.26 Quit jakesir (Client Quit) 21.50.51 Join dstar5 [0] (Lee@ACC478EA.ipt.aol.com) 21.55.16 Join [IDC]Dragon [0] (~d90a3255@reladm.kharkov.net) 21.57.28 # hi Jörg 21.57.39 # <[IDC]Dragon> Hello Jens 21.58.41 # <[IDC]Dragon> I'm looking for Jake, he only sticked his head in here and left 22.00.04 # Hmm. 22.00.27 # Didn't he have some problems with his box? 22.00.50 # <[IDC]Dragon> yes, he shipped it to me 22.01.44 # Interesting. Isn't this rather expensive (I assume he lives in the states) 22.01.48 # ? 22.01.49 # what was the problem with his box? 22.01.57 # <[IDC]Dragon> he suspected a bad flash, but it turns out to be a bus problem or so 22.02.26 # <[IDC]Dragon> I've hooked it up to uart_boot, the flash reads OK 22.03.25 # <[IDC]Dragon> but when dumping ROM+flash from revived Rockbox, the files have a stuck 0 bit every 8 KB 22.03.47 # Hmm. Do you already have an idea what could cause this? 22.04.03 # <[IDC]Dragon> I ran out of them 22.04.33 # Exactly _one_ zero every 8 KB? 22.04.40 # <[IDC]Dragon> first I thought it's a RAM error, I made a test to uart_boot, but this went OK 22.05.07 # <[IDC]Dragon> yes, bit 1 on every 8 KB 22.05.23 # One bit only?? Really strange 22.05.45 # <[IDC]Dragon> the address has to end on FF8 22.06.00 # well... if you can't fix it... i have a good CPU board he could use it does not have a flashable chip though 22.06.08 # <[IDC]Dragon> so, on 0FF8, 2FF8, 4FF8, and so on 22.06.32 # <[IDC]Dragon> it's a V2 22.06.49 # <[IDC]Dragon> but CPU boards are welcome! 22.06.54 # ohh 22.07.04 # <[IDC]Dragon> does it have USB2? 22.07.09 # yes 22.07.11 # [IDC]Dragon: Did you try a ram check from within rockbox? 22.07.43 # <[IDC]Dragon> dssar5: the box of my gf could need such an upgrade 22.08.08 # <[IDC]Dragon> amiconn: no, I didn't went through that effort 22.08.53 # [IDC]Dragon: i could send it to you 22.09.07 # <[IDC]Dragon> dstar5: where are you? 22.09.32 # [IDC]Dragon: I suppose rockbox crashes every now and then with that error. Does it boot into rockbox from flash, or do you need to load rockbox via uart? 22.09.45 # [IDC]Dragon: US (oregon), but he board is so small, it would not cost much at all to ship 22.10.23 # <[IDC]Dragon> amiconn: the box starts very unreliable recently, but from flash 22.11.08 # <[IDC]Dragon> dstar5: the wreck of Jake is from the US, too, I had to pick it up at customs 22.11.37 # [IDC]Dragon: at customs? why is that? 22.11.56 # [IDC]Dragon: I wonder how this works... The bootloader has to uncompress the ucl image. Doesn't ucl incorporate a checksum? 22.12.47 # <[IDC]Dragon> dstar5: probably they suspected it could be valuable 22.13.17 # <[IDC]Dragon> amiconn: ucl has a checksum, but this is not verfied on decompression 22.13.25 # ahh well that sorta is... heh 22.13.26 # Ah 22.13.55 # <[IDC]Dragon> everything with a checksum fails on that box: RoLo, firmware_flash.rock 22.14.55 # So the problem also exists for the ram... or for the ram _only_?? 22.15.50 # <[IDC]Dragon> I'm puzzled, because my RAM test went OK 22.16.18 # <[IDC]Dragon> then I suspected the RAM on the HD, changed the disk, but same result 22.16.57 # It could well be the ram - one bit cell may be flaky, unable to maintain it's state between refreshes 22.17.42 # <[IDC]Dragon> but I wrote a RAM test... 22.18.04 # Iirc the refresh cycle is programmable, perhaps the boot loader sets a different value than rockbox? 22.18.13 # <[IDC]Dragon> I filled the whole with 0x55, verified, filled with 0xAA, verified again 22.19.02 # <[IDC]Dragon> then I filles with 0x00 and wrote a marching 0xFF, verified that this stays, then reverse values 22.19.15 # <[IDC]Dragon> s/filles/filled 22.19.30 # [IDC]Dragon: if you want the board, email me dstar5 at gmail _D0T_ com 22.19.36 # <[IDC]Dragon> (to catch address errors) 22.19.37 # see you later :) 22.19.48 # <[IDC]Dragon> dstar5: thanks, yes 22.19.58 Quit dstar5 ("Leaving") 22.23.12 # <[IDC]Dragon> afk 22.32.33 # [IDC]Dragon: (1) From which memory region the ram test executed? IRAM? (2) The bootloader starts with RAS up mode and burst mode disabled. Rockbox does enable both... 22.36.41 # (RAS down and burst) 22.43.23 *** Saving seen data "./dancer.seen" 22.47.29 Join Bagder [0] (~daniel@1-1-5-26a.hud.sth.bostream.se) 22.49.48 Join undefinedassasin [0] (~Aggressor@undefinedassasin.registered) 22.49.51 # h3y 22.49.53 # where is midk 22.52.51 # <[IDC]Dragon> back again 22.53.30 # Wher3 is midk? 22.53.34 # <[IDC]Dragon> amiconn: the test is using minimon in IRAM, bootloader DRAM init 22.54.06 # <[IDC]Dragon> in an act of despair, I have just exchanged the DRAM of Jake's box 22.54.15 # [IDC]Dragon: You could try setting burst & RAS down mode in your RAM test, then try again... 22.54.43 # <[IDC]Dragon> I'll try the other RAM when I get back home 22.54.58 # Please help me 22.55.00 # midk is gone 22.55.05 # and someone is asking me for him 22.55.10 # but I can't help 22.55.12 # [IDC]Dragon: Still at work? 22.55.29 # <[IDC]Dragon> amiconn: only for the solder tools 22.55.35 # <[IDC]Dragon> leaving now 22.55.46 # Ahh 22.56.06 Part undefinedassasin ("X-Chat [2.0.10c] Quit.") 22.56.25 # <[IDC]Dragon> ehatch the sky, we have the Perseides at max now 22.56.32 # <[IDC]Dragon> whatch 22.57.00 # <[IDC]Dragon> (meteor storm) 22.57.39 # watch even :) 22.57.48 # * [IDC]Dragon leaves for falling star gazing 22.58.15 # <[IDC]Dragon> yes, watch out for my reckless typing 22.58.41 Quit [IDC]Dragon ("no fate but what we make") 23.54.36 Join [IDC]Dragon [0] (~idc-drago@pD9E34A79.dip.t-dialin.net) 23.55.40 # <[IDC]Dragon> Just for the record: the behavior of Jake's box is the same with the new RAM chip. :-( 23.56.38 # Did you try your RAM test with burst & RAS down enabled? 23.57.12 # <[IDC]Dragon> why should I? there's a different RAM chip in in now. 23.58.02 # <[IDC]Dragon> in it