--- 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 #       <LinusN> 3) The i2c drivers were developed when there were no recorders
00.02.23 #       <amiconn> 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 #       <LinusN> do so
00.03.08 #       <LinusN> funny though, i have had the opposite experience
00.03.29 #       <amiconn> In what respect?
00.03.44 #       <LinusN> i had to go to the recording screen, back to playback and then back to recording
00.04.12 #       <amiconn> Did you read my bug description at the bottom of the RomBox wiki page?
00.04.15 #       <LinusN> if i just went to the rec screen, it would record 30 bytes
00.05.10 #       <LinusN> just read it now
00.06.51 #       <amiconn> 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 #       <amiconn> Next will be a frequent time-split recording (several hours in 1 minute chunks)
00.10.07 #       <LinusN> how big are your FAT clusters?
00.11.36 #       <LinusN> amiconn: bad news from Paul on the mailing list
00.13.47 #       <amiconn> LinusN: fat_cluster_size == 32768 (80 GB drive)
00.14.03 #       <amiconn> What bad news? :(
00.14.25 #       <LinusN> big clusters == better recording performance
00.14.34 #       <LinusN> so you should try smaller clusters
00.15.03 #       <LinusN> bad news == Paul's recording problems went away when he tried the non-optimized ATA version
00.15.53 #       <amiconn> 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 #       <amiconn> 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 #       <LinusN> no more info yet
00.18.52 #       <amiconn> To (2): Did you do logic analyses of the i2c drivers? If yes, do you have them still available?
00.19.22 #       <LinusN> yes i did, but i didn't keep them
00.19.34 #       <LinusN> i can do new ones, i have my kit with me
00.20.14 #       <amiconn> If this doesn't cause too much hassle, it could be interesting. I still have the viewer installed...
00.21.06 #       <amiconn> 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 #       <LinusN> not sure
00.22.28 #       <amiconn> 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 #       <amiconn> s/free/freeze/
00.23.09 #       <LinusN> i got it a few times when running with gdb
00.24.23 #       <LinusN> your latest stack fix, was that to munge the entire stack with DEADBEEF?
00.25.21 #       <amiconn> Yes, because otherwise the main thread panics with stov after using "create directory"
00.25.31 #       <amiconn> s/stov/stkov/
00.25.46 #       <LinusN> ok, but you didn't reply to the bug report
00.26.38 #       <amiconn> Sorry, I didn't realise that there was one. Two users reported it to me on the channel
00.26.45 #       <LinusN> i'm replying now
00.26.57 #       <LinusN> nice catch, btw!
00.27.16 #       <amiconn> 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 #       <amiconn> However, I got very high stack usage readings after trying that (96..97%)
00.28.05 #       <LinusN> badness
00.28.45 #       <amiconn> I wonder why you changed the linker script in the first place...
00.29.28 #       <LinusN> there is a bug in older binutils versions that allows sections to overlap
00.29.46 #       <LinusN> it is now fixed, so i changed the script to comply with that
00.30.53 #       <LinusN> from the CVS commit log: "Major fixes to please newer versions of the linker"
00.30.55 #       <amiconn> 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 #       <amiconn> 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 #       <LinusN> which binutils version?
00.33.57 #       <amiconn> 2.15
00.34.04 #       <LinusN> weird
00.37.05 #       <amiconn> For fixing (3): Should there be an additional config define, HAVE_MAS_ENABLE or such?
00.38.14 #       <LinusN> nah, move the code somewhere else, with #ifdef HAVE_MAS3507D
00.38.47 #       <LinusN> it'll break the neo, but frankly, i don't care
00.39.03 #       <LinusN> but yes, your approach is cleaner
00.39.38 #       <amiconn> Iirc the neo is broken anyway (still builds without warning, but most probably won't run)
00.42.12 #       <LinusN> 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 #       <amiconn> The latest bug in the tracker looks like another "classic" rld case...
00.44.44 #       <LinusN> not really
00.45.16 #       <LinusN> well,maybe it is...
00.47.02 #       <amiconn> 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 #       <LinusN> "cvs log"
00.48.22 #       <amiconn> And a completely different thing: Why http://rockbox.haxx.se/docs/contributing.html says "Also, avoid using 'const'."
00.48.35 #       <LinusN> yes
00.49.34 #       <amiconn> ?
00.49.35 #       <LinusN> can you guess why it says so?
00.49.42 #       <amiconn> No
00.50.13 #       <LinusN> because life is a lot easier if you don't care
00.51.36 #       <amiconn> 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 #       <LinusN> i mostly use #define for constants
00.53.11 #       <amiconn> Other than that, it does have no effect unless the code is running from rom...
00.53.39 #       <LinusN> ...and rockbox was never intended to run from rom
00.55.12 #       <amiconn> ...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 #       <LinusN> yes, and back then we didn't intend to port rockbox to another platform
00.56.07 #       <amiconn> ...and using 'const' instead of #define may save some memory in case the compiler doesn't do proper constant folding
00.57.21 #       <amiconn> So my point is not knowing why the document said so in the past, but why it _still_ does.
00.57.44 #       <LinusN> because we haven't bothered changing them
00.59.09 #       <amiconn> Perhaps this sentence should be taken out then
01.01.11 #       <LinusN> one main problem with "const" is that C++ programmers think that const works the same way in C as well
01.01.30 #       <LinusN> (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 #       <amiconn> 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 #       <LinusN> ic
01.40.53 #       <ze> 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 #       <LinusN> ze: wrong channel
01.42.27 #       <ze> well whats the right one
01.42.29 #       <ze> heh
01.42.39 #       <ze> this is the only active one with linux people i'm in
01.42.57 #       <ze> if you got no idea thats ok, but if you do don't just say wrong channel hehe
01.45.27 #       <LinusN> ze: so what's your problem?
01.45.45 #       <ze> can't connect to web/ssh/samba from accross the network
01.46.50 #       <LinusN> what happens if you do telnet to port 80?
01.47.21 #       <ze> hmm
01.47.26 #       <ze> well it was giving me connection refused
01.47.31 #       <ze> and now it's spontaneously decided to work
01.47.57 #       <ze> both ssh and web gave me connection refused every time i tried
01.48.15 #       <ze> 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 #       <ze> i dunno, it's weird
01.49.01 #       <amiconn> LinusN: My 24 h recording finished - bad news :(
01.49.28 #       <ze> 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 #       <LinusN> ze: weird indeed
01.50.31 #       <LinusN> amiconn: corrupt frames?
01.51.42 #       <amiconn> 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 #       <amiconn> 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 #       <ze> err scratch 6534 and 6544.. those only show up locally, which is probably right, but the rest is as i said
01.53.30 #       <ze> it's like it doesn't start working till the uptime reaches 10 or 15 minutes
01.53.30 #       <ze> heh
01.55.02 #       <LinusN> amiconn: could be disk related problems
01.55.29 #       <ze> er! it's doing it again
01.55.34 #       <ze> Read from remote host pvr: Connection reset by peer
01.55.34 #       <ze> Connection to pvr closed.
01.55.44 #       * ze checks the crontab
01.58.20 #       <LinusN> amiconn: gotta sleep now
01.58.39 #       <amiconn> nite LinusN
01.59.12 #       <ze> hmm i bet it's this 'shaper' crap whatever it is
01.59.16 #       <amiconn> (Just checking with mp3fixer, although I know that the windows version isn't always reliable)
01.59.25 #       <ze> seems to run every 10 minutes and is something about traffic control
02.00.06 #       <ze> and all i had to do was wait 20 minutes
02.00.06 #       <ze> :p
02.00.32 #       <ze> if thats actually it
02.00.47 #       <LinusN> ok, nite all
02.00.50 Part    LinusN
02.01.25 #       <ze> er doh... well if you see the longs, Thanks and goodnight heh
02.01.31 #       <ze> s/longs/logs/
02.12.13 #       <ze> haha it might not be though, apparently i'm using an ip address thats already in use :p
02.17.58 #       <ze> teehee that was it... how stupid
02.18.17 #       <ze> that'll teach me to leave out an /etc/hosts entry for a new system
02.24.38 #       <amiconn> 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 #       <Madman> cool, you fixed the stkov error when making a dir in the new build
08.24.58 #       <Madman> 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 #       <Bagder> ok amp let me out
09.01.07 #       <Bagder> 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 #       <dwihno> 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 #       <Bagder> http://www.opengroup.org/publications/graphics/n900cov.jpg
09.44.33 #       <Bagder> now, can I have that on my car? ;-)
09.45.14 #       <Zagor> :)
09.45.37 #       <Zagor> i would guess both UNIX and LINUX are taken already
09.45.44 #       <Bagder> yeps
09.46.19 #       <Zagor> probably not CURL though ;)
09.46.38 #       <Bagder> its just a bit too expensive to be worth it, imho
09.46.52 #       <Zagor> how much is it?
09.47.07 #       <Bagder> it used to be 5000 SEK
09.47.15 #       <Bagder> for a few years only
09.47.25 #       <Bagder> but I know they talked about raising the fee
09.47.26 #       <Zagor> it's time limited?
09.47.28 #       <Bagder> yes
09.47.32 #       <Zagor> weird
09.47.51 #       <Zagor> deduct it as a marketing expense ;)
09.48.00 #       <Bagder> :-)
09.49.24 #       <Bagder> that plate is available as a mug too ;-)
09.49.30 #       * Bagder considers buying one
09.49.42 #       <Zagor> :)
09.51.38 #       <Bagder> http://www.opengroup.org/bookstore/catalog/n901.htm
09.51.44 #       <Bagder> also a fun product
09.52.02 #       <Bagder> "don't leave home without it" ;-)
09.52.36 #       <Zagor> business card cdroms are always fun. rather useless content though
09.53.20 #       <Bagder> the SUSV3! ;-)
09.53.36 #       <Bagder> when you buy that in hardcopy, is 11kg!
09.54.45 #       <Zagor> haha
09.54.51 #       <Zagor> ...as we all do
09.55.06 #       <Bagder> stupid google refused my app due to "bad postal address"
09.57.27 #       <Bagder> but the mail was in swedish
09.57.42 #       <Bagder> and they didn't say what was bad with it
09.59.43 #       <Zagor> maybe it was in their pyramid scheme blacklist
10.00.32 #       <Bagder> 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 #       <dwihno> hmm
10.01.07 #       <Zagor> haha, and that failed application can never be fixed?
10.01.12 #       <Bagder> yeps
10.01.13 #       <dwihno> 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 #       <Bagder> and since I don't know what the problem was, I'm deemed to repeat it
10.01.22 #       <Zagor> cute system
10.01.44 #       <Zagor> there must be a contact address somewhere
10.01.48 #       <Bagder> yes
10.01.52 #       <Bagder> I mailed them
10.02.10 #       <Bagder> dwihno: you're talking about crc problems on the network?
10.03.14 #       <dwihno> Bagder: Not really... Larger packets seem to trigger the crc failure
10.03.25 #       <dwihno> as long as the packets are small, it runs so smoothly!
10.03.33 #       <Bagder> so the ssh client is what detects the checksum problems?
10.03.43 #       <dwihno> yup
10.04.07 #       <dwihno> there must be a problem in the client since the Z1010 is the only phone with this specific problem
10.04.26 #       <Bagder> yes
10.04.38 #       <Bagder> the traffic is checksumed already on the TCP layer
10.04.54 #       <Bagder> it can't be bad when the app receives it, unless the server sent bad data
10.04.59 #       <dwihno> yeah
10.05.27 #       <dwihno> A couple of larger packets just trigger the internal crc failure
10.05.48 #       <Bagder> it sounds like a good old application bug
10.06.13 #       <dwihno> Rather strange it only occurs on my phon.e
10.08.25 #       <dwihno> Well. I've contacted the author with my findings. Perhaps he has any ideas.
10.33.33 #       <dwihno> 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 #       <Bagder> possibly because you have an usual MTU?
10.49.40 #       <dwihno> MTU?
10.50.00 #       <dwihno> Telia felia lingonbär \o/ :)
10.50.06 #       <Zagor> maximum transmission unit
10.51.40 #       <dwihno> Changeable?
10.53.40 #       <dwihno> Fixable? :)
10.53.42 #       <dwihno> Repairable?
10.54.23 #       <Zagor> 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 #       <dwihno> Okay
10.55.15 #       <dwihno> It is the receiving that breaks, afaik
10.55.20 #       <dwihno> Perhaps MTU affects both?
10.56.42 #       <Zagor> yes
10.59.02 #       <Bagder> I'm just suggesting that the app might have some assumptions in the code that your situation breaks
11.01.44 #       <dwihno> the application assumes larger buffers than the phone has to offer? (otherwise, it should work, huh?)
11.02.32 #       <Bagder> 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 #       <dwihno> It isn't just the checksum
11.04.15 #       <dwihno> I've tried the plain telnet version of the software and it still bangs
11.05.45 #       <dwihno> So if I was to fix the telnet version, the same fix could most likely be applied on the ssh software
11.07.01 #       <Bagder> perhaps the bug is in code used independent of the actual transport (ssh or plain telnet)
11.08.17 #       <dwihno> could be
11.08.28 #       <dwihno> might be
11.08.29 Join    Nibbler [0] (~andrer@port-212-202-78-112.dynamic.qsc.de)
11.08.32 #       <dwihno> must be
11.08.33 #       <dwihno> :-)
11.49.50 Quit    Nibbler (Read error: 104 (Connection reset by peer))
11.53.58 #       <webmind> morning
12.10.03 #       <webmind> anyone here know if linux mass storage driver can take 2 disks on 1 usb-ata controller ?
12.13.15 #       <amiconn> 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 #       <webmind> hmm
12.14.00 #       <webmind> any idea if it would work on the chip ?
12.36.59 #       <Zagor> 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 #       <Zagor> have you checked the data sheet?
12.42.10 #       <webmind> just did.. chip claims to be fully ata/atapi compliant..
12.42.14 #       <webmind> so should be no problem
12.43.09 ***     Saving seen data "./dancer.seen"
12.43.10 #       <Zagor> are you going to mount dual flash cards, or what is your plan?
12.44.42 #       <webmind> my HD on my laptop is dying...
12.44.56 #       <webmind> so i'm thinking of making a portable raid system
12.45.17 #       <webmind> raid I can do in software.. so just need 2 disks
12.46.02 #       <Zagor> aha. battery powered or just movable?
12.46.10 #       <webmind> battery powered
12.46.16 #       <Zagor> neat
12.46.21 #       <webmind> uhuh
12.46.59 #       <webmind> especially since I will probably will be able to combine it with my pda
12.48.33 #       <Zagor> a zaurus? or does anyone else have usb host ports these days?
12.57.21 #       <webmind> uhuh
12.57.26 #       <webmind> 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 #       <Ericgoh> is Zagor here?
15.23.24 #       <Bagder> Zagor: BOOO
15.23.41 #       <Ericgoh> ah...
15.23.50 #       <Ericgoh> got something wanna ask him
15.23.55 #       * Bagder tries to scare him awake
15.24.59 #       <Ericgoh> i am trying to find the datasheets for portalplayer IC, heard that Zagor has it
15.25.14 #       <Ericgoh> wonder is anyone here has the datasheet too?
15.25.23 #       <Bagder> he doesn't have that
15.25.27 #       <Ericgoh> ??
15.25.29 #       <Bagder> I don't think anyone has
15.25.40 #       <Bagder> unless they chop off an arm and a leg
15.26.03 #       <Ericgoh> coz i saw the irc log in rockbox homepage saying that he got it from someone else
15.26.20 #       <Bagder> then I'm wrong
15.26.33 #       <Bagder> but I don't think I am
15.26.50 #       <Zagor> i'm here
15.26.58 #       * Bagder jumps
15.27.06 #       <Bagder> don't scare us like that
15.27.09 #       <Zagor> bagder is right, i don't have the sheets.
15.27.15 #       <Ericgoh> ohh
15.27.32 #       <Zagor> i got an agreement to sign that required me to be their eternal soul slave and sign off my firstborn.
15.27.32 #       <Ericgoh> maybe i misunderstood
15.27.43 #       <Ericgoh> haha
15.29.45 #       <Ericgoh> the stupid portalplayer keep their IC so secret that nobody knows wtf they doing
15.30.18 #       <Bagder> the question is why companies buy it
15.31.17 #       <Ericgoh> ??
15.31.54 #       <Ericgoh> do you mean LSI Logic?
15.32.01 #       <Bagder> why do companies build players based on portalplayer
15.32.34 #       <Bagder> 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 #       <Ericgoh> oh...
15.33.51 #       <Ericgoh> but portalplayer eating the battery power like hell
15.34.22 #       <Ericgoh> also the reason why player based on portalplayer sucks on their playtime
15.34.46 #       <Zagor> i'm guessing the portalplayer chip is part of an attractive package with nearly complete firmware and so on.
15.35.04 #       <Ericgoh> <--agree
15.35.04 #       <Bagder> most likely, yes
15.35.12 #       <Zagor> which means less work for the manufacturer == less risk == easier to calculate for the bean counters
15.35.19 #       <Ericgoh> portalplayer actually selling their solution but not IC
15.35.26 #       <Zagor> right
15.35.41 #       <Bagder> jumping off a cliff is cheap too ;-)
15.36.01 #       <Zagor> :)
15.36.23 #       <Ericgoh> yap, hope ipod jumping off the cliff one day
15.36.28 #       <Ericgoh> really hate ipod
15.37.35 #       <Ericgoh> <--anti-apple
15.37.45 #       <Zagor> i can't say i hate ipod. i more dislike uncritical consumers
15.38.47 #       <dwihno> \o/
15.39.04 #       <dwihno> Regular hard disk players with NORMAL batteries si teh bestest! :)
15.39.24 #       <Bagder> they will be history soon
15.39.56 #       <Ericgoh> hope such day comes as early as possible
15.41.54 #       <dwihno> Bagder: hush! don't say that!
15.42.25 #       <Ericgoh> ipod is now trying to do like microsoft to monopolize the market
15.43.22 #       <Bagder> every company would want to do that
15.43.46 #       <Bagder> but as Zagor said, its the consumers that let them
15.44.06 #       <dwihno> That reminds me. Any of you guys have a cheap 512 meg memorystick duo for sale? )
15.44.10 #       <dwihno> :)
15.44.30 #       <Ericgoh> so consumers should think wise before they buy, not just buying through advertisements
15.44.48 #       <Ericgoh> ??MS DUO
15.44.57 #       <Ericgoh> you want that for what?
15.45.11 #       <Ericgoh> you never get MS for cheap
15.46.29 #       <dwihno> My cell phone
15.46.34 #       <dwihno> I want to keep some music in it.
15.46.40 #       <dwihno> 256 meg chips are affordable
15.47.18 #       <Bagder> when talking about not buying crappy products, memorystick sure is a good thing to mention ;-)
15.47.23 #       <Zagor> does your phone use memorystick? is it a sony?
15.47.25 #       <Ericgoh> that's rare
15.47.45 #       <Ericgoh> haha, what else other than sony use MS
15.47.47 #       <dwihno> Zagor: yep. and the chip is 100% covered as well
15.47.55 #       <dwihno> Ericgoh: Behave :)
15.48.34 #       <Ericgoh> MS license almost double of SD Card, only rich company afford to use that
15.48.36 #       <Zagor> rule #1: never buy sony hardware
15.48.51 #       <dwihno> Zagor: how come?
15.49.18 #       <Bagder> proprietary crap
15.49.20 #       <Zagor> they always use crappy proprietary things like memory stick to force you to buy everything else from sony too
15.49.20 #       <Ericgoh> Sony is throwing all the useless rubbish into MS causing it to be so much bigger than SD
15.49.45 #       <Ericgoh> also increasing the development cost for MS
15.59.39 #       <dwihno> Zagor: well, I'm really satisfied with my phone anyhow :)
15.59.55 #       <Zagor> which model is it?
16.01.04 #       <dwihno> z1010
16.02.31 #       <Ericgoh> how many hours of music can you play with it?
16.02.41 #       <dwihno> Dunno really...
16.02.55 #       <dwihno> I only fit 4 tracks on the chip :)
16.03.38 #       <Ericgoh> haha...wonder what happened to the phone when you find out battery ends becoz of playing music
16.03.52 #       <dwihno> :-)
16.03.56 #       <dwihno> I can live with that
16.05.20 #       <Ericgoh> ??then what the purpose of getting a cell phone?
16.05.40 #       <Bagder> Ericgoh: so your phone never runs out of batteries?
16.06.16 #       <dwihno> Ericgoh: I charge my phone regularly
16.07.15 #       <Ericgoh> my phone can stand for more than 1week
16.07.32 #       <Ericgoh> even i talk frequently, it can still stands for 2-3days
16.08.24 #       <Ericgoh> actually i bought a very stupid phone, 
16.08.43 #       <Ericgoh> but the battery life is very long
16.09.24 #       <dwihno> Well, people should do as they see fit :)
16.09.37 #       <dwihno> And not critisize everyone everytime they think differently
16.09.42 #       <dwihno> Perhaps I should run for president
16.09.45 #       <dwihno> ;)
16.09.50 #       * Bagder votes for dwihno
16.10.22 #       <dwihno> Yay!
16.10.27 #       <Ericgoh> thats not critisize, i am just giving opinion
16.10.30 #       <dwihno> Watch out Kerry - here I come! :)
16.10.57 #       <Ericgoh> coz already got lots of customer complaining about the battery life while playing music on cell phone
16.11.31 #       <Ericgoh> even though they already know how long they can play the music on their cell phone
16.11.31 #       <dwihno> Keeping the phone charged and doubling it as a mp3 player works for me
16.12.00 #       <Ericgoh> everyone thinks like that then we wont get any complain, haha...
16.14.05 #       <dwihno> :-)
16.22.28 #       <Bagder> 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 #       <nevs> 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 #       <amiconn> 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 #       <amiconn> Hmm.
22.00.27 #       <amiconn> Didn't he have some problems with his box?
22.00.50 #       <[IDC]Dragon> yes, he shipped it to me
22.01.44 #       <amiconn> Interesting. Isn't this rather expensive (I assume he lives in the states)
22.01.48 #       <amiconn> ?
22.01.49 #       <dstar5> 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 #       <amiconn> Hmm. Do you already have an idea what could cause this?
22.04.03 #       <[IDC]Dragon> I ran out of them
22.04.33 #       <amiconn> 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 #       <amiconn> One bit only?? Really strange
22.05.45 #       <[IDC]Dragon> the address has to end on FF8
22.06.00 #       <dstar5> 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 #       <dstar5> ohh
22.07.04 #       <[IDC]Dragon> does it have USB2?
22.07.09 #       <dstar5> yes
22.07.11 #       <amiconn> [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 #       <dstar5> [IDC]Dragon: i could send it to you
22.09.07 #       <[IDC]Dragon> dstar5: where are you?
22.09.32 #       <amiconn> [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 #       <dstar5> [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 #       <dstar5> [IDC]Dragon: at customs? why is that?
22.11.56 #       <amiconn> [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 #       <dstar5> ahh   well that sorta is...    heh
22.13.26 #       <amiconn> Ah
22.13.55 #       <[IDC]Dragon> everything with a checksum fails on that box: RoLo, firmware_flash.rock
22.14.55 #       <amiconn> 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 #       <amiconn> 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 #       <amiconn> 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 #       <dstar5> [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 #       <dstar5> 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 #       <amiconn> [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 #       <amiconn> (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 #       <undefinedassasin> h3y
22.49.53 #       <undefinedassasin> where is midk
22.52.51 #       <[IDC]Dragon> back again
22.53.30 #       <undefinedassasin> 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 #       <amiconn> [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 #       <undefinedassasin> Please help me
22.55.00 #       <undefinedassasin> midk is gone
22.55.05 #       <undefinedassasin> and someone is asking me for him
22.55.10 #       <undefinedassasin> but I can't help
22.55.12 #       <amiconn> [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 #       <amiconn> 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 #       <amiconn> 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 #       <amiconn> 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