01:43.08 | CIA-10 | 03vapier * r10795 10uClibc/libc/misc/glob/glob.c: import fix from glibc to resolve segfault reported by wmq in Bug 335 |
02:38.20 | *** join/#uclibc zslevin (~zslevin@218.14.8.69) |
03:19.56 | *** join/#uclibc ChanServ (ChanServ@services.) |
03:19.56 | *** mode/#uclibc [+o ChanServ] by irc.freenode.net |
03:50.14 | *** join/#uclibc Delta__ (~delta@p50831710.dip0.t-ipconnect.de) |
03:59.02 | *** join/#uclibc samrobb (~sam@dsl093-061-094.pit1.dsl.speakeasy.net) |
04:23.18 | CIA-10 | 03vapier * r10796 10uClibc/ldso/ldso/ldso.c: use wrapper debug macros to improve readability |
04:50.54 | *** join/#uclibc zslevin (~zslevin@218.14.8.69) |
06:04.23 | jrubio | hi guys anyone familiar with "Data Bus error epc =" messages? |
06:04.37 | jrubio | but I don't get an oops? |
06:24.13 | *** join/#uclibc Jenna (~cherryRed@209.8.233.196) |
06:47.19 | *** join/#uclibc Vincen1 (~root@62.160.74.99) |
06:56.37 | *** join/#uclibc vrm (~vrm@84.55.101-84.rev.gaoland.net) |
07:00.51 | *** join/#uclibc Jenna (~cherryRed@209.8.233.204) |
07:01.17 | *** part/#uclibc Jenna (~cherryRed@209.8.233.204) |
07:21.16 | *** join/#uclibc kezac (~kezac@mxerems.erems.fr) |
07:33.55 | *** join/#uclibc Jenna (~cherryRed@209.8.233.206) |
07:52.10 | *** join/#uclibc ChanServ (ChanServ@services.) |
07:52.10 | *** join/#uclibc hgb (~hgb@cm-80.111.151.063.chello.no) [NETSPLIT VICTIM] |
07:52.10 | *** join/#uclibc cow (~cow@M1105P001.adsl.highway.telekom.at) [NETSPLIT VICTIM] |
07:52.10 | *** join/#uclibc khem (~khem@gateway-1237.mvista.com) [NETSPLIT VICTIM] |
07:52.10 | *** join/#uclibc solar (~solar@smtp.gentoo.org) [NETSPLIT VICTIM] |
07:52.11 | *** join/#uclibc Kaloz (~kaloz@arrakis.dune.hu) [NETSPLIT VICTIM] |
07:52.11 | *** join/#uclibc kergoth (~kergoth@c-24-118-219-25.hsd1.mn.comcast.net) [NETSPLIT VICTIM] |
07:52.11 | *** join/#uclibc rgb (~rgb@Quebec-HSE-ppp230809.qc.sympatico.ca) [NETSPLIT VICTIM] |
07:52.11 | *** join/#uclibc lack (~ramsay@sw-63.SEDSystems.ca) [NETSPLIT VICTIM] |
07:52.11 | *** join/#uclibc ambrose (~bjb@ns1.linuxbutler.ca) |
07:52.11 | *** join/#uclibc vapier (UserBah@wh0rd.org) [NETSPLIT VICTIM] |
07:52.11 | *** join/#uclibc jrubio (~jrubio@ip68-7-124-20.sd.sd.cox.net) [NETSPLIT VICTIM] |
07:52.11 | *** join/#uclibc CIA-10 (~CIA@flapjack.navi.cx) [NETSPLIT VICTIM] |
07:52.11 | *** join/#uclibc mjn3 (~mjn3@c-24-9-47-191.hsd1.co.comcast.net) [NETSPLIT VICTIM] |
07:52.11 | *** join/#uclibc n2n (nobody@n2n.user) [NETSPLIT VICTIM] |
07:52.11 | *** join/#uclibc tchan (~tchan@c-24-13-81-164.hsd1.il.comcast.net) [NETSPLIT VICTIM] |
07:52.11 | *** join/#uclibc waldi (~waldi@waldi.developer.debian) [NETSPLIT VICTIM] |
07:52.11 | *** join/#uclibc svenl (~luther@AStrasbourg-251-1-20-215.w82-126.abo.wanadoo.fr) [NETSPLIT VICTIM] |
07:52.11 | *** join/#uclibc rfs (~rsiemsen@gw-rossvideo.storm.ca) [NETSPLIT VICTIM] |
07:52.11 | *** join/#uclibc Zta (~stephan@port572.ds1-arc.adsl.cybercity.dk) [NETSPLIT VICTIM] |
07:52.11 | *** join/#uclibc GyrosGeier (~geier@a130-233-4-204.debconf5.hut.fi) [NETSPLIT VICTIM] |
07:52.11 | *** join/#uclibc andersee (~andersee@codepoet.org) [NETSPLIT VICTIM] |
07:52.11 | *** join/#uclibc nitinkg (~ngupta@gateway-1237.mvista.com) [NETSPLIT VICTIM] |
07:52.11 | *** join/#uclibc zslevin (~zslevin@218.14.8.69) [NETSPLIT VICTIM] |
07:52.11 | *** join/#uclibc vrm (~vrm@84.55.101-84.rev.gaoland.net) [NETSPLIT VICTIM] |
07:52.11 | *** join/#uclibc Vincen1 (~root@62.160.74.99) [NETSPLIT VICTIM] |
07:52.11 | *** join/#uclibc samrobb (~sam@dsl093-061-094.pit1.dsl.speakeasy.net) [NETSPLIT VICTIM] |
07:52.11 | *** join/#uclibc Delta_ (~delta@p50831710.dip0.t-ipconnect.de) [NETSPLIT VICTIM] |
07:52.11 | *** join/#uclibc mjn3-work (~mjn3@h-66-134-116-110.dnvtco56.covad.net) [NETSPLIT VICTIM] |
07:52.11 | *** join/#uclibc Sgt-Donan (~Loutre@mto30-1-82-242-53-8.fbx.proxad.net) [NETSPLIT VICTIM] |
07:52.11 | *** join/#uclibc carlg (clrsrv@www.clearcore.com) [NETSPLIT VICTIM] |
07:52.12 | *** join/#uclibc ccjoe (clrsrv@www.clearcore.com) [NETSPLIT VICTIM] |
07:52.12 | *** join/#uclibc SpanKY (~UserBah@pool-141-154-58-228.bos.east.verizon.net) [NETSPLIT VICTIM] |
07:52.12 | *** join/#uclibc thomasez (~thomasez@castle.linpro.no) [NETSPLIT VICTIM] |
07:52.12 | *** join/#uclibc ashes (~ashes@modemcable037.175-201-24.mc.videotron.ca) [NETSPLIT VICTIM] |
07:52.12 | *** join/#uclibc flatronf700B (~flatronf7@202.75.186.154) [NETSPLIT VICTIM] |
07:52.12 | *** join/#uclibc _keturn (~kevint@c-24-21-141-200.hsd1.or.comcast.net) [NETSPLIT VICTIM] |
07:52.12 | *** mode/#uclibc [+o ChanServ] by irc.freenode.net |
07:52.54 | *** join/#uclibc samrobb (~sam@dsl093-061-094.pit1.dsl.speakeasy.net) |
08:51.02 | *** join/#uclibc Jenna (~cherryRed@209.8.233.241) |
08:51.23 | *** part/#uclibc Jenna (~cherryRed@209.8.233.241) |
10:02.04 | *** join/#uclibc Jenna (~cherryRed@209.8.233.242) |
10:08.23 | *** join/#uclibc Jenna (~cherryRed@209.8.233.252) |
10:08.45 | *** part/#uclibc Jenna (~cherryRed@209.8.233.252) |
11:17.40 | *** join/#uclibc EvilR1ck (~blah@196-28-86-77.wdsl.co.za) |
11:23.21 | EvilR1ck | hey guys. I built my kernel using the uclibc MIPS cross compile tools that are built by buildroot . My 2.4.29 kernel works fine but If I make a 2.4.30 kernel and modules all my modules dont load. they dump with an "unaligned data access" error and a ton of register info and what not. |
11:23.23 | EvilR1ck | any ideas? |
11:33.23 | rfs | EvilR1ck: just a wild guess, does mips have alignment fixup handler like ARM? |
11:33.37 | rfs | and if so, maybe in the 2.4.30 config its not enabled by default? |
11:33.39 | EvilR1ck | could be .. how do I tell? |
11:33.48 | rfs | diff the .config files for the kernel... |
11:33.48 | EvilR1ck | that sounds about right |
11:34.01 | rfs | or arch/mips/defconfig or whatever it is you use... |
11:34.04 | EvilR1ck | k sec.. |
11:34.21 | EvilR1ck | have to conenct to my home machien to check |
11:37.35 | EvilR1ck | ok.. there are a few diffrences |
11:38.03 | EvilR1ck | what am I looking for? |
11:39.30 | rfs | honestly i don't know :( |
11:39.32 | EvilR1ck | CONFIG_CPU_HAS_LLSC=y ? |
11:40.03 | EvilR1ck | wait no. I know what that is :) |
11:40.05 | rfs | let's look that one up in kconfig help.. |
11:41.08 | EvilR1ck | its a mips flag.. it allows you to force ll and sc support |
11:41.16 | EvilR1ck | I forced it on on my 2.4.29 build |
11:41.33 | EvilR1ck | and I thought removing it from the 2.4.30 build may help |
11:41.36 | EvilR1ck | it didnt :/ |
11:41.54 | EvilR1ck | the rest is netfilter stuff |
11:42.11 | rfs | hmm |
11:42.41 | rfs | you'll need to ask someone who actually has mips :) or maybe google for mips alignment fixup or somesuch. |
11:43.29 | EvilR1ck | checking a makefile diff |
11:43.50 | EvilR1ck | "-fno-strict-aliasing -fno-common -g" the -g option is new in 2.4.30 |
11:43.58 | EvilR1ck | any idea what it does? |
11:44.26 | rfs | that just turns on debugging symbols. |
11:44.47 | rfs | they'll later be removed by 'strip' command. |
11:45.01 | EvilR1ck | yeah :/ damn.. |
11:46.23 | *** join/#uclibc GyrosGeier (~geier@a130-233-4-204.debconf5.hut.fi) |
11:48.14 | rfs | sorry ;( but i'm sure some mips-knowledgable folk will appear before too long ;) |
11:49.19 | EvilR1ck | thanks for teh help anyways :) |
14:08.32 | mjn3-work | EvilR1ck: mips has unaligned emulation. but unaligned instruction accesses will oops. what are you building for? and what modules oops? |
14:11.41 | EvilR1ck | all kernel modules on 2.4.30 building for a idt 4kc core chip on a routerboard 523 |
14:12.09 | EvilR1ck | aparrently an issue with gcc 3.4 and 2.4.30 requires a kernel patch for 2.4.30 |
14:12.45 | EvilR1ck | I built the madwifi modules with the gnu toochain which explains why they work :) |
14:16.15 | mjn3-work | yes. the linux mips maintainers aren't interested in taking patches to fix 2.4.x when built with gcc 3.4 |
14:17.07 | mjn3-work | best use 3.3.x to build the kernel and modules unless you know what you're doing |
14:18.34 | *** join/#uclibc zslevin (~zslevin@59.33.50.35) |
14:19.18 | zslevin | i could not get the kernel filesystem module auto inserting while mounting the partition in Linux 2.6.12.2. |
14:20.11 | EvilR1ck | mjn3: thanks for the advice. any big diffrences between 2.4.29 and 2.4.30? |
14:37.05 | mjn3-work | don't know. i jumped from 2.4.25 to 2.4.30 and then 2.4.31 |
14:37.14 | mjn3-work | didn't look at 2.4.29 |
14:37.24 | mjn3-work | or 2.4.2[678] either |
14:38.46 | *** join/#uclibc svenl (~luther@AStrasbourg-251-1-55-245.w82-126.abo.wanadoo.fr) |
14:41.14 | *** join/#uclibc ambroseL (~bjb@smtp2.symbium.com) |
15:15.36 | *** join/#uclibc carlg (clrsrv@www.clearcore.com) |
15:27.34 | *** join/#uclibc hgb (~hgb@cm-80.111.151.063.chello.no) [NETSPLIT VICTIM] |
16:37.54 | *** join/#uclibc ccjoe (clrsrv@www.clearcore.com) |
16:51.07 | *** join/#uclibc kergoth (~kergoth@c-24-118-219-25.hsd1.mn.comcast.net) |
16:53.01 | *** join/#uclibc kergoth (~kergoth@c-24-118-219-25.hsd1.mn.comcast.net) |
17:14.04 | *** join/#uclibc carlg (clrsrv@www.clearcore.com) |
17:53.47 | *** join/#uclibc ChanServ (ChanServ@services.) |
17:53.47 | *** mode/#uclibc [+o ChanServ] by irc.freenode.net |
17:58.07 | *** join/#uclibc mjn3-work (~mjn3@h-66-134-116-110.dnvtco56.covad.net) |
18:28.11 | *** join/#uclibc andersee (~andersee@codepoet.org) |
19:53.16 | CIA-10 | 03andersen * r10797 10buildroot/package/ (8 files in 5 dirs): (log message trimmed) |
19:53.16 | CIA-10 | Thomas Lundquist writes: |
19:53.16 | CIA-10 | If I understand you correctly, you want the ncurses development headers |
20:02.56 | CIA-10 | 03andersen 07busybox_1_00_stable * r10798 10/: (log message trimmed) |
20:02.56 | CIA-10 | Create a new branch to contain the busybox 1.00 stable tree, allowing |
20:02.56 | CIA-10 | more radical changes and whatnot in the mainline busybox tree. |
20:14.00 | CIA-10 | 03andersen 07busybox_1_00_stable * r10799 10/TODO: trim whitespace |
21:13.25 | *** join/#uclibc andersee (~andersee@codepoet.org) |
21:28.50 | *** join/#uclibc Rigidus (~10339DD46@host217-43-2-45.range217-43.btcentralplus.com) |
21:28.59 | Rigidus | hi all |
21:29.20 | ashes | hi |
21:29.38 | solar | lo |
21:29.55 | Rigidus | guys, i'd have a question :) |
21:29.59 | solar | ashes: did you see ssp is going mainline? |
21:30.21 | solar | July 01 2005 (gcc-patches ml) |
21:30.33 | Rigidus | i have a netgear di-602 router powered by sparc32 cpu |
21:30.52 | ashes | i didn't see |
21:31.27 | Rigidus | it has a 2MB flash and 16MB RAM |
21:31.43 | ashes | libssp |
21:31.48 | ashes | hmm |
21:31.58 | Rigidus | i would need a small linux distribution for it, but the problem is |
21:32.48 | Rigidus | i haven't found any sparc32 based embedded distro for it |
21:33.03 | Rigidus | any idea? :) |
21:33.05 | Rigidus | thx |
21:39.01 | solar | ashes: yeah not super fond of that |
21:39.39 | ashes | it looks like it checks if ssp is in libc first |
21:40.43 | ashes | so its good all around. it will work standalone with gcc, or with uclibc, openbsd, and patched glibc |
21:40.50 | solar | yeah but the general idea of puttting those functions into it's own lib seems wasteful. 4K + 5.5K header (PAGE_SIZE + ELF_HEADERS) * 65536 |
21:41.06 | solar | yeah it's a good thing |
21:41.08 | ashes | you dont have to |
21:41.16 | solar | looks like they have been finding and fixing bugs also. |
21:41.18 | ashes | either way it optional |
21:41.22 | solar | nod |
21:42.02 | solar | but there are some advantages also. per thread guards |
21:43.28 | solar | should be interesting. I'm kinda shocked that redhat has seen the light. |
21:43.45 | solar | I welcome it as of now, thats for sure |
21:43.45 | ashes | i bought granite today for my computer desk. should be finished next week |
21:44.08 | solar | granite as in rock? |
21:44.13 | ashes | yes |
21:44.21 | ashes | polished |
21:44.33 | solar | for bling effect? |
21:44.55 | ashes | ive worn the top off my desk, and i like the shape, so im putting a new top on it which should last a long time |
21:45.07 | solar | oh. |
21:45.25 | solar | Rigidus: better use buildroot. |
21:45.33 | ashes | i have a corner desk |
21:45.50 | solar | sparc has been kinda overlooked. embedded sparc hardware is rare++ |
21:53.52 | Rigidus | solar: thx |
21:55.00 | andersee | Rigidus: indeed. you can get old sun sparc boxes off ebay and such, but few folks find reto computing of that sort to be as exciting as they had hoped |
21:55.42 | andersee | Rigidus: sparc seems to following in the footsteps of the DEC alpha chip... |
21:56.04 | andersee | Rigidus: just not quite so far along the pathway |
21:56.13 | andersee | Rigidus: somewhat sad really |
21:58.09 | andersee | Rigidus: the LEON sparc is sortof interesting, being an open source core... |
21:58.50 | andersee | Rigidus: but generally, sparc tends to be the path less traveled these days, and that makes all the difference. |
21:59.55 | solar | seems that x86/mips/arm are the best supported around here, and by chipmakers |
22:01.12 | solar | with ppc catching up as of recent |
22:01.38 | andersee | best supported by chipmakers tends to produce best supported by uclibc |
22:04.43 | solar | it's my understanding that sparc chipsets tend to produce more heat and require more power/volts than pretty much another other of the major cpus players out on the market |
22:05.39 | solar | I've never tested that, but I'll take that one at face value as it seems pretty logical for that vendor |
22:08.25 | SpanKY | i updated the sparc port so static mostly works ... |
22:08.47 | SpanKY | i also updated the TODO to cover the few neglected arches that i can hack on |
22:09.07 | Rigidus | andersee: thx for the advice :) |
22:10.16 | Rigidus | i've read the buildroot and i find it interesting |
22:11.19 | Rigidus | i'm guessing not going to the bed |
22:11.25 | Rigidus | :D |
22:12.35 | Rigidus | i have to change this firmware anyway |
22:13.29 | Rigidus | and it's all for a nat bug |
22:14.16 | CIA-10 | 03gkajmowi * r10800 10uClibc++/ (6 files in 2 dirs): |
22:14.16 | CIA-10 | Ostream fixed to set eofbit, call flush() less often. |
22:14.16 | CIA-10 | Char_traits fixed to copy characters correctly. |
22:21.55 | CIA-10 | 03gkajmowi * r10801 10uClibc++/include/ostream: Specify parent class for functino call |
22:26.12 | CIA-10 | 03gkajmowi * r10802 10uClibc++/include/functional: Add <basic_defintions> to <functional> |
22:27.55 | Rigidus | i've changed my mind... |
22:28.06 | Rigidus | i'll go to sleep |
22:28.31 | Rigidus | thx for all for everything |
22:28.49 | Rigidus | bye |
22:30.37 | CIA-10 | 03gkajmowi * r10803 10uClibc++/ (ChangeLog include/map): Add multimap::operator= |
22:37.21 | CIA-10 | 03gkajmowi * r10804 10uClibc++/ (BugFinders ChangeLog include/iterator): Implementation of istreambuf_iterator::equal() provided by tommi() |
22:41.46 | SpanKY | andersee: i found the elf spec and i was reading it through ... |
22:44.02 | andersee | SpanKY: yeah, I have a copy in my ~/Standards directory |
22:44.15 | andersee | SpanKY: good stuff |
22:44.58 | SpanKY | sorry, got interrupted heh |
22:45.04 | SpanKY | i didnt finish my statement :) |
22:45.32 | SpanKY | soooooo i found the elf spec and i was reading it through ... |
22:45.41 | SpanKY | it describes the hash tables a bit ... but it just says |
22:45.57 | SpanKY | A hash table of Elf32_Word objects supports symbol table access. |
22:45.59 | CIA-10 | 03gkajmowi * r10805 10uClibc++/ (BugFinders ChangeLog include/stdexcept src/stdexcept.cpp): Fix certain implementations of exception classes. |
22:46.11 | SpanKY | and gives a little diagram (page 84 in my version) |
22:46.45 | SpanKY | so i guess that means that each is a 32bit element ? wording seems a little vague ... |
22:48.12 | SpanKY | the thing that throws me is that their hash function uses unsigned long types ... |
22:48.52 | SpanKY | but their algorithm limits the hash values to 7 bytes right ? (the & 0xf0000000 test triggers a right shift of 24 bytes) |
22:50.47 | andersee | SpanKY: are you concerned there might be a single application with more than 2684354560 symbols? |
22:51.40 | SpanKY | not really, i'm just double checking all the types since ive found a few places where they get truncated :) |
22:52.30 | SpanKY | for example the hash code was declaring the bucket stuff as 'unsigned long' in struct elf_resolve and was using pointers to refer to it |
22:52.39 | SpanKY | so it ended up eating 2 hash codes at a time on my machine |
22:52.46 | andersee | hmmm |
22:53.19 | SpanKY | ive forced them to uint32_t and that seemed to fix hash table reading on x86_64 |
22:53.29 | SpanKY | (at least the output of LD_DEBUG matched that of `readelf`) |
22:54.42 | SpanKY | i'm just double checking behavior versus docs now to make sure forcing it to uint32_t isnt a mistake |
22:55.13 | andersee | the spec does tend to be a bit vague |
22:55.34 | andersee | might be worth the trouble of finding the x86_64 version of the ELF spec |
22:55.40 | andersee | just to double check |
22:55.55 | SpanKY | where can i find that guy ? |
22:56.10 | andersee | not sure |
22:56.12 | SpanKY | oh oh oh, gimme :) |
22:56.19 | andersee | I'd start by asking google |
22:56.36 | SpanKY | i'm going to, but asking you tends to be a bit faster since you know more than me :) |
22:56.56 | SpanKY | i think creating a docs dir in svn might be beneficial eh |
23:59.26 | CIA-10 | 03vapier * r10806 10docs/ (. elf.pdf): start importing some useful docs |