| --- Log opened Sun Jul 20 00:00:27 2014 | ||
| stekern | dalias: yeah, that's fine I think | 04:52 |
|---|---|---|
| stekern | looks like there's more to it than just adding support for msync to the implementations, the assembler doesn't even grok it. | 07:07 |
| olofk | stekern: Ah. One of the famous missing instructions. I think it's kind of funny that after 15 years, we can still find instructions that haven't been implemented :) | 08:32 |
| olofk | Of course, it's not as critical as the one's that were found to be missing a few years ago | 08:33 |
| olofk | blueCmd: I'm about to merge your fusesoc patch now | 08:38 |
| olofk | There are some minor things like unneeded imports that I want to fix. Mind if I alter the patch before I apply it? | 08:38 |
| blueCmd | olofk: oh, like what? | 09:15 |
| blueCmd | oh yes, i see it | 09:17 |
| blueCmd | i'll fix that, spares me a merge conflict | 09:17 |
| blueCmd | olofk: there you go | 09:19 |
| blueCmd | stekern: that patch you sent me for the kernel related to llsc, what does it fix? | 09:55 |
| stekern | it fixes the situation when a l.swa causes a data pagefault | 10:32 |
| stekern | without the patch, the kernel will think that it was a load causing the data pagefault (since it don't match what it thinks is stores) | 10:33 |
| stekern | this typically happen when the kernel has mapped a zero page which is being written for the first time and the write should map the real page and remove the write-protection | 10:36 |
| blueCmd | stekern: ah hm | 10:53 |
| stekern | I get a feeling I wasn't clear enough ;) | 10:57 |
| blueCmd | stekern: nah, it think I got it - but I'm trying to think of if that could break my atomics the way they are broken | 11:01 |
| stekern | ah, ok. if you'd experience the bug, it would just go into a data pagefault loop around the l.swa | 11:03 |
| blueCmd | stekern: hm, it would lock the system I guess? | 11:06 |
| stekern | well, 'lock' in that sense that it will not be doing anything else than constantly serving that data pagefault over and over again | 11:30 |
| blueCmd | stekern: my programs lock, but they are running (as in, I can Ctrl-C them) | 11:36 |
| blueCmd | if I understand you correctly, this bug would lock up the whole system and that would not be possible | 11:36 |
| stekern | hmm, a signal can probably intercept that loop | 12:07 |
| stekern | so maybe my description of the 'lockup' wasn't right/clear | 12:08 |
| blueCmd | 25f8: e4 27 38 00 l.sfne r7,r7 | 12:29 |
| blueCmd | 25fc: 13 ff ff eb l.bf 25a8 <main+0x44> | 12:29 |
| blueCmd | that seems wasteful | 12:29 |
| stekern | heh, where does that come from? | 12:30 |
| blueCmd | stekern: the Wonderful and Almost Perfect Atomic Generation (TM) | 12:31 |
| blueCmd | or WAPAG as I usually call it | 12:31 |
| blueCmd | http://1ad5e858b3f435a9.paste.se/ | 12:34 |
| blueCmd | trying to figure out why that loops seemingly forever | 12:34 |
| blueCmd | hm, it loads a value to r7 before the compxchg which compxchg overwrites which it later tries to compare against | 12:40 |
| blueCmd | right, it sets r7 to 0, so the thing it wants to compare is if it succeded or not | 12:40 |
| blueCmd | I might have found the error and we shall never ever speak of it again.... | 12:57 |
| blueCmd | also, I'm deeply disappointed in you stekern. It's your role as code reviewer to find bugs in my code, clearly the biggest blame here is on you ;) | 12:58 |
| blueCmd | (patch that I hope will fix stuff http://b27136a600468082.paste.se/) | 12:59 |
| poke53281 | blueCmd: Did you also succeed implementing the ata device. We discussed this a month ago. | 13:00 |
| blueCmd | poke53281: yes, no I didn't figure it out - I resorted to use virtio instead | 13:01 |
| poke53281 | Yes I read your email. | 13:01 |
| blueCmd | poke53281: actually I totoally forgot about that I tried to use ATA and was a bit confused when I was about to commit the virtio stuff (What? Did _I_ write this?) | 13:01 |
| poke53281 | Hehe | 13:02 |
| poke53281 | You could also mount the 9p filesystem. | 13:02 |
| blueCmd | Yes, that's what I do, but I didn't show it in the screencast | 13:02 |
| blueCmd | it's super convienient and fast | 13:03 |
| poke53281 | Ok, so one important question for me. You can compile a linux kernel that boots Debian? I have still problems with chrooting to Debian when I try a kernel. | 13:04 |
| poke53281 | I still think, that qemu-user is much faster, than a full emulation. | 13:04 |
| blueCmd | poke53281: Hm, I think I can - I get weird lockups though, possibly related to the atomic thing I'm fixing now | 13:04 |
| blueCmd | poke53281: it is, but I require pthreads | 13:04 |
| poke53281 | I get a segmentation fault, when I try to chroot to Debian. | 13:05 |
| blueCmd | hah, that's no good! :) | 13:05 |
| poke53281 | I use your linux kernel in your github repository. | 13:05 |
| blueCmd | poke53281: yes, it was broken :( | 13:06 |
| blueCmd | poke53281: sorry about that | 13:06 |
| poke53281 | was | 13:07 |
| blueCmd | I just updated it the nice rebase stekern did | 13:07 |
| poke53281 | ? | 13:07 |
| poke53281 | It was updated last time on May 19th | 13:07 |
| blueCmd | that should work, but you might need one additional patch (use branch 'mexiko' or apply https://github.com/bluecmd/or1k-linux/commit/97c652a9abd224039bba25848cd5016b15a52654.patch | 13:07 |
| blueCmd | poke53281: well, not really - I replaced the old repository with stekerns rebase | 13:08 |
| blueCmd | it's a forced push so you might want to re-download it if you have changes on top of it | 13:08 |
| poke53281 | Ok, trying | 13:08 |
| blueCmd | my repository was getting out of hand with weirdness | 13:08 |
| poke53281 | Thanks | 13:08 |
| blueCmd | np, thanks for poking me about it | 13:08 |
| poke53281 | By the way. Yesterday I saw jor1k running on a relatively new Intel CPU. 200 MIPS! | 13:09 |
| poke53281 | That is more the speed of an AMD K6 CPU or a Pentium 2. | 13:10 |
| blueCmd | woo! :D | 13:11 |
| poke53281 | Ahh, by the way. We should implement the idle state in the Linux kernel. | 13:11 |
| blueCmd | yes | 13:11 |
| poke53281 | Also for QEMU. | 13:11 |
| blueCmd | yes yes yes x 1000 | 13:11 |
| poke53281 | It is relatively easy. A few lines in Linux | 13:11 |
| poke53281 | http://pastie.org/9407139 | 13:13 |
| poke53281 | I use my special "halt opcode" | 13:13 |
| poke53281 | But according to the spec I should use l.mtspr ... | 13:14 |
| poke53281 | Well, no problem. I read the spec after the implementation :) | 13:14 |
| blueCmd | :) | 13:15 |
| poke53281 | There must be also a check, whether the cpu supports the sleep mode. | 13:15 |
| poke53281 | I should add this check to the patch and send it to the mailing list | 13:37 |
| poke53281 | http://pastie.org/9407221 | 14:13 |
| poke53281 | stekern , blueCmd : If there is no objection I will send this patch to the mailing list. | 14:14 |
| poke53281 | Suggestions welcome | 14:14 |
| stekern | is the SPR_UPR_PMP define correct in the kernel? | 14:14 |
| stekern | it has been wrong somewhere, can't remember where though | 14:15 |
| poke53281 | #define SPR_PMR_SDF 0x0000000f /* Slow down factor */ | 14:15 |
| poke53281 | #define SPR_PMR_DME 0x00000010 /* Doze mode enable */ | 14:15 |
| poke53281 | #define SPR_PMR_SME 0x00000020 /* Sleep mode enable */ | 14:15 |
| poke53281 | #define SPR_PMR_DCGE 0x00000040 /* Dynamic clock gating enable */ | 14:15 |
| poke53281 | #define SPR_PMR_SUME 0x00000080 /* Suspend mode enable */ | 14:15 |
| poke53281 | ups, wrong table | 14:15 |
| poke53281 | #define SPR_UPR_PMP 0x00000100 /* Power management present */ | 14:16 |
| stekern | minor nit, the kernel coding style claims that there should be an empty line after the '/*' in block comments | 14:16 |
| poke53281 | Done | 14:16 |
| stekern | yeah, that's wrong. it should be 0x00000200 (1<<9) | 14:18 |
| poke53281 | Yes, I see. Thanks for mentioning it. | 14:18 |
| stekern | not your fault, but that needs fixing before you can use it in your code | 14:19 |
| poke53281 | No problem. Then two patches. | 14:20 |
| poke53281 | PIC and PMP must be exachanged in the table. | 14:21 |
| stekern | ok, I've got binutils emitting l.msync, l.psync and l.csync now | 14:33 |
| stekern | blueCmd: don't worry, I take full responsibility for that bug! | 14:37 |
| stekern | or1ksim threats them all as no-op instructions | 14:41 |
| blueCmd | *sigh* rebasing glibc to the latest version is forcing me to implement nocancel read/write | 14:50 |
| blueCmd | oh well, I didn't know those existed so it will probably solve bugs if I implement it | 14:50 |
| stekern | that's related to how glibc implements cancellation points, right? | 14:55 |
| blueCmd | stekern: I have no idea yet | 14:59 |
| stekern | I'm pretty sure it is | 15:08 |
| blueCmd | stekern: hm, i was a bit quick on calling that the bug, re-reading it the first way was correct | 17:03 |
| blueCmd | I think I'm just missing a "early clobber" on retval or something | 17:06 |
| dalias | the nocancel ones are just noncancellable versions of the functions that would otherwise be cancellation points | 17:09 |
| stekern | https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=018dc9bedf40d528f1d05d56555e20ed54a77dc3 | 17:29 |
| blueCmd | stekern: if you continue pushing stuff at the same pace as you have now, you will soon lose respect and push something bad :-) | 17:34 |
| blueCmd | you're supposed to sweat and not be able to sleep for 3 nights when you push to upstream | 17:34 |
| stekern | yeah, I know... | 17:36 |
| stekern | actually, the commit message had a typo in it | 17:38 |
| stekern | it's already happening | 17:38 |
| blueCmd | http://static1.gamespot.com/uploads/ignore_jpg_scale_medium/1188/11888561/2562405-6086807432-Happe.gif | 17:38 |
| stekern | "This webpage is not available" | 17:39 |
| blueCmd | dalias: what would the effect be if I make all syscall non-cancellable? | 17:40 |
| blueCmd | http://1.bp.blogspot.com/-vpE6uMJ37dk/UOScrne47aI/AAAAAAAAEL4/Ki-4IWO-SoY/s1600/ron-paul.gif | 17:40 |
| blueCmd | stekern: this gif is everywhere, so don't fret - I have an unlimited supply of links to the same gif | 17:40 |
| stekern | ;) | 17:40 |
| dalias | bluecmd, it would be non-conforming | 17:42 |
| dalias | read and write are both required to be cancellation points | 17:42 |
| blueCmd | dalias: right, but for debugging | 17:42 |
| blueCmd | dalias: I've done so now, and I'm having trouble Ctrl-C'ing ping for example | 17:43 |
| blueCmd | but I'm not sure if that's relevant | 17:43 |
| dalias | unless the bug you're encountering is happening in a program that's performing cancellation, i don't think it will make any difference | 17:43 |
| dalias | i really doubt ping is multithreaded or using pthread_cancel | 17:43 |
| blueCmd | right. this is busybox's ping so it might do some weird stuff but that was what I was thinking | 17:44 |
| blueCmd | oh jikes. I have a 19 days streak on github apparently | 18:03 |
| poke53281 | blueCmd: Interesting. With the new kernel neither ethoc nor fboc seems to work. For example I get a "Framebuffer registration failed" error | 18:32 |
| blueCmd | poke53281: hm, weird | 18:32 |
| poke53281 | ATA seems to work. And all other drivers too. | 18:33 |
| blueCmd | poke53281: ethoc has an endian patch, if you open ethoc.c in the kernel you should be able to see #ifdef CONFIG_WISHBONE_BIG_ENDIAN or something | 18:34 |
| poke53281 | Hmm, Ok. I will take a look. | 18:38 |
| poke53281 | Does someone know how to get a log of the changes of the file sorted by date? | 18:39 |
| mor1kx | [mor1kx] skristiansson pushed 1 new commit to master: https://github.com/openrisc/mor1kx/commit/2e695ee7f57976af8a7732acf1e3e52d7f671a48 | 18:39 |
| mor1kx | mor1kx/master 2e695ee Stefan Kristiansson: decode: do not generate illegal insn exception on l.msync... | 18:39 |
| poke53281 | git log -p filename | 18:39 |
| poke53281 | does not sort | 18:39 |
| blueCmd | really? i just do 'git log filename' | 18:39 |
| blueCmd | ah sorry, no it won't be by date | 18:40 |
| blueCmd | it will be in order, but not by date | 18:40 |
| poke53281 | this is exactly, what screwed me. Because I checked for changes before I asked you. | 18:40 |
| poke53281 | But I missed them, because I expected a sorted list. | 18:40 |
| dalias | :) | 18:41 |
| dalias | i think git log has multiple options for how it orders the results | 18:41 |
| dalias | but i'm not sure if "by date" is one | 18:41 |
| stekern | poke53281: you didn't fully emulate to ocfb, right? | 18:41 |
| dalias | most of them looked topological last i checked | 18:41 |
| poke53281 | no | 18:41 |
| poke53281 | But the registration is the last step. And I checked for changes in the probing function. | 18:42 |
| poke53281 | But maybe, I should check again | 18:42 |
| stekern | that's probably it then, the upstreamed driver detects endianness by writing a value to the base address register and reading it back | 18:43 |
| blueCmd | -funroll-all-loops | 18:45 |
| * blueCmd giggles | 18:45 | |
| dalias | http://funroll-loops.info/ | 18:46 |
| blueCmd | " I have used many different kernels and all sorts of optimization combinations-yesterday I finally used -noatime and -notail for my reiserfs file system: The single biggest performance boost I have yet to see-" | 18:48 |
| blueCmd | *sigh* | 18:48 |
| blueCmd | yeah, why would have thought that tuning your IO would be the low-hanging fruit | 18:48 |
| blueCmd | who* | 18:48 |
| blueCmd | olofk: <3 | 18:50 |
| olofk | poke53281: If PICP and PMP are swapped in the kernel, and you're fixing that, please put a note here as well http://bugzilla.opencores.org/show_bug.cgi?id=77 | 18:54 |
| blueCmd | oh I hate bugzilla | 18:59 |
| blueCmd | "List all open bugs". would that be so hard? | 19:00 |
| poke53281 | olofk: done | 19:13 |
| poke53281 | @stekern: This endianess is just weird. | 19:15 |
| poke53281 | This check is especially weird. | 19:17 |
| poke53281 | But finally it works | 19:27 |
| poke53281 | Now, the ethoc | 19:27 |
| stekern | umm, what's weird about it? | 19:35 |
| poke53281 | what was the original write command to the registers? | 19:39 |
| poke53281 | I tried every combination. And only one is working. | 19:39 |
| poke53281 | And the working combination is not compatible with the old implementation. | 19:40 |
| poke53281 | Mhh, there is a new .config option which I might have to activate. | 19:42 |
| poke53281 | Framebuffer foreign endianness support | 19:42 |
| poke53281 | The detection method is especially weird. | 19:44 |
| stekern | well, I couldn't use the wishbone endianness config option, since it's not upstream | 19:45 |
| stekern | and it's not even certain that the core would sit on a wishbone bus | 19:46 |
| stekern | the detection method is just writing a value to the register and see if it comes back the same way. | 19:47 |
| stekern | I don't understand what's so strange about it | 19:48 |
| poke53281 | Well, why do you think, that this works. The framebuffer device must support this. | 19:48 |
| stekern | the foreign framebuffer option is for the framebuffer, the detection is for the registers | 19:49 |
| poke53281 | Why should the reading part be different wired than the writing part? | 19:49 |
| stekern | it wouldn't, but the ioread/write functions are not endian agnostic | 19:51 |
| poke53281 | Now it works in both directions. The foreign framebuffer option must be compiled in in order to work. | 19:52 |
| stekern | so a ioread on a be machine will be converted to le | 19:52 |
| poke53281 | Therefore I got the registration failure. | 19:52 |
| stekern | so, is your framebuffer wired like that? | 19:53 |
| poke53281 | Ahh, Ok. | 19:53 |
| poke53281 | this.addr = Swap32(value); | 19:53 |
| poke53281 | Always I had to swap the value which was send over the bus. | 19:54 |
| poke53281 | So, yes | 19:54 |
| poke53281 | With the new framebuffer, it is no longer necessary. | 19:54 |
| poke53281 | new framebuffer driver .... | 19:55 |
| blueCmd | bah, remind me. r3 is return value? | 19:56 |
| blueCmd | or is it r11 or something? | 19:56 |
| blueCmd | yes r11 | 19:57 |
| stekern | ...and r12 | 20:01 |
| blueCmd | right.. | 20:02 |
| blueCmd | hm | 20:02 |
| stekern | not sure why we have a separate register for return value. | 20:02 |
| blueCmd | I wonder if 64 bit return value are going to work for syscalls :P | 20:02 |
| stekern | iirc Joern explained some corner case where that might be beneficial | 20:02 |
| blueCmd | tail-recursion maybe? | 20:03 |
| olofk | blueCmd: http://bugzilla.opencores.org/buglist.cgi?query_format=advanced&order=Importance&bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS | 20:05 |
| blueCmd | olofk: are you a wizard? | 20:07 |
| blueCmd | olofk: If I told you that in my life I've probably spent hours trying to do that | 20:07 |
| blueCmd | I would only slightly exagerate | 20:07 |
| olofk | :) | 20:09 |
| olofk | I am the god of bugzilla. You can call me godzilla | 20:09 |
| blueCmd | olofk, keeper of the 61 bugs | 20:10 |
| olofk | blueCmd: Yeah, I got a bit power crazy for a while there | 20:10 |
| blueCmd | olofk: I'd imagine | 20:10 |
| stekern | poke53281: note that if you are using the foreign framebuffer option, you have to either use 32-bit or make sure the programs honor that flag | 20:11 |
| olofk | Hmm.. I wonder where that patch is that I'm talking about in a comment in bug 77 | 20:12 |
| stekern | xorg doesn't for instance | 20:12 |
| stekern | I had completely forgot about bug 77 | 20:13 |
| stekern | I just remembered that the define was wrong somewhere ;) | 20:15 |
| poke53281 | Before my patch get applied to the kernel we should be sure if we want to follow the specification or not. | 20:15 |
| olofk | My plan was to release a version 3 of or1200, so that we could do invasive changes after that | 20:15 |
| olofk | But I almost killed myself trying to write a changelog | 20:16 |
| olofk | It's a fucking mess | 20:16 |
| stekern | poke53281: does jor1k follow the spec or the kernel definition? | 20:18 |
| stekern | mor1kx follow the spec at least | 20:18 |
| poke53281 | the spec. | 20:19 |
| poke53281 | But so far it didn't matter. | 20:19 |
| stekern | then we are two against one ;) | 20:20 |
| poke53281 | I implemented today the check if the pmu is installed or not, | 20:20 |
| poke53281 | spec, verilog, linux, or1ksim, qemu, jor1k. | 20:21 |
| poke53281 | All have to be checked. | 20:22 |
| poke53281 | For consistency. | 20:22 |
| poke53281 | so far the kernel didn't care about it. | 20:22 |
| stekern | yeah, it just printed some info about it | 20:22 |
| poke53281 | The worst thing, that can happen with my patch is, that the kernel writes to an unknown register via l.mtspr. | 20:22 |
| poke53281 | to the pmu register. Nothing really serious. | 20:23 |
| blueCmd | poke53281: which can be pretty bad :P | 20:23 |
| stekern | no, to the pic register... | 20:23 |
| stekern | ah, no... right PMU | 20:23 |
| stekern | but anyway, the spec should be the reference. if there is some need for special handling for buggy implementations, so be it. But at least spec compliant implementations should be handled correctly first hand. | 20:25 |
| poke53281 | if the pmu is not installed, nothing will happen. In the worst case we get an exception or so. | 20:25 |
| poke53281 | At the moment I can't see a good workaround. | 20:28 |
| stekern | yeah, except something like a static config for broken implementations | 20:29 |
| blueCmd | stekern: does "ping" work for you with musl and your latest kernel? | 20:30 |
| blueCmd | it sends one ping and then just hangs for me | 20:30 |
| blueCmd | seems to be related to SIGALRM, but I'm not sure | 20:30 |
| stekern | I don't think I've tried, wait | 20:31 |
| stekern | works here | 20:32 |
| stekern | but I'm not using the master branch, I'm using my smp branch | 20:32 |
| blueCmd | also | 20:33 |
| blueCmd | https://github.com/skristiansson/musl-or1k/blob/1a18cf235f5edb2d3fb056f6d8e08e82ebf806fb/src/ipc/semctl.c | 20:33 |
| blueCmd | has IPC64, what gives? | 20:33 |
| blueCmd | ah right, you defined it to 0 | 20:33 |
| stekern | yes | 20:33 |
| blueCmd | openat(AT_FDCWD, "/dev/sem.PBpq8p", O_RDWR|O_CREAT|O_EXCL, 0700) = 3 | 20:40 |
| blueCmd | hah, not sure but that doesn't seem the correct way to test semctl | 20:40 |
| stekern | what are you looking at? | 20:42 |
| blueCmd | strace of a libc testuite | 20:43 |
| blueCmd | should be what "sem_open" does | 20:43 |
| blueCmd | oh, it might be correct looking at the code | 20:45 |
| blueCmd | stekern: which branch is that you're running of the körnöl? | 21:07 |
| blueCmd | http://git.openrisc.net/cgit.cgi/stefan/linux/log/?h=smp ? | 21:07 |
| stekern | jupp | 21:08 |
| stekern | that enables the SPR scratch reg hack by default though | 21:09 |
| stekern | http://git.openrisc.net/cgit.cgi/stefan/linux/commit/?h=smp&id=3396c439282a68b3e933bdd86b731c30a897889e | 21:10 |
| stekern | I'm working on implementing a proper solution in mor1kx now | 21:10 |
| stekern | that hack works in or1ksim though, since those SPR are read/writeable there | 21:11 |
| stekern | not sure if it works in qemu | 21:11 |
| stekern | it's not working in a vanilla mor1kx | 21:11 |
| blueCmd | I wonder if it will work in qemu | 21:12 |
| stekern | you can just turn those #if 1 into #if 0 and it will revert to the old behaviour | 21:13 |
| blueCmd | nothing on my screeeeeen | 21:14 |
| blueCmd | do I need to use something from simple_smp.dts ? | 21:15 |
| poke53281 | I didn't follow the discussion. What is the status for the multi-core environment? | 21:16 |
| blueCmd | poke53281: it's fine if you hate console output | 21:16 |
| stekern | blueCmd: ? | 21:16 |
| blueCmd | it's very very quiet, we could call it Zen Linux - too bad it's already a thing | 21:17 |
| poke53281 | Usually I like console output. | 21:17 |
| stekern | I have console output on a dual-core here ;) | 21:17 |
| stekern | blueCmd: you can use the old or1ksim_definconfig and the accompanying .dts | 21:17 |
| poke53281 | Better than a gui with a tabulated output but no "copy" support | 21:17 |
| blueCmd | stekern: I'm a simple man, I want output on my unicore :P | 21:17 |
| olofk | I have console output on a quadcore here. It's an intel though | 21:17 |
| blueCmd | stekern: I have a bit of changes to or1ksim.dts that I would rather keep | 21:18 |
| stekern | yeah, that shouldn't be an issue | 21:18 |
| blueCmd | that's why I asked about if there there was any specific things I need to move over, like ompic | 21:18 |
| stekern | ompic is only needed for CONFIG_SMP | 21:18 |
| blueCmd | oh, maybe I should =n that | 21:19 |
| blueCmd | if I'm not using it | 21:19 |
| stekern | yeah, but it's not enabled by default | 21:19 |
| stekern | I can build you a kernel that boots in or1ksim without the spr hack | 21:20 |
| stekern | just to check | 21:20 |
| blueCmd | stekern: no, but I enabled it! | 21:20 |
| blueCmd | "why should I not run the latest code?" I thought | 21:20 |
| olofk | hmm... can I change temporarily change the DNS server easily? | 21:21 |
| blueCmd | olofk: you can just overwrite /etc/resolv.conf I guess | 21:21 |
| olofk | ah yes. That's where it is | 21:22 |
| stekern | ok ;) in the long run, we should of course support running a SMP enabled kernel on a unicore soc, but I doubt that will work as things currently stands | 21:23 |
| olofk | Things just tend to work nowadays so I had forgotten that. Works fine. Thanks | 21:23 |
| blueCmd | stekern: it freezes at "Mountpoint-cache hash table entries: 2048 (order: 0, 8192 bytes) | 21:23 |
| blueCmd | stekern: I want to learn OpenRISC, I have error, please help me: http://1deabf8a36fe7cea.paste.se/ | 21:23 |
| stekern | try this first: http://oompa.chokladfabriken.org/openrisc/vmlinux-smp-nosmp | 21:27 |
| stekern | that at least boots in or1ksim from git | 21:27 |
| stekern | oh... wait, I have the atomic insns enabled in that though | 21:28 |
| blueCmd | yes, that works | 21:28 |
| stekern | it does? in what are you running it? | 21:28 |
| blueCmd | wonderful and honorable qemu | 21:29 |
| stekern | ok, so you have the always succeeding atomics enabled? | 21:29 |
| blueCmd | yes! | 21:30 |
| blueCmd | always succeeding atomics is best atomics | 21:30 |
| stekern | that's not going to bite you at some point ;) | 21:30 |
| blueCmd | pfff | 21:30 |
| stekern | does your built kernel work if you enable the atomic insns? | 21:31 |
| blueCmd | stekern: http://openrisc.debian.net/tmp/Linux-config | 21:31 |
| blueCmd | stekern: I think I have enabled atomics | 21:31 |
| stekern | yes you do | 21:31 |
| stekern | so why isn't your kernel working then? | 21:33 |
| blueCmd | stekern: beats me! :) | 21:35 |
| stekern | let me try your config then... | 21:37 |
| dalias | bluecmd, sorry, gentoo is actually pretty cool but that site is still fun :) it was especially fun when i had an office-mate whose computer was _constantly_ busy compiling :) | 21:42 |
| stekern | blueCmd: in or1ksim, your config boots up to this: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) | 21:42 |
| stekern | which is way after where it freezes for you | 21:43 |
| blueCmd | stekern: hmpf | 21:44 |
| stekern | what happens if you try to boot your kernel in or1ksim? | 21:45 |
| blueCmd | stekern: it crashes with a buserror | 21:45 |
| mor1kx | [mor1kx] skristiansson pushed 1 new commit to master: https://github.com/openrisc/mor1kx/commit/bca908d059f99a05cba7815c3772e39b9c79d9ac | 21:46 |
| mor1kx | mor1kx/master bca908d Stefan Kristiansson: propagate OPTION_PIC_NMI_WIDTH all the way up to top level... | 21:46 |
| blueCmd | 0xbc000000 | 21:46 |
| blueCmd | but that's later than qemu | 21:46 |
| stekern | ok, but that's probably because you have some fancy peripherals in your .dts that aren't supported by or1ksim | 21:46 |
| blueCmd | stekern: nope, not as far as I can see | 21:47 |
| stekern | http://oompa.chokladfabriken.org/openrisc/vmlinux-blucmd | 21:49 |
| stekern | try that | 21:49 |
| stekern | it's the kernel I built with your config | 21:50 |
| olofk | God, how I miss visio. Libreoffice draw is not what I'm looking for | 21:50 |
| olofk | And dia has it's own share of problems as well | 21:50 |
| blueCmd | stekern: works | 21:51 |
| blueCmd | hmmm | 21:51 |
| stekern | the only difference is the gcc then I guess... | 21:51 |
| blueCmd | stekern: well, I have mods | 21:52 |
| stekern | blueCmd: right, but that should just make it better, right? =P | 21:52 |
| blueCmd | yes, ofc | 21:53 |
| blueCmd | qemu: fatal: Trying to execute code outside RAM or ROM at 0xffc076dc | 21:56 |
| blueCmd | waaat | 21:56 |
| dalias | stekern, btw does the code in or1k a_store look ok now? | 21:56 |
| dalias | it's a bit heavier than it i'd like but i'd rather just have it be safe/correct/ready-for-use now and worry about improving it later | 21:57 |
| stekern | yeah, that looks ok. and as you say, we can improve it later. | 21:58 |
| stekern | at least our assembler recognizes the l.msync instruction now ;) | 21:59 |
| stekern | and mor1kx will not cause an illegal exception upon them anymore | 22:00 |
| stekern | or1ksim always treated it as a no-op | 22:00 |
| blueCmd | hm, this is weird | 22:05 |
| blueCmd | building the smp version makes it try to read weird addresses | 22:06 |
| stekern | but did you change the two #if 1 to #if 0? | 22:07 |
| blueCmd | I tried both, but that might be why it's crashing weirdly now | 22:07 |
| blueCmd | (oh, there are two!?) | 22:08 |
| blueCmd | stekern: works! :P | 22:09 |
| blueCmd | stekern: also, this kernel fixes my ping | 22:11 |
| stekern | sorry, I should have said that there are two from the beginning... | 22:12 |
| stekern | maybe the busybox in the master branch is borken | 22:13 |
| blueCmd | latest kernel + recompile works, downgrading the kernel makes weird stuff happen | 22:19 |
| blueCmd | stekern: did you change the ABI in any way? | 22:19 |
| blueCmd | FUTEX maybe? | 22:20 |
| stekern | 'downgrading' to what? | 22:20 |
| blueCmd | to non-SMP | 22:20 |
| stekern | which non-SMP? | 22:21 |
| blueCmd | my non-SMP which is 3 patches or so on your master | 22:21 |
| stekern | hmm, odd | 22:22 |
| stekern | everything ontop master should basically just be SMP related stuff | 22:23 |
| blueCmd | you didn't change any futex stuff? | 22:23 |
| blueCmd | because now I get segfault in the testsuite for pthreads, last syscall is "futex" | 22:24 |
| stekern | aha.. is that the "weird" stuff? | 22:24 |
| blueCmd | git diff mexiko stefan/smp shows futex stuff, but I'm not sure if that's exposed | 22:24 |
| blueCmd | stekern: no, the weird stuff was lockups | 22:24 |
| blueCmd | stekern: now I straced an app and it segfaults when doing futex | 22:24 |
| stekern | the futex changes are necessary for robust_list to work | 22:25 |
| blueCmd | i'm sure they are, would the be exposed to userspace or is it only internal? | 22:25 |
| blueCmd | trying with CONFIG_OPENRISC_HAVE_INST_LWA_SWA=n to see if that brings forth cthulhu | 22:27 |
| stekern | they=? | 22:27 |
| stekern | the operations are used internally by the kernel | 22:28 |
| stekern | but the futex stuff that uses them are of course initiated from userspace | 22:28 |
| blueCmd | hm, with CONFIG_OPENRISC_HAVE_INST_LWA_SWA=n it still crashes, but not on futex | 22:29 |
| blueCmd | stekern: they = futex changes | 22:30 |
| stekern | hmm, I should get up in 1.5h and drive people to the airport... maybe I should at least try to sleep some before that... | 22:32 |
| blueCmd | stekern: :) sounds like a not-too-bad idea | 22:33 |
| stekern | but the futex_atomic_* operations was necessary for the pthread_robust test. | 22:33 |
| stekern | blueCmd: if you want to have a reference setup: http://www.openwall.com/lists/musl/2014/07/19/5 | 22:36 |
| blueCmd | stekern: ok, thanks | 22:40 |
| blueCmd | jeremy_bennett: I'm trying to hunt down what specific changes Jungsook did for floating point support | 23:57 |
| blueCmd | you applied her patch in http://opencores.org/websvn,revision?repname=openrisc&path=%2Fopenrisc%2Ftrunk%2Fgnu-old%2Fgcc-4.2.2%2Fgcc%2Fconfig%2For32%2F&rev=133 but opencores's SVN doesn't like to play ball, so I cannot get any diffs or anything | 23:57 |
| blueCmd | do you happen to have some mail or something left that might contain the changes? | 23:58 |
| blueCmd | i'm trying to do some SVN trickery to find out what was changed, but failing that it would helpful | 23:58 |
| --- Log closed Mon Jul 21 00:00:28 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!
