00:51:22 | DEBUG | Lost contact with server (snapshot: netstuff.c line 597) |
00:51:22 | *** | Saving seen data "./dancer.seen" |
00:51:22 | *** | Cleanup |
00:51:22 | *** | Cleanup |
00:51:22 | *** | No seen item changed, no save performed. |
00:51:22 | *** | Exit |
00:51:22 | *** | Started Dancer V4.16 |
00:51:22 | *** | Connected to irc.freenode.net on port 6667 |
00:51:22 | *** | Logfile for #rockbox started |
00:51:23 | *** | Server message 501: 'logbot :Unknown MODE flag' |
00:51:23 | Mode | "logbot :+i" by logbot |
00:51:23 | | Join logbot [242] (~bjst@labb.contactor.se) |
00:51:23 | | Join gromit`` [0] (~gromit@ALagny-151-1-41-197.w83-114.abo.wanadoo.fr) |
00:51:23 | | Join bagawk [0] (Lee@bagawk.user) |
00:51:23 | | Join amiconn [0] (~jens@pD9E7F9E4.dip.t-dialin.net) |
00:51:23 | | Join mattzz [0] (~mattzz@c227123.adsl.hansenet.de) |
00:51:23 | | Join scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) |
00:51:23 | | Join DeepB [0] (~x@107.Red-217-127-93.pooles.rima-tde.net) |
00:51:23 | | Join _aLF [0] (~Alexandre@mutualite-3-82-67-66-128.fbx.proxad.net) |
00:51:23 | | Join Bagder [0] (~daniel@1-1-5-26a.hud.sth.bostream.se) |
00:51:23 | | Join Ka_ [0] (~tkirk@pcp261180pcs.howard01.md.comcast.net) |
00:51:23 | | Join Hadaka [0] (naked@naked.iki.fi) |
00:51:23 | | Join mbr [0] (~mb@stz-softwaretechnik.com) |
00:51:23 | | Join plok [0] (s336156@student.uq.edu.au) |
00:51:23 | | Join dwihno [0] (~dw@81.8.224.89) |
00:51:23 | | Join elinenbe [0] (~elinenbe_@65.115.46.225) |
00:51:23 | | Join midk [0] (~midk@c66-235-14-120.sea2.cablespeed.com) |
00:51:23 | | Join ze [0] (psyco@adsl-63-205-44-84.dsl.lsan03.pacbell.net) |
00:51:23 | | Join silencer- [0] (~silencer@zen.via.ecp.fr) |
00:51:23 | | Join webmind [0] (~random@217-195-236-172.dsl.esined.net) |
01:00 |
01:00:03 | bagawk | hi logbot :) |
01:00:23 | | Quit bagawk ("umount /dev/brain") |
01:00:38 | | Quit _aLF ("bye") |
01:07:42 | amiconn | :)) mmc driver is now faster for writing as well: 17..80 % |
01:18:57 | | Quit plok ("Leaving") |
02:00 |
02:05:58 | | Quit mattzz ("Client exiting") |
02:09:16 | | Part amiconn |
02:51:24 | *** | Saving seen data "./dancer.seen" |
02:59:45 | | Join Sebulba03 [0] (~Sebulba03@Darth-Sebulba04.active.supporter.pdpc) |
03:00 |
03:02:36 | | Join iRiverMan [0] (~acbfbf7f@labb.contactor.se) |
03:02:43 | iRiverMan | hi |
03:28:35 | | Quit iRiverMan ("CGI:IRC (Ping timeout)") |
03:33:41 | | Quit silencer- (Read error: 104 (Connection reset by peer)) |
04:00 |
04:25:06 | | Part DeepB |
04:51:27 | *** | Saving seen data "./dancer.seen" |
05:00 |
05:01:19 | | Join kramerica [0] (~lkd@hsdbsk207-195-113-154.sasknet.sk.ca) |
06:00 |
06:23:50 | | Quit scott666_ ("i'll be back...eventually...") |
06:23:50 | | Quit kramerica (Read error: 104 (Connection reset by peer)) |
06:51:31 | *** | Saving seen data "./dancer.seen" |
06:53:39 | | Join LinusN [0] (~linus@labb.contactor.se) |
07:00 |
07:12:58 | | Join kramerica [0] (~lkd@hsdbsk207-195-113-154.sasknet.sk.ca) |
07:16:11 | | Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) |
07:55:50 | | Join oxygen77 [0] (~Chris@pauguste-7-82-66-87-78.fbx.proxad.net) |
07:57:33 | | Quit AciD (Read error: 110 (Connection timed out)) |
08:00 |
08:00:04 | | Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) |
08:02:08 | | Join webguest28 [0] (~401829cb@labb.contactor.se) |
08:03:26 | webguest28 | test |
08:03:58 | | Quit webguest28 (Client Quit) |
08:20:46 | | Join amiconn [0] (~jens@pD9E7F9E4.dip.t-dialin.net) |
08:20:48 | | Quit kramerica (Read error: 232 (Connection reset by peer)) |
08:38:34 | | Join Nibbler [0] (~andrer@port-212-202-78-24.dynamic.qsc.de) |
08:41:02 | | Join kramerica [0] (~lkd@hsdbsk207-195-113-154.sasknet.sk.ca) |
08:49:48 | | Join webguest80 [0] (~d996a082@labb.contactor.se) |
08:50:27 | | Part webguest80 |
08:51:34 | *** | Saving seen data "./dancer.seen" |
08:58:22 | | Join [IDC]Dragon [0] (~idc-drago@p50861B66.dip.t-dialin.net) |
08:58:58 | [IDC]Dragon | Hello Jens, do you read? |
09:00 |
09:07:33 | LinusN | [IDC]Dragon: better call for "amiconn", as his IRC client might call for his attention when seeing his nick |
09:07:42 | LinusN | at least mine does |
09:08:11 | [IDC]Dragon | just trying to be nice at first ;-) |
09:09:02 | [IDC]Dragon | LinusN: did you read about the interrupted playback from MMC? |
09:09:57 | | Join Zagor [242] (~bjst@labb.contactor.se) |
09:10:03 | [IDC]Dragon | perhaps the mpeg thread needs some fine-tuning wrt initial load, chunksize, etc. |
09:10:18 | [IDC]Dragon | Hi Zagor! |
09:10:26 | Zagor | ih |
09:10:28 | Zagor | hi |
09:10:59 | [IDC]Dragon | how was the Rockbox-free weekend? (I also had one) |
09:11:32 | Zagor | very good, thanks. i went up north and spent the weekend outdoors. |
09:13:24 | LinusN | [IDC]Dragon: no, i haven' |
09:13:31 | LinusN | t heard about iinterrupted playback |
09:13:48 | LinusN | i also had a rb free weekend :-) |
09:14:21 | LinusN | [IDC]Dragon: i think it might have to do with the dynamic watermark levels |
09:14:29 | [IDC]Dragon | playback works now (I goofed), a bit jerky |
09:14:53 | [IDC]Dragon | but we better discuss that when amiconn is alert |
09:14:57 | LinusN | they are calculated from the disk spinup time, doesn't really apply to mmc |
09:15:26 | [IDC]Dragon | spinup is fast, transfer is slow ;-) |
09:15:41 | [IDC]Dragon | thanks to our SH |
09:15:52 | LinusN | so we need to revise the watermark handling |
09:16:19 | LinusN | we need to do that anyway, since the spinup time measurement bugs |
09:16:37 | [IDC]Dragon | do you think so? what would happen if spinup time measures very fast? |
09:17:23 | LinusN | the watermark level will be set quite low |
09:17:30 | [IDC]Dragon | so? |
09:17:56 | LinusN | and there is increased risk of buffer underrun |
09:20:36 | * | [IDC]Dragon loads some songs on the ondio |
09:23:08 | [IDC]Dragon | USB1 is slooow |
09:25:32 | | Quit Nibbler (Read error: 238 (Connection timed out)) |
09:49:58 | amiconn | [IDC]Dragon: Now I'm around. And: My client alerts me if either my realname or my nick is mentioned. Of course this only helps when I'm around ;) |
09:49:59 | | Quit kramerica (Read error: 54 (Connection reset by peer)) |
09:52:41 | | Join MisticJeff [0] (~MisticJef@lv-65-173-87-243.dyn.sprint-hsd.net) |
09:53:08 | MisticJeff | Zagor, LinusN... good morning |
09:53:13 | Zagor | morning |
09:53:24 | MisticJeff | did you get my email |
09:55:20 | Zagor | yes |
09:56:26 | LinusN | MisticJeff: morning |
09:56:43 | MisticJeff | good morning |
09:57:14 | MisticJeff | don't know whether that will work for you or not but thought i'd throw it out there |
09:57:35 | | Join amiconn_ [0] (~jens@pD9E7E4F2.dip.t-dialin.net) |
10:00 |
10:02:45 | | Join ashridah [0] (ashridah@220.253.120.65) |
10:03:24 | Bagder | Zagor: I and LinusN discussed how to deal with the wildcard sources concept now when iriver enters |
10:04:00 | Bagder | I suggest we introduce a concept with a special file like 'SOURCES' that is preprocessed that mention what source files to build |
10:04:21 | LinusN | i think that's the way to go |
10:04:26 | Zagor | sounds good |
10:04:33 | Bagder | (so LinusN's weekend wasn't _entirely_ rb-free :-) |
10:04:40 | LinusN | :-) |
10:05:08 | Bagder | ok, so I'll start working on setting up such a concept |
10:05:33 | | Join kramerica [0] (~lkd@207.195.113.154) |
10:05:38 | Bagder | it'll be easier to build for iriver target once we have that fixed |
10:05:40 | LinusN | funny, the iriver has separate i2c busses for each i2c slave... |
10:05:49 | LinusN | Bagder: great |
10:09:31 | | Quit amiconn (Nick collision from services.) |
10:09:32 | | Nick amiconn_ is now known as amiconn (~jens@pD9E7E4F2.dip.t-dialin.net) |
10:10:58 | | Quit [IDC]Dragon (Read error: 110 (Connection timed out)) |
10:11:58 | Bagder | -m1 is a sh-specific gcc option, isn't it? |
10:12:06 | LinusN | yes |
10:12:16 | Bagder | needs to be moved to configure then |
10:12:37 | LinusN | it's supposed to be -m5349, but the gcc docs are lying |
10:13:26 | Bagder | so what is it? |
10:14:18 | LinusN | lemme check |
10:15:31 | LinusN | -m5200 might do |
10:16:34 | Bagder | ok |
10:17:15 | Bagder | -fomit-frame-pointer -fschedule-insns is only used in the apps makefile |
10:17:19 | Bagder | is that on purpose? |
10:17:31 | LinusN | i don't think so |
10:18:58 | Bagder | ok, making them global |
10:19:13 | Bagder | oh |
10:19:25 | Bagder | they're added in the firmware as well, but only if non-debug |
10:19:32 | LinusN | of course |
10:19:45 | Bagder | we'll need to set them up conditionally in the configure script instead |
10:28:56 | | Join [IDC]Dragon [0] (~d90a3255@labb.contactor.se) |
10:30:16 | | Join methangas [0] (methangas@0x50c61ce6.virnxx10.adsl-dhcp.tele.dk) |
10:42:47 | amiconn | hi Jörg |
10:42:48 | | Quit kramerica (Read error: 104 (Connection reset by peer)) |
10:46:45 | [IDC]Dragon | Hello Jens |
10:47:07 | [IDC]Dragon | concgratulations to your latest achievements |
10:47:29 | LinusN | [IDC]Dragon and amiconn: are you really sure that you are supposed to speak i2c with the tuner on the ondio? |
10:47:54 | [IDC]Dragon | pretty much, yes (why?) |
10:47:57 | LinusN | i mean, then busenable wouldn't have been present in the 10-pin header |
10:49:13 | [IDC]Dragon | ? |
10:49:34 | [IDC]Dragon | the bus enable is necessary because the pins are shared with the LCD |
10:49:52 | [IDC]Dragon | well, at least the clock |
10:50:00 | LinusN | ah |
10:50:29 | LinusN | funny, why didn't they connect it to the i2c bus instead? |
10:50:58 | [IDC]Dragon | I guess this is because they have the option to mount the Samsung tuner instead |
10:51:08 | LinusN | perhaps |
10:51:10 | [IDC]Dragon | with the classic hookup |
10:51:38 | [IDC]Dragon | one pin is unused, which before was with SPI |
10:51:39 | *** | Saving seen data "./dancer.seen" |
10:51:56 | LinusN | i see now |
10:52:54 | [IDC]Dragon | on the iriver, you are also facing multiple I2Cs, I read above? |
10:54:26 | [IDC]Dragon | so you'd also benefit from a multi-instance capable driver, if worth the effort |
10:56:23 | amiconn | [IDC]Dragon: I thought for a while that you may be right and the mask bit 3 does tell whether there is a tuner or not, because from the Archos site I learned that there is an "original Ondio 128", which shares firmware with the "Ondio 128 FM recorder". However, the Ondio 128 also features a radio |
10:56:24 | | Part oxygen77 ("Cho") |
10:57:22 | * | [IDC]Dragon waits for the wide user base to tell us |
10:57:57 | [IDC]Dragon | maybe the original one has a backlight |
10:58:22 | amiconn | or maybe the original one has a Samsung tuner |
10:58:49 | amiconn | Did you try to dig for the FAT16 bug? |
11:00 |
11:01:10 | [IDC]Dragon | afk, meeting |
11:01:24 | [IDC]Dragon | yes, I did, no success yet |
11:01:35 | | Join Nibbler [0] (~andrer@port-212-202-78-24.dynamic.qsc.de) |
11:06:19 | LinusN | yes, a multi-instance i2c driver is a must |
11:07:03 | LinusN | those koreans must have a bad dictionary entry for "bus" |
11:09:09 | | Join wizzzard [0] (~merlin@dsl-082-082-234-199.arcor-ip.net) |
11:21:27 | ashridah | heh |
11:22:23 | Zagor | bus: A long motor vehicle for carrying passengers, usually along a fixed route. |
11:22:40 | Zagor | what's that got to do with i2c? ;) |
11:23:54 | LinusN | :-) |
11:24:25 | LinusN | see? even your dictionary is wrong! ;-) |
11:24:38 | | Quit Nibbler (Read error: 238 (Connection timed out)) |
11:28:42 | amiconn | Zagor: (merriam-webster) bus: (3) a set of parallel conductors in a computer system that forms a main transmission path |
11:30:05 | | Join Chronic007 [0] (~Miranda@24.30.163.142) |
11:30:37 | | Join iRiverMan [0] (~acbefb5d@labb.contactor.se) |
11:30:48 | iRiverMan | mornign |
11:35:55 | Chronic007 | shhhhhhh.....we don't want to interrupt the technical discussions of the rockbox team.....they may fleet away into private discussions...then I'll have no break from the manotony of my homework.....hahahahahha |
11:36:01 | iRiverMan | can't wit to see rockbox on the iriver |
11:38:00 | Chronic007 | ; - ) |
11:38:18 | ashridah | it's not going to happen overnight. |
11:38:40 | iRiverMan | will it happen eventually |
11:38:52 | iRiverMan | i got an ihp-120 to replace my busted Archos Recorder 10 |
11:39:08 | ashridah | they've gotten the debugger working. things progress. |
11:39:11 | iRiverMan | :) |
11:39:34 | iRiverMan | the iriver can record to wav or mp3, has a radio tuner and supports wav, mp3, wma, asf and ogg |
11:39:35 | Chronic007 | yeaaaa Linus!!!! |
11:40:21 | Chronic007 | Wonder if PaulS has had any luck with his unit |
11:40:54 | iRiverMan | will rockbox on the iriver be the same as rockbox on the archos? |
11:41:22 | LinusN | iRiverMan: yes |
11:41:41 | LinusN | more or less, of course |
11:41:51 | iRiverMan | and if you wanted to, could u revert back to the iriver firmware from rockbox if u wish? |
11:41:51 | LinusN | the platforms are different |
11:41:55 | LinusN | yes |
11:42:14 | iRiverMan | cool |
11:42:24 | iRiverMan | the iriver firmware is good, but playlist handling is a bit poor |
11:43:20 | iRiverMan | so far the only way to shuffle playlists is to manually shuffle them in Winamp |
11:43:32 | iRiverMan | but at least it can shuffle the hard drive without a playlist |
11:43:35 | LinusN | the iriver fw annoys the hell out of me |
11:43:40 | iRiverMan | why linus? |
11:43:47 | iRiverMan | i have an iriver ihp-120 |
11:43:53 | LinusN | one keypress too many, and i'm back in the Playing screen |
11:44:05 | iRiverMan | well nothing practice wouldn't fix |
11:44:19 | iRiverMan | after all it is much more advanced than the Archos |
11:44:21 | Chronic007 | Linus: I agree...and scrolling soooo slow |
11:44:40 | LinusN | and the silly joystick is too slippery |
11:44:51 | iRiverMan | linus the joystick is not slippery |
11:45:08 | LinusN | i can't hold it for long until it slides under my finger |
11:45:11 | iRiverMan | man 5 gigabites transferred in 5 minutes over the USB2.0 port! |
11:45:23 | iRiverMan | i use my thumb on the joystic |
11:45:33 | LinusN | i'll have to put some hot glue or something on it |
11:45:44 | LinusN | i use the thumb as well |
11:45:46 | iRiverMan | I still think its a better machine than the archos |
11:45:52 | LinusN | absolutely |
11:46:04 | LinusN | lightyears ahead, imho |
11:46:06 | iRiverMan | :) |
11:46:14 | iRiverMan | i've got the hitachi HD for my old archos lying around |
11:46:29 | iRiverMan | i decided to save the HD from the Archos |
11:46:32 | iRiverMan | 10gb Hitachi |
11:46:55 | iRiverMan | the iriver uses the 20gb Toshiba drive |
11:47:12 | LinusN | i want at least 40... |
11:47:22 | iRiverMan | i don't like the look of the 40gb iriver |
11:47:28 | iRiverMan | the 20gb one looks better |
11:47:34 | LinusN | perhaps |
11:47:57 | iRiverMan | linus u may kill me if i say this but i very nearly bought an ipod before choosing the iriver |
11:48:03 | Chronic007 | I can't wait till somone figures out how to upgrage the h140 to 80gig |
11:48:27 | Chronic007 | : -) |
11:48:27 | ashridah | Chronic007: you'll have to wait till someone crams the 80g into the 40g drive's formfactor. |
11:48:39 | Chronic007 | already been done |
11:48:47 | iRiverMan | if they can add more "pixie dust" |
11:48:57 | dwihno | faerie dust! :) |
11:49:03 | iRiverMan | ok faerie dust then |
11:49:18 | iRiverMan | Does anyone know any ogg rippers around |
11:49:19 | ashridah | Chronic007: yeah? where/how/who/howmuch? :) |
11:49:53 | iRiverMan | i wonder if the iriver can be reprogrammed to play atrac3 or aac |
11:49:58 | Chronic007 | someone was posting about it at the irver@lounge forums lemme see if I can find the thread......BRB |
11:50:36 | iRiverMan | or mp3pro eveb |
11:50:38 | iRiverMan | even |
11:51:50 | LinusN | iRiverMan: yes, yes and yes |
11:52:19 | LinusN | however, there are patent and license issues |
11:52:55 | LinusN | so we might not be able to do it because of that |
11:52:56 | iRiverMan | lol |
11:52:57 | iRiverMan | ok |
11:53:07 | iRiverMan | well mp3pro is not protected |
11:53:50 | LinusN | then again i wonder why anyone would want mp3pro |
11:54:26 | iRiverMan | because a 64kbs mp3pro sounds as good as 128kbs mp3 in half the file size |
11:54:54 | iRiverMan | so u can squeeze more music on a device |
11:55:44 | iRiverMan | i've compared a 64kbs mp3pro to its original 40mb wav file and the quality is almost as good |
11:56:38 | iRiverMan | :-) |
11:57:02 | iRiverMan | and the quality is certainly better than wma |
11:58:00 | LinusN | lunch time |
11:58:55 | iRiverMan | don't eat too much |
11:59:06 | iRiverMan | :D |
12:00 |
12:00:26 | Chronic007 | Ashridah: Ok back with report, Buckaroo Banzai posted in the @lounge forums "Toshiba announced the start of the production of 30GB and 60GB 1.8" harddisks at the end of august or september" - well it was 60g not 80g sorry didn;t mean to get your hopes up. |
12:00:50 | iRiverMan | lol |
12:01:05 | iRiverMan | whaever happened to those dataplay disks? |
12:02:14 | | Join webguest60 [0] (~82ec60fd@labb.contactor.se) |
12:02:41 | webguest60 | Anybody here? |
12:03:04 | Zagor | webguest60: yes |
12:03:38 | iRiverMan | hi |
12:03:49 | webguest60 | I am looking for information about the mas3587f which is built into some of the rockbox.... |
12:06:14 | Zagor | what do you want to know? |
12:06:14 | webguest60 | Where can I buy the mas3587f circuit? Small order, 2 or 3 circuits.... |
12:06:32 | webguest60 | Preferably in Sweden... |
12:06:36 | Zagor | no idea. tried the usual places? |
12:06:59 | webguest60 | yepp, no go... |
12:07:23 | webguest60 | just a place in easterneurope... |
12:08:17 | | Quit iRiverMan ("CGI:IRC (EOF)") |
12:08:21 | Zagor | it's a very specialized circuit, not many companies carry it. eastern europe is probably as close as you will get. |
12:09:43 | webguest60 | Arrow Electronics sell them in sweden, but only for industries, which probably mean at least 500 circuits a batch :) crap |
12:10:56 | Zagor | you can always ask for a few samples |
12:12:28 | webguest60 | yeah, or contact their customers (sometimes works), |
12:17:35 | | Part MisticJeff |
12:18:33 | | Join R3nTiL [0] (~zorroz@227-250-30-217.kgts.ru) |
12:24:44 | webguest60 | thanks anyway! bye |
12:24:47 | | Quit webguest60 ("CGI:IRC") |
12:31:34 | Bagder | SRC := $(shell cat SOURCES | $(CC) -DMEMORYSIZE=$(MEMORYSIZE) $(INCLUDES) $(TARGET) $(DEFINES) -E -P -include "config.h" -) |
12:31:38 | Bagder | kinda nice ;-) |
12:32:02 | Bagder | even better than include since this "takes" immediately |
12:32:11 | Zagor | skip 'cat' and it will work on windows too |
12:32:43 | Bagder | cat works on cygwin |
12:32:52 | Bagder | we already use cat like that for the link files |
12:34:15 | Zagor | why pipe at all? |
12:34:18 | | Part wizzzard ("Kopete 0.9.0 : http://kopete.kde.org") |
12:36:49 | LinusN | gcc has issues with the file naming |
12:37:16 | LinusN | it doesn't accept all file extensions for preprocessing, iirc |
12:37:53 | Bagder | right, but I probably use < SOURCES |
12:37:58 | LinusN | or rather, it tries to be smart, behaving differently for different file types |
12:38:30 | Bagder | "I can" even |
12:41:08 | amiconn | [IDC]Dragon: r u there? |
12:51:43 | *** | Saving seen data "./dancer.seen" |
13:00 |
13:02:18 | | Join Nibbler [0] (~andrer@port-212-202-78-24.dynamic.qsc.de) |
13:10:10 | | Quit R3nTiL () |
13:13:29 | Zagor | this is a wonderful optical illusion: http://web.mit.edu/persci/people/adelson/checkershadow_illusion.html |
13:17:45 | methangas | yeah i love that one, i didnt believe it until i edited everything else out and putted them next to each other |
13:25:10 | | Join oxygen77 [0] (~Chris@pauguste-7-82-66-87-78.fbx.proxad.net) |
13:28:22 | | Quit Nibbler (Read error: 238 (Connection timed out)) |
13:30:49 | [IDC]Dragon | back again |
13:31:12 | [IDC]Dragon | triggering Jens amiconn |
13:31:17 | amiconn | [IDC]Dragon: Perhaps the following may give you a hint what's going wrong with fat 16: |
13:32:13 | amiconn | (1) At the point the panic occurs, the code tries to write 96 sectors before the first allowed sector. Maybe a coincidence, but the size of the root dir is 32 sectors... |
13:33:04 | amiconn | (2) The panic does not occur when the FAT16 partition is located at the beginning of the disk, because the 96 sectors then wrap around (unsigned) to a very high sector number |
13:33:35 | [IDC]Dragon | oh, so I should panic for that, too |
13:34:37 | amiconn | The FAT code in general (both FAT16 and FAT32) should panic if it tries to access areas outside the partition |
13:35:31 | amiconn | Furthermore, you assign the root dir "virtual" cluster numbers < 0. I wonder how you handle the case that the root dir size is not an integer number of clusters |
13:36:54 | [IDC]Dragon | I do |
13:37:18 | [IDC]Dragon | then the start sector of the "file" is not zero |
13:38:26 | [IDC]Dragon | look into fat_open_root() |
13:39:31 | amiconn | Ah ok. |
13:42:19 | [IDC]Dragon | amiconn: the -96 sector, is that the very first one to be written? |
13:46:53 | oxygen77 | hello, anybody here with some knowledge in XLIB? |
13:48:14 | Zagor | oxygen77: a bit |
13:50:53 | oxygen77 | cool |
13:51:16 | oxygen77 | I'm doing a X simulator for the graphical lib of linav |
13:51:29 | oxygen77 | I can draw in black and white |
13:51:44 | oxygen77 | but now I'm trying to use colors |
13:52:18 | oxygen77 | is there a way to use directly RGB? |
13:53:23 | [IDC]Dragon | Zagor: what am I missing in that optical illusion? |
13:53:44 | Zagor | A and B is the same color |
13:54:07 | [IDC]Dragon | aha? nice |
13:55:22 | amiconn | [IDC]Dragon: Dunno which write causes that; it's the first write that tries to write in the forbidden area and hence causes the panic |
13:56:02 | [IDC]Dragon | really strange that it doesn't happen in the test suite |
13:56:40 | [IDC]Dragon | I stared at the code for endianess or other porting problems, but found none |
14:00 |
14:00:55 | amiconn | [IDC]Dragon: We would need a way to backtrace the call. However, I have no idea how to do this |
14:05:05 | [IDC]Dragon | that's possible, but the worst part is that the player display is so small |
14:05:42 | amiconn | There is lcd_puts_scroll() ... |
14:05:51 | [IDC]Dragon | I was thinking about how I can set something up |
14:06:03 | [IDC]Dragon | on my gdb-capable recorder |
14:06:37 | [IDC]Dragon | I need to install another disk |
14:08:17 | amiconn | I could try to display a part of the stack frame, the figure out what's going on with a disassembler listing |
14:08:36 | amiconn | s/the/then |
14:08:55 | Zagor | [IDC]Dragon: you can always repartition the disk you have, and make a small fat16 partition on it |
14:09:02 | [IDC]Dragon | but before I do that, I wait for my USB2 card, which is on order |
14:09:19 | [IDC]Dragon | the USB2 on my mainboard is unreliable |
14:09:31 | amiconn | [IDC]Dragon: I could do that with my recorder as well, my old 20 GB disk is still laying around... |
14:10:25 | [IDC]Dragon | Zagor: I thought about shrinking my partition, to create a little FAT16 one at the end |
14:10:43 | [IDC]Dragon | but I prefer not to endanger the data on it |
14:11:21 | [IDC]Dragon | I have a "spare" (=empty) 20 GB disk |
14:15:31 | [IDC]Dragon | amiconn: in your new code, I noticed that the delayed write is mapped to the normal write |
14:16:15 | [IDC]Dragon | I don't think that's such a good idea, iirc the WPS calls this once per second to save the resume position |
14:16:19 | Bagder | stand clear for yet another Makefile commit |
14:16:31 | [IDC]Dragon | so we'll have a lot of flash wear |
14:17:01 | [IDC]Dragon | Bagder: uh oh :-/ |
14:17:19 | Bagder | this is just another step forward towards easier life |
14:17:37 | Bagder | like less fixed recorder <=> bitmap <=> FM associations |
14:23:53 | amiconn | [IDC]Dragon: I mapped the delayed write to the normal write because there is no spinup. This was already there with my first version supporting writing. I didn't know that this is accessed *that* often... |
14:24:36 | Bagder | LinusN: here? |
14:25:12 | LinusN | yup |
14:25:26 | Bagder | is it really intended to use -O for debug builds? |
14:25:39 | LinusN | yes |
14:25:43 | Bagder | ok |
14:25:45 | amiconn | [IDC]Dragon: Now that I though about it a bit, I think the backtracing won't be hard. |
14:26:07 | LinusN | Bagder: otherwise the inlining doesn't work, and the scheduler messes up |
14:26:13 | [IDC]Dragon | no, we can just store an array of the params |
14:26:14 | LinusN | iirc |
14:26:15 | Bagder | ah, right |
14:26:55 | [IDC]Dragon | we could even log to fixed sectors |
14:27:58 | amiconn | [IDC]Dragon: I think the idea of displaying the stack frame on panic and the backtracing by hand with disassembled rockbox isn't hard |
14:28:30 | [IDC]Dragon | this is very low |
14:29:16 | [IDC]Dragon | but we couldeven write the stack to disk, for more comfy handling |
14:29:56 | [IDC]Dragon | I once have made a little memory scroll screen (for recorder) |
14:30:59 | | Join Yokalosh [0] (~3efec181@labb.contactor.se) |
14:31:01 | [IDC]Dragon | LinusN: how would you like the idea to be able to scroll back through the stack on panic? |
14:31:28 | LinusN | sounds really nice |
14:31:28 | | Quit Yokalosh (Client Quit) |
14:31:59 | LinusN | still, our panic numbers help a lot today |
14:32:19 | LinusN | i haven't felt much need for a more detailed trace |
14:33:08 | [IDC]Dragon | you had gdb... |
14:33:45 | LinusN | yes, but the panic numbers have often been enough for traceback |
14:34:24 | LinusN | with the panic numbers i can see the exact call chain |
14:34:40 | LinusN | well, not always exact, but close |
14:35:29 | LinusN | still, if you can produce a stack dump, i won't protest |
14:35:44 | LinusN | unless it bloates the code, of course |
14:37:46 | [IDC]Dragon | probably not, a key loop and a printf |
14:38:57 | LinusN | then go for it |
14:39:37 | LinusN | i still want the panic codes |
14:40:57 | [IDC]Dragon | probably the keys don't work any more... |
14:41:35 | [IDC]Dragon | ... without interrupts ticking |
14:43:37 | LinusN | true |
14:51:46 | *** | Saving seen data "./dancer.seen" |
14:55:23 | amiconn | [IDC]Dragon: How would you write the stack to disk? Obviously we can't use the file system, because that's what we try to debug |
15:00 |
15:01:15 | [IDC]Dragon | amiconn: raw sector writing is OK |
15:03:04 | | Join Nibbler [0] (~andrer@port-212-202-78-24.dynamic.qsc.de) |
15:03:42 | Bagder | committed |
15:07:29 | mbr | Hi |
15:07:36 | mbr | One question regarding the new button handling. |
15:07:46 | mbr | I think it inverted old UP/DOWN behaviour on recorder in some places |
15:08:18 | mbr | Zagor did the changes, right? |
15:08:42 | Zagor | yes |
15:08:48 | mbr | Hi |
15:09:07 | mbr | for example Recent and List Bookmarks changed |
15:09:15 | mbr | Previously DOWN got the next older entry, now it is UP |
15:09:22 | mbr | is this intended? |
15:09:50 | mbr | Another example is Debug -> View battery UP/DOWN |
15:10:10 | mbr | Now I need to use UP to get the next page |
15:10:26 | mbr | In fact most debug screens are inverted. |
15:10:36 | Bagder | please cvs update and try the new make |
15:10:45 | Zagor | yes, there was a lot of mixups in the debug screens |
15:11:05 | Zagor | down is now INC in all screens |
15:11:21 | Zagor | uh, pposite :) |
15:12:11 | amiconn | Zagor: Any new button code in the pipe? The problem with the double-left exists in many places.. |
15:12:30 | Zagor | yes, i'll fix it. |
15:12:31 | * | [IDC]Dragon barely dares to ask about the Ondio menu button |
15:13:07 | mbr | I find the Bookmark behaviour a little bit confusing |
15:13:26 | mbr | I think DOWN should get the next older |
15:14:08 | Zagor | possibly, yes |
15:15:49 | amiconn | Zagor: If we have buttons that react both on short & long press, we have to trigger on the release for short presses. However, for long presses we have to trigger on the repeat (already), so the (trailing) release has to be "eaten". Otherwise it triggers another item |
15:16:54 | amiconn | Same goes for buttons with a single function only, that trigger on the keypress itself. |
15:17:20 | LinusN | amiconn: we might want it a little more sophisticated |
15:17:49 | amiconn | LinusN: In what respect? |
15:17:51 | LinusN | like providing some feedback on the down event, but performing the action on release |
15:18:12 | LinusN | to make the interface appear more "snappy" |
15:20:18 | amiconn | LinusN: Another topic, concerning interrupts, yield() and the mmc driver: |
15:21:19 | amiconn | I would make the mmc driver yield() between transfers, because otherwise the ui appears locked for several seconds. |
15:22:01 | amiconn | In order to do this, I'd have to do many things within ISRs, otherwise the performance would drop significantly |
15:23:03 | LinusN | explain |
15:23:15 | amiconn | There would be ISRs (well, one) that may run a bit long, and in order to not block other interrupts, I'd have to enable interrupts within that ISR |
15:23:49 | * | oxygen77 is away: chui pas là |
15:24:00 | amiconn | While this is fine with my ISR, this may screw the set_irq_level() logic in other code (?) |
15:25:19 | | Quit Nibbler (Read error: 238 (Connection timed out)) |
15:25:39 | amiconn | Explanation: With ata, there is one, possibly, long, wait before the start of data transfer. Once the transfer starts, it is done at once. |
15:26:36 | amiconn | With MMC, there is a wait before each block transfer, where the start of block mark has to be polled for. The block transfer itself can be done with dma. |
15:27:09 | amiconn | The wait itself is _relatively_ short, so yielding there would significantly drop performance |
15:27:40 | amiconn | Furthermore, if doing block transfers with dma, the bitswap has to be done afterwards. |
15:28:43 | Bagder | ok, last chance for makefile comments until tonight |
15:29:21 | amiconn | So my idea was to let an isr capture the end-of-block interrupt, then wait for the next block by polling (with interrupts enabled) |
15:30:30 | amiconn | The bitswap is done in the mmc thread, on demand by the isr |
15:32:14 | amiconn | Both the mmc thread and the thread calling the mmc driver could then yield, and while a block transfer is running, other threads could run. (typically for 512*8*4 = 16384 clock cycles) |
15:32:40 | amiconn | Bagder: New configure necessary to test that? |
15:32:45 | Bagder | yes |
15:32:54 | LinusN | Bagder: hang on |
15:33:03 | Bagder | gcc opts moved out from the makefiles to the root makefile |
15:33:17 | Bagder | another coldfire prep |
15:33:50 | LinusN | ls |
15:34:22 | LinusN | oops |
15:34:23 | Bagder | check apps/SOURCES for an example of how this works |
15:35:07 | LinusN | this is great, now we can exclude the grayscale stuff for the player |
15:35:30 | Bagder | yes, very easily |
15:35:46 | LinusN | and lcd-player... driver stuff for the recorder etc |
15:36:00 | LinusN | me likes it |
15:36:05 | Bagder | it should make it easier for your early iriver builds too |
15:36:14 | LinusN | absolutely |
15:39:29 | amiconn | Bagder: YOur new make logic seems to work. Unrelated to this, I get a linker error for the fmr linking rombox "region FLASH is full" |
15:39:59 | Bagder | I noticed that one too |
15:40:05 | Bagder | I don't know why though |
15:41:06 | amiconn | I think it's clear. Rombox doesn't fit into flash, so the linker errors out |
15:41:27 | Bagder | but why doesn't it fit all of a sudden= |
15:41:28 | Bagder | ? |
15:41:39 | Bagder | or didn't it before either? |
15:42:18 | Zagor | fm never fit afair |
15:43:14 | LinusN | the bleeding edge builds fail too |
15:43:58 | Bagder | btw, I bet the daily build will need attention due to the configure needing to be re-run |
15:45:14 | LinusN | you'll have to reconfigure manually |
15:45:36 | LinusN | or fix the scripts |
15:45:42 | LinusN | Zagor? |
15:46:17 | Bagder | I have no time now, the scripts should be fixed to do it every time |
15:46:25 | * | Bagder runs off |
15:46:27 | Zagor | we don't reconfigure anymore, remember? |
15:46:34 | Zagor | it's all from the scratch all the time |
15:46:40 | LinusN | not the daily builds |
15:46:44 | LinusN | only the bleeding edge |
15:46:56 | LinusN | separate scripts |
15:47:04 | Zagor | !?? |
15:47:10 | Zagor | well I did them that way |
15:47:30 | LinusN | last time i checked, only the bleeding edge builds were fixed |
15:47:53 | LinusN | i had to run configure manually |
15:48:05 | LinusN | that's why there were no daily builds for a few days |
15:49:11 | Zagor | ah, found and fixed. a trailing "update" was left. |
15:49:41 | LinusN | goodie |
15:49:57 | Zagor | bleeding works though |
15:52:23 | LinusN | gotta go, cu guys |
15:52:41 | | Part LinusN |
16:00 |
16:24:02 | * | oxygen77 is back (gone 01:00:12) |
16:24:28 | | Part oxygen77 ("Cho") |
16:33:46 | | Quit ashridah ("sleep") |
16:41:12 | | Part Zagor |
16:43:30 | | Join WhiteStar [0] (mithrandir@pD9E1EA4A.dip.t-dialin.net) |
16:43:35 | WhiteStar | Hi |
16:44:23 | WhiteStar | Does somebody want to buy a new JB Car Kit? |
16:44:47 | [IDC]Dragon | what's that? |
16:45:19 | WhiteStar | Er, sorry, it's the Travel kit |
16:45:22 | WhiteStar | http://archos.com/products/prw_500179.html |
16:45:59 | [IDC]Dragon | no, thanks |
16:46:34 | WhiteStar | i had to send my jbr back in and got the money back, but i still have the travel kit... |
16:48:18 | WhiteStar | Is the Gmini 20 any good, besides being unable to run rockbox? |
16:51:12 | [IDC]Dragon | the 220 is definitely cute |
16:51:21 | [IDC]Dragon | besides, I don't know |
16:51:49 | *** | Saving seen data "./dancer.seen" |
16:53:50 | WhiteStar | okay thanks |
16:54:28 | | Join mecraw [0] (~lmarlow@69.2.235.2) |
16:56:04 | | Join mattzz [0] (~mattzz@c159207.adsl.hansenet.de) |
17:00 |
17:01:01 | | Join webguest42 [0] (~3f7cde02@labb.contactor.se) |
17:01:47 | | Quit webguest42 (Client Quit) |
17:04:19 | | Join Nibbler [0] (~andrer@port-212-202-78-24.dynamic.qsc.de) |
17:08:52 | [IDC]Dragon | amiconn: r u there? |
17:11:07 | amiconn | yeps |
17:11:45 | [IDC]Dragon | I suggest using sleep_thread() in the driver |
17:12:05 | [IDC]Dragon | far less overhead than yield() |
17:12:35 | [IDC]Dragon | even the I2C driver uses that while waiting for ack |
17:14:30 | [IDC]Dragon | yield() wakes up all threads |
17:15:24 | amiconn | yes, but does sleep_thread() allow other threads to run? |
17:15:42 | [IDC]Dragon | sleep_thread() will directly enter CPU sleep mode if all other threads are sleeping |
17:16:03 | [IDC]Dragon | but then walk around |
17:17:32 | [IDC]Dragon | causing n context switches |
17:18:00 | WhiteStar | how much would a JB Studio 10 be worth today? |
17:18:24 | [IDC]Dragon | and n-1 threads calling sleep_thread() again, in their wait loop |
17:18:39 | amiconn | WhiteStar: I bought one from eBay for ~90 € |
17:19:32 | amiconn | [IDC]Dragon: I wonder if one walk-around is done in less than ~1.3 ms. Otherwise, performance would drop significantly |
17:21:41 | WhiteStar | hum. well i need a mobile HDD and it should be with mp3-player, so archos seems to be the best choice... |
17:21:53 | WhiteStar | although i had to retourn the JBR0 |
17:21:56 | WhiteStar | *20 |
17:22:33 | [IDC]Dragon | amiconn: 1.3 ms is 1000 cycles! |
17:24:26 | [IDC]Dragon | but you can easily measure it, to check |
17:25:07 | amiconn | 1.3 ms is 16384 cycles (transfer of 512 bytes over SCI @ 3 MBit/s) |
17:26:19 | [IDC]Dragon | ah, sorry, I had it reciproc and all mesed up |
17:26:32 | [IDC]Dragon | messed |
17:26:36 | [IDC]Dragon | see? |
17:27:05 | | Quit Nibbler (Read error: 238 (Connection timed out)) |
17:27:27 | [IDC]Dragon | well, but definitely enough to walk around our ~5 threads |
17:28:15 | | Join gromit``` [0] (~gromit@ALagny-151-1-27-41.w83-114.abo.wanadoo.fr) |
17:28:28 | [IDC]Dragon | if we sleep the CPU, it needs an interrupt to wake it up again |
17:29:02 | [IDC]Dragon | so you can't do that in a pure polling environment, I'd say |
17:36:02 | amiconn | Yes. I can't do that while polling for start of data, hence I wanted to do it while the sector transfer is running. Then I capture the end-of-dma-transfer interrupt |
17:36:46 | amiconn | (That needs dma implemented first, of course) |
17:38:24 | [IDC]Dragon | will that be any faster than now? (or: are you transmitting/receiving back to back currently?) |
17:39:14 | WhiteStar | byebye ^^ |
17:40:29 | amiconn | [IDC]Dragon: (1) What do you mean with back to back? (2) I think it wil be faster than the current implementation, because with the polling approach, there are short pauses between the individual bytes |
17:40:59 | [IDC]Dragon | that's what I meant with back-to-back, yes |
17:41:13 | [IDC]Dragon | if the clock is continuous |
17:42:17 | | Quit gromit`` (Read error: 110 (Connection timed out)) |
17:42:46 | [IDC]Dragon | I'd guess you're just a little bit slower now (haven't checked with the scope) |
17:43:07 | | Quit WhiteStar ("( www.nnscript.de :: NoNameScript 3.79 :: www.XLhost.de )") |
17:43:59 | [IDC]Dragon | I'd like to correct me: yield() is no more expensive, and it returns the control to you without interrupt |
17:45:58 | [IDC]Dragon | so perhaps do this in your polling loop, at least once |
17:46:44 | [IDC]Dragon | (I know, with polling we don't have the whole sector worth of time) |
17:51:08 | amiconn | The problem is that the polling time can vastly differ: from a few 100 clocks to several 10000's |
17:51:40 | [IDC]Dragon | if some other thread has something to do, yes |
17:51:58 | [IDC]Dragon | but that's why we yield, isn't it? |
17:52:31 | [IDC]Dragon | or, you mean the MMC time? |
17:58:13 | amiconn | I mean mmc time |
17:58:29 | [IDC]Dragon | ok |
17:58:46 | [IDC]Dragon | still it more or less matches |
18:00 |
18:01:02 | amiconn | The problem here is that while polling, the mmc has to be clocked, and this can't be done via dma, because we need to catch the first data byte != 0xFF |
18:03:13 | amiconn | (away) |
18:06:34 | [IDC]Dragon | then how about: 1) send command, 2) yield, 3) poll |
18:07:39 | | Join _aLF [0] (Alexandre@mutualite-3-82-67-66-128.fbx.proxad.net) |
18:07:40 | _aLF | hi |
18:11:40 | [IDC]Dragon | amiconn: I'm getting some wild ideas: |
18:11:56 | [IDC]Dragon | byte != FF means falling edge |
18:12:38 | [IDC]Dragon | infortunately, RxD1 has no dual function as an interrupt |
18:14:35 | [IDC]Dragon | perhaps we can clock SCK1 using the Programmable Timing Pattern Controller |
18:15:20 | [IDC]Dragon | and have the serial in an async mode which gives an interrupt when falling |
18:20:09 | [IDC]Dragon | like, setting it to highest baudrate, falling is the start bit, it will give an interrupt somewhat late |
18:30:14 | [IDC]Dragon | either the TPC clock has to be much slower than the async baudrate, such that a framing error interrupt occurs within one TPC cycle, |
18:30:49 | [IDC]Dragon | or the rates have to match and the information in the async receive is recycled |
18:31:24 | [IDC]Dragon | either case would require a fast stop of the TPG |
18:38:35 | | Quit AciD (Connection timed out) |
18:39:21 | [IDC]Dragon | I'm off |
18:39:30 | | Quit [IDC]Dragon ("CGI:IRC") |
18:45:10 | | Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) |
18:49:42 | | Quit elinenbe (" HydraIRC -> http://www.hydrairc.com <- s0 d4Mn l33t |t'z 5c4rY!") |
18:51:50 | *** | Saving seen data "./dancer.seen" |
18:53:16 | | Join salimfadhley [0] (~sal@host-83-146-34-206.bulldogdsl.com) |
19:00 |
19:04:02 | | Quit mattzz ("Client exiting") |
19:22:56 | | Join [IDC]Dragon [0] (~idc-drago@pD9FF886E.dip.t-dialin.net) |
19:23:07 | [IDC]Dragon | hi again |
19:23:17 | amiconn | Ka_: |
19:23:26 | amiconn | erh, I mean: hi |
19:23:56 | amiconn | Found your wild ideas. Unfortunately, this won't work, for several reasons |
19:24:01 | [IDC]Dragon | guess my wild ideas are not too practical :-/ |
19:24:38 | [IDC]Dragon | I was just thinking aloud |
19:24:56 | amiconn | (1) We have to maintain byte sync as long as /CS is low. /CS has to stay low during the whole transfer. Hence no async mode or single clocks possible |
19:25:44 | amiconn | (2) The first bit of the byte we have to catch is _not_ 0, only the last one is. Furthermore, we need the correct value of that byte |
19:27:05 | amiconn | I had some similar wild ideas, that also wouldn't work, like receiving into a TPC register and compare-matching the byte |
19:28:34 | amiconn | The problem with that is that the dma has to be stopped *immediately* after receiving the first byte |
19:34:18 | amiconn | I just made MMC writing another 15% faster (still polling). Same thing for reading is on its way... |
20:00 |
20:13:21 | | Part salimfadhley ("I am slowly drifting away from you....") |
20:23:36 | | Join webguest89 [0] (~8446da7f@labb.contactor.se) |
20:25:08 | | Join kramerica [0] (~lkd@hsdbsk207-195-113-154.sasknet.sk.ca) |
20:30:45 | amiconn | [IDC]Dragon: r u there |
20:30:47 | amiconn | ? |
20:44:58 | | Join Nibbler [0] (~andrer@port-212-202-78-24.dynamic.qsc.de) |
20:44:58 | | Quit kramerica (Read error: 104 (Connection reset by peer)) |
20:45:07 | | Quit webguest89 ("CGI:IRC (EOF)") |
20:47:01 | | Quit Sebulba03 (Read error: 104 (Connection reset by peer)) |
20:51:54 | *** | Saving seen data "./dancer.seen" |
20:59:23 | | Join kramerica [0] (~lkd@hsdbsk207-195-113-154.sasknet.sk.ca) |
21:00 |
21:11:18 | | Quit Nibbler ("¿") |
21:11:18 | | Quit kramerica (Read error: 104 (Connection reset by peer)) |
21:11:52 | | Join Nibbler [0] (~andrer@port-212-202-78-24.dynamic.qsc.de) |
21:29:37 | amiconn | [IDC]Dragon: knock knock! |
21:35:10 | | Join kramerica [0] (~lkd@hsdbsk207-195-113-154.sasknet.sk.ca) |
21:47:17 | | Join scott666_ [0] (~scott666@24.245.58.48) |
21:47:18 | | Quit kramerica (Read error: 104 (Connection reset by peer)) |
22:00 |
22:06:43 | | Nick scott666_ is now known as scott666 (~scott666@24.245.58.48) |
22:07:03 | | Join Paco_ [0] (~Miranda@80.119.248.127) |
22:09:40 | | Quit Nibbler ("¿") |
22:27:02 | [IDC]Dragon | amiconn: I'm here |
22:27:16 | [IDC]Dragon | girlfriend took over the PC |
22:27:16 | amiconn | Ah, finally ;) |
22:27:41 | amiconn | I traced back the call to transfer() which causes the panic. |
22:27:51 | [IDC]Dragon | and? |
22:28:14 | | Quit methangas (" HydraIRC -> http://www.hydrairc.com <- Get hot chicks here!") |
22:29:21 | amiconn | It happens when I go to info->debug->dump rom contents in the write call for the first file (boot rom). Call sequence is as follows: |
22:32:29 | | Join webguest33 [0] (~c7e73180@labb.contactor.se) |
22:33:19 | amiconn | (file.c) write(fd, 0, 0x1000); −−> readwrite(fd, 0, 0x1000, true) |
22:33:24 | amiconn | fd is unknown from the backtrace, but shouldn't be too interesting |
22:33:40 | webguest33 | hi all |
22:34:12 | webguest33 | I have a UI question/comment |
22:34:34 | amiconn | [IDC]Dragon: From readwrite(), the first call to (fat.c) fat_readwrite(&file->fatfile, 128, 0, true) |
22:34:49 | webguest33 | If you're listening to music loud to stay awake driving late at night, |
22:34:59 | webguest33 | and resume is set to YES |
22:35:32 | webguest33 | You can be VERY startled the following morning :) |
22:36:06 | amiconn | [IDC]Dragon: Then the _last_ call to transfer(168, 112, 8182, true) causes the panic. |
22:36:08 | webguest33 | would it make sense to resume at some less loud volume, at least if some time has passed? |
22:36:57 | amiconn | [IDC]Dragon: This is of course correct, since the first valid sector is 264 (== 168 + 96) |
22:42:03 | amiconn | Summary: (file.c) write(fd, 0, 0x1000) (line 565) −−> readwrite(fd, 0, 0x1000, true) (line 471) −−> (fat.c) fat_readwrite(&file->fatfile, 128, 0, true) (line 1969) −−> transfer(168, 112, 8192, true) −−> panic |
22:42:44 | [IDC]Dragon | why the panic then? |
22:43:37 | amiconn | It seems like the code writes the beginning of the file into a sigle cluster, and tries to write the whole remainder into a single cluster chain. Somehow it gets the start sector wrong |
22:44:10 | amiconn | Why panic? Because sector 168 is forbidden, first valid sector is 264 |
22:44:57 | [IDC]Dragon | ah, the panic is correct, see above |
22:45:17 | [IDC]Dragon | is this with the image you gave me? |
22:46:22 | amiconn | Yes, although not precisely, since this would require to put back the image first. |
22:47:13 | | Join Sebulba03 [0] (~Sebulba03@Darth-Sebulba04.active.supporter.pdpc) |
22:49:19 | [IDC]Dragon | btw, how did you trace? |
22:51:06 | amiconn | I defined a static array of 32 longs. Then I put a copy loop at the start of transfer(), which copied 32 values from the stack into the array. Within the if() that detects the panic condition, I put an output loop that shows me the 32 values, 2 at a time. |
22:51:09 | [IDC]Dragon | tracing the sim: first, I get a lot of single sector transfers, the FAT entries |
22:51:57 | *** | Saving seen data "./dancer.seen" |
22:52:24 | [IDC]Dragon | then 16 sectors, a cluster |
22:52:24 | amiconn | This revealed that the call came from fat_readwrite, and the parameters as well. Then I moved that copy loop to the start of fat_readwrite(), which revealed the call from readwrite() and the parameters as well |
22:53:35 | [IDC]Dragon | poor Jens |
22:53:42 | amiconn | Huh? |
22:54:04 | [IDC]Dragon | tedious work, I mean |
22:54:39 | amiconn | Well, it wasn't that hard, althoguh it required a bit of disassembling |
22:55:27 | [IDC]Dragon | do you have the image from before this action? |
22:56:29 | amiconn | One thing I discovered: You extended cluster2sec() (precisely: first_sector_of_cluster() for the cluster < 0 case (fat16 root dir). However, you did not do that for the reverse function, sec2cluster() |
22:58:30 | [IDC]Dragon | it's not used fot FAT16 |
22:58:38 | amiconn | Maybe that it's not necessary, since this is only used within fat_opendir(), which is not used for fat16 root |
22:59:07 | amiconn | AH |
22:59:41 | [IDC]Dragon | how about the image before? |
23:00 |
23:00:10 | amiconn | Yes, I still have the image as I sent it to you |
23:00:46 | [IDC]Dragon | you said your state was different |
23:02:07 | amiconn | Yes because in order to use the exact state again, I would have to put the image back on the box before every experiment. |
23:02:43 | amiconn | This is an USB1.1 box.... |
23:02:48 | [IDC]Dragon | or, just the fat and the root dir |
23:02:57 | amiconn | Hmm. |
23:03:12 | | Join Zagor [0] (foobar@h254n2fls31o265.telia.com) |
23:03:29 | [IDC]Dragon | evening Björn |
23:03:33 | Zagor | hi |
23:03:49 | amiconn | Zagor: evening |
23:03:55 | amiconn | [IDC]Dragon: Have to figure out the exact location, and split the image file accordingly |
23:04:33 | amiconn | And I have to do that twice (once for each function trace) |
23:05:25 | [IDC]Dragon | ? |
23:06:01 | amiconn | Not the "figure out and split file", but the write back to the box |
23:06:31 | amiconn | Zagor: How would you split a large file at a given position, on the unix command line? |
23:09:29 | Zagor | with dd |
23:10:43 | amiconn | Ah, probably using the "seek" option? |
23:11:38 | Zagor | yes, seek or skip |
23:12:19 | Zagor | (they do the same thing, only using different block sizes) |
23:12:21 | | Quit AciD (Read error: 110 (Connection timed out)) |
23:12:58 | [IDC]Dragon | with your image, I get 8 single cluster writes |
23:13:02 | | Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) |
23:13:24 | [IDC]Dragon | plus the fat+dir sectors interspersed |
23:13:40 | amiconn | Ah, seek is for output, skip is for input. Nice, so I can use both, and don't have to split the file beforehand (and one possible error source less) |
23:14:36 | [IDC]Dragon | I have to leave soon, but try to dump my transfer() parameters |
23:19:37 | | Join erik____ [0] (~erik@foxtail.org) |
23:20:41 | | Part Paco_ |
23:20:48 | amiconn | [IDC]Dragon: The offending call to transfer() looks exactly the same as I told above with the original image |
23:22:45 | [IDC]Dragon | with that manysectors? |
23:23:15 | amiconn | yes. The stack frame looks identical |
23:23:21 | [IDC]Dragon | I get no more than a cluster each time |
23:23:35 | [IDC]Dragon | do you see the single sectors as well? |
23:24:02 | amiconn | No. I catch only the call that causes the panic |
23:24:27 | [IDC]Dragon | just in case you would: |
23:24:44 | [IDC]Dragon | I get sigle sector writes like the following: |
23:24:51 | [IDC]Dragon | twice to 264 |
23:25:09 | | Quit erik____ ("Leaving") |
23:25:14 | [IDC]Dragon | then 265 to 279 all in single sectors |
23:25:46 | [IDC]Dragon | (16 calls to transfer() ) |
23:26:02 | amiconn | The fat_readwrite() call looks identical too |
23:26:11 | [IDC]Dragon | then 8 cluster-size calls for the payload |
23:26:52 | [IDC]Dragon | to 680, 696, 712, 728, 744, 760, 776, 792 |
23:27:03 | amiconn | That is the output from the LDEBUGF() macros I guess? |
23:27:10 | [IDC]Dragon | then 2 single sectors, 801 and 264 |
23:27:50 | [IDC]Dragon | that's my breakpoint at transfer() |
23:28:00 | * | [IDC]Dragon sees something |
23:28:10 | amiconn | Telling you just the transfer() calling parameters? |
23:28:21 | [IDC]Dragon | this test code does not combine consecutive access |
23:28:31 | amiconn | Ahhah!! |
23:28:41 | [IDC]Dragon | probably because the max transfer size is faked low |
23:29:08 | [IDC]Dragon | Zagor: do you remember how this is handled? |
23:30:41 | amiconn | Btw: There is an _ugly_ _hard coded_ dependency to ata behaviour in fat.c: It tries to combine consecutive sectors into one ata call, but max. 256 because this is the maximum ata can handle. However, this is not true with MMC |
23:31:30 | | Quit webguest33 ("CGI:IRC") |
23:31:33 | [IDC]Dragon | where it the combining? I can't find it |
23:32:15 | amiconn | fat.c, lines 1912ff |
23:32:34 | Zagor | amiconn: well I wouldn't call it terribly ugly, but yeah there is a limit |
23:32:43 | amiconn | The ata dependency is in line 1955 |
23:33:05 | [IDC]Dragon | the hard coded 256? |
23:33:11 | amiconn | yes |
23:33:26 | [IDC]Dragon | why does it not combine here, then? |
23:34:10 | amiconn | I dunno. |
23:34:25 | [IDC]Dragon | perhaps the test code feeds small chunks |
23:34:56 | amiconn | I'll put a parameter output at the start of transfer(), and retry. Then we can compare the sector numbers & counts |
23:35:42 | [IDC]Dragon | yes, there is an 8 K chunk size |
23:36:07 | [IDC]Dragon | amiconn: you can save that effort |
23:36:14 | amiconn | Okay. |
23:43:19 | [IDC]Dragon | I increased the size to 64K, but this still went smooth |
23:43:44 | amiconn | Hmm. |
23:43:55 | [IDC]Dragon | what a pity, I was really hoping for the problem to show up |
23:44:54 | [IDC]Dragon | it's writing the payload in one swoop, from sector 680 on |
23:45:30 | [IDC]Dragon | the fat+dir traffic looks similar |
23:48:05 | amiconn | I wonder why the target code tries to write 112 of the 128 sectors starting at sector 168 then |
23:49:00 | amiconn | Do you display write accesses only? I'm asking because if I would display read accesses too, it would be tedious to click through at box startup |
23:49:27 | | Quit mecraw ("Trillian (http://www.ceruleanstudios.com)") |
23:49:47 | | Join mecraw [0] (~lmarlow@69.2.235.2) |
23:51:07 | [IDC]Dragon | I broke on read, too,but skipped those |
23:52:55 | [IDC]Dragon | I really gotta go now |
23:53:07 | [IDC]Dragon | maybe we'll nail it tomorrow! |
23:53:13 | | Quit [IDC]Dragon () |