Back to Home / #uml / 2007 / 12 / Prev Day | Next Day
#uml IRC Logs for 2007-12-17

---Logopened Mon Dec 17 00:00:59 2007
03:09|-|silug [~steve@ppp-70-225-81-132.dsl.covlil.ameritech.net] has quit [Ping timeout: 480 seconds]
04:08|-|balbir [~balbir@122.167.178.67] has quit [Ping timeout: 480 seconds]
04:24|-|balbir [~balbir@122.167.178.67] has joined #uml
04:29|-|ftumch [~James@james.1ec.aaisp.net.uk] has quit [Remote host closed the connection]
04:47|-|monsti [~i@m11s12.vlinux.de] has joined #uml
04:47<monsti-#uml->>hi
04:48<monsti-#uml->>somebody at home?
04:49|-|ftumch [~James@james.1ec.aaisp.net.uk] has joined #uml
04:53<monsti-#uml->>are there recent skas patches for 22+ kernels?
05:32|-|nami1 [~test_acco@83-70-39-95.b-ras1.prp.dublin.eircom.net] has quit [Ping timeout: 480 seconds]
06:25|-|krau [~cktakahas@200.184.118.132] has joined #uml
06:28|-|Infinito [argos@201-3-114-47.gnace701.dsl.brasiltelecom.net.br] has joined #uml
06:37|-|balbir [~balbir@122.167.178.67] has quit [Read error: Connection reset by peer]
06:45|-|krau [~cktakahas@200.184.118.132] has quit [Ping timeout: 480 seconds]
06:54|-|flips [~phillips@phunq.net] has left #uml [Leaving]
07:15|-|krau [~cktakahas@200.184.118.132] has joined #uml
07:37|-|balbir [~balbir@122.167.206.219] has joined #uml
08:11|-|Ancalagon [~PtitKosmi@215.208-78-194.adsl-fix.skynet.be] has joined #uml
08:32|-|dang [~dang@nemesis.fprintf.net] has quit [Quit: Leaving.]
08:33|-|dgraves [~agraves@inet-bc01-o.oracle.com] has joined #uml
08:59|-|dang [~dang@aa-redwall.nexthop.com] has joined #uml
09:04<caker-#uml->>monsti: yes, check the uml-devel archives
09:11|-|Ancalagon [~PtitKosmi@215.208-78-194.adsl-fix.skynet.be] has quit [Quit: ChatZilla 0.9.79 [Firefox 2.0.0.8/2007100400]]
09:15|-|krau [~cktakahas@200.184.118.132] has quit [Ping timeout: 480 seconds]
09:27|-|krau [~cktakahas@200.184.118.132] has joined #uml
09:27|-|krau [~cktakahas@200.184.118.132] has quit []
09:27|-|krau [~cktakahas@200.184.118.132] has joined #uml
10:04|-|dang [~dang@aa-redwall.nexthop.com] has quit [Ping timeout: 480 seconds]
10:12|-|dang [~dang@aa-redwall.nexthop.com] has joined #uml
11:25<monsti-#uml->>caker: any url for the development stuff?
11:27<caker-#uml->>http://marc.info/?l=user-mode-linux-devel&m=119712349923229&w=2
11:27<monsti-#uml->>thx!
11:30<monsti-#uml->>i consider using uml for a production mailserver - is there any reason against this?
11:31<caker-#uml->>nope. I run thousands of UMLs :)
11:31<monsti-#uml->>ok cool :)
11:31|-|hfb [~hfb@pool-71-106-219-180.lsanca.dsl-w.verizon.net] has joined #uml
11:31<monsti-#uml->>any idea i get a error: asm/user.h: No such file or directory when compiling uml
11:32<monsti-#uml->>i use ARCH=um make
11:32<caker-#uml->>have you ever ran a make command in that tree without ARCH=um?
11:32<caker-#uml->>if so, it screws up the uml build, and you'll need to make mrproper to restore the tree (save your .config first)
11:34<monsti-#uml->>no
11:34<monsti-#uml->>i use gentoo and a gentoo kernel
11:34<monsti-#uml->>maybe the "overloaded" gentoo patches killed some files
11:34<caker-#uml->>use kernel.org kernels to build UML
11:35<monsti-#uml->>ok i try
11:35<monsti-#uml->>2.6.23 works?
11:36|-|dgraves_ [~agraves@inet-netcache2-o.oracle.com] has joined #uml
11:37<caker-#uml->>they all work -- grab the latest stable
11:38<monsti-#uml->>nop still some errors
11:38<monsti-#uml->>where do you have your /usr/include/linux ?
11:39<monsti-#uml->>is it a link to the kernel?
11:39<caker-#uml->>I build in my home dir
11:39|-|jdike [~jdike@pool-72-93-105-51.bstnma.fios.verizon.net] has joined #uml
11:39<jdike-#uml->>Hi guys
11:39[~]dgraves_ #uml knew caker was going to have issues. :)#uml-> knew caker was going to have issues. :)
11:39<dgraves_-#uml->>morning jdike.
11:39<dgraves_-#uml->>i shipped your cookies sat.
11:39<jdike-#uml->>dgraves!
11:40<jdike-#uml->>payback time
11:40<dgraves_-#uml->>i hope you enjoy them. :)
11:40<jdike-#uml->>hehe
11:40<dgraves_-#uml->>Thanks for the help!
11:40<dgraves_-#uml->>what's up?
11:40<monsti-#uml->>caker: yes but where does /usr/include/linux points to?
11:40<jdike-#uml->>I need to bisect a Fedora kernel
11:40<jdike-#uml->>it turns out that UML doesn't run on any recent stock kernel
11:40<caker-#uml->>monsti: what does that have to do with anything? .. download a kernel tarball, untar it, cd into the directory, make defconfig ARCH=um; make ARCH=um <-- done
11:41<jdike-#uml->>but it does run on FC6 kernels
11:41<dgraves_-#uml->>jdike, huh. nice.
11:41<monsti-#uml->>caker: sorry i did - can you please answert my question? its gentoo related :)
11:41<dgraves_-#uml->>what would be most useful to you? the quilt series i went through?
11:41<monsti-#uml->>-t
11:42|-|dgraves [~agraves@inet-bc01-o.oracle.com] has quit [Ping timeout: 480 seconds]
11:42<jdike-#uml->>no, just clues as to how best turn their patches into a quilt patchset
11:43<dgraves_-#uml->>ah.
11:43[~]dgraves_ #uml wonders if he still has his script.#uml-> wonders if he still has his script.
11:44<monsti-#uml->>the highmem option works fine with uml?
11:45<dgraves_-#uml->>jdike, I don't have the script, it got lost in the reimage, i think.
11:45<dgraves_-#uml->>However, this is what I did:
11:45<jdike-#uml->>monsti, I wouldn't count on it
11:45<dgraves_-#uml->>1) turned the source kernel into a kernel tree using rpmbuild.
11:45<jdike-#uml->>right
11:45<dgraves_-#uml->>2) Wrote a script that did:
11:46<dgraves_-#uml->>a) looked through /usr/src/redhat/SPECS/redhat-2.6.spec for %patch503 -p
11:46<dgraves_-#uml->>lines.
11:46<dgraves_-#uml->>stripped %patch out, and translated it to: Patch503: linux-2.6-s390-net-ctcmpc-driver.patch
11:47<dgraves_-#uml->>I then called quilt to add that the quilt series in reverse order.
11:47<dgraves_-#uml->>then i used push and pop to apply patches one by one.
11:47<dgraves_-#uml->>or in some cases, 50 -200.
11:47<dgraves_-#uml->>depending on where i was in the bisect.
11:47<jdike-#uml->>OK, seems easy enough
11:47<monsti-#uml->>ok a gentoo related issue :(
11:48<jdike-#uml->>what about the reverted patches you found?
11:48<monsti-#uml->>/usr/include/asm and /usr/inlude/linux is bad
11:48<dgraves_-#uml->>well, i applied the first few patches singly (quilt push 1), cause they were big.
11:48<dgraves_-#uml->>there was one revert.
11:48<dgraves_-#uml->># we really want the backported patch and not the stable one
11:48<dgraves_-#uml->>%patch9 -p1 -R
11:48<dgraves_-#uml->>you can see the line there.
11:48<jdike-#uml->>OK
11:49<dgraves_-#uml->>the arguements to %patchX are the args to patch.
11:49<jdike-#uml->>and the order in the spec file is the order to apply them?
11:49<dgraves_-#uml->>so for that one, i had to do the new patch, add files, manually -R patch.
11:49<dgraves_-#uml->>jdike, yes.
11:49<jdike-#uml->>OK, sounds straightforwar
11:49<jdike-#uml->>d
11:49<dgraves_-#uml->>i also skipped some of the Xen patches. b\c i wasn't building a xen kernel.
11:50<dgraves_-#uml->>you'll see some things like this in the spec file:
11:50<dgraves_-#uml->>#
11:50<dgraves_-#uml->># Xen
11:50<dgraves_-#uml->>#
11:50<dgraves_-#uml->>%if %{includexen}
11:50<dgraves_-#uml->>#
11:50<dgraves_-#uml->># Apply the main xen patch...
11:50<dgraves_-#uml->>#%patch951 -p1
11:50<dgraves_-#uml->>%patch950 -p1 -b .p.xen
11:50<dgraves_-#uml->>for me, those weren't important, cause we aren't building xen kernels for xen hosts.
11:50<dgraves_-#uml->>jdike, most of the work was the bisect, not the setup, except for installing quilt, cause quilt wants to be installed to a dir that IT controls.
11:51<dgraves_-#uml->>but i doubt you'll have that issue. :)
11:51<jdike-#uml->>hehe
11:52<dgraves_-#uml->>jdike, for the script, i wrote a recursive perl script, to parse for %patchXXX, and then call itself again with XXX, and output the actual patch name.
11:52<dgraves_-#uml->>i wrote it to a file, and then handed that to a for i in $(cat file) do quilt push -R done
11:52<dgraves_-#uml->>or something similar.
11:52[~]dgraves_ #uml doesn't have the quilt man page in front of him.#uml-> doesn't have the quilt man page in front of him.
11:52<dgraves_-#uml->>that puts them in the right order to have a huge patches list in quilt.
11:53<dgraves_-#uml->>i think you could also do add, push.
11:53<dgraves_-#uml->>(sorry, i didn't mean push earlier. i meant add to the series, not apply).
11:53<dgraves_-#uml->>but i wanted them all available and not applied, b\c i didn't think they'd apply.
11:55[~]jdike #uml was getting UML to run using new_mm and switch_mm#uml-> was getting UML to run using new_mm and switch_mm
11:56<jdike-#uml->>and it started crashing and dying in a strange way
11:56<dgraves_-#uml->>yummy.
11:56<dgraves_-#uml->>this is the right version, not the reversed one you had, right? :)
11:56<jdike-#uml->>spent time debugging it before I found that a stock UML which has run forever also did the same thing
11:57<dgraves_-#uml->>yuck!
11:57<dgraves_-#uml->>that's no good!
11:57<dgraves_-#uml->>are these new test?
11:57<jdike-#uml->>started bisecting the host kernel between 2.6.23 (on the theory that my 2.6.23-skas3 kernel was good) and rc5
11:57<jdike-#uml->>then checked out skas0 on 2.6.23-skas3
11:57<jdike-#uml->>and it dies in the same way
11:57<jdike-#uml->>so the one good host kernel I have is the one Fedora gave me
11:58<dgraves_-#uml->>so its a host thing then, where you get wierd memory back?
11:58<jdike-#uml->>so I need to figure out what goodness they added in order to make this work
11:58<jdike-#uml->>the funny thing is, google says it's a toolchain bug
11:59<jdike-#uml->>so I have no idea how the kernel can be affecting it
11:59<monsti-#uml->>http://groups.google.com.pe/group/comp.os.linux.setup/msg/5b6e4c4b7339f6e3 <- any idea i have this problem using a vanilla 2.6.23
11:59<dgraves_-#uml->>you kept the toolchain the same throughout i suppose, just changing the kernel?
11:59<jdike-#uml->>yup, of course
12:00<jdike-#uml->>just booting different kernels
12:00<dgraves_-#uml->>maybe its like where the toolchain moved something to a different place and it only affects kernels past a certain point?
12:00<jdike-#uml->>dunno
12:00<jdike-#uml->>monsti, 2.6.23 is the UML?
12:00<jdike-#uml->>or the host?
12:02<monsti-#uml->>ok this patch works
12:05<monsti-#uml->>http://www.mail-archive.com/user-mode-linux-devel@lists.sourceforge.net/msg05237.html
12:05<monsti-#uml->>well - sort of :(
12:07<anderiv-#uml->>so - I see that the user-offsets patches made it into the latest stable. It looks like ptrace_user.c is still referencing asm/user.h though.
12:12<jdike-#uml->>not that many patches
12:12<jdike-#uml->>tens, not hundreds
12:15<jdike-#uml->>the first one is bzipped though
12:27<jdike-#uml->>dgraves_, did the RHEL patches go in cleanly?
12:27<jdike-#uml->>no offsets or fuzz?
12:28<jdike-#uml->>then there are things like Patch00: patch-2.6.%{base_sublevel}.%{stable_update}.bz2
12:31|-|namit [~test_acco@83-70-39-95.b-ras1.prp.dublin.eircom.net] has joined #uml
12:33|-|tyler29 [~tyler@ARennes-257-1-147-52.w86-210.abo.wanadoo.fr] has joined #uml
12:36<monsti-#uml->>ok - i fixed that missing user.h and page.h with a hack from the mailinglist
12:36<monsti-#uml->>cp /usr/src/linux/include/asm/user.h /usr/include/asm/user.h
12:36<monsti-#uml->>cp /usr/src/linux/include/asm/page.h /usr/include/asm/page.h
12:37<jdike-#uml->>there are real patches to UML to fix those
12:37<monsti-#uml->>yes but the hack is ok
12:39<monsti-#uml->>Checking PROT_EXEC mmap in /dev/shm/...failed: Operation not permitted
12:39<monsti-#uml->>/dev/shm/ must be not mounted noexec
12:39<monsti-#uml->>ok that's interessting
12:40<monsti-#uml->>UML running in SKAS0 mode
12:40<monsti-#uml->>i will need the scas patch?
12:40<monsti-#uml->>-c+k
12:43<jdike-#uml->>no
12:43<jdike-#uml->>you'll need a tmpfs mount for it somewhere for speed, though
12:44<monsti-#uml->>yes that's fixed
12:45<monsti-#uml->>but the skas0 mode assumes there is no hos skas patch?
12:45<monsti-#uml->>so i still need this if i don't want the uml's process pollute the hosts ps/top?
12:45<jdike-#uml->>for that, you'll need the skas patch
12:50<monsti-#uml->>http://uml.nagafix.co.uk/skas-2.6.23.patch.bz2 thats the patch?
12:51<caker-#uml->>monsti: the one I linked to earlier -- the nagafix one may be an earlier attempt
12:53<dgraves_-#uml->>jdike, i don't recall fuzz, but there were some offsets.
12:53<dgraves_-#uml->>for the most part, it was harmless.
12:55<monsti-#uml->>caker: the nagafix works
12:55<caker-#uml->>it may apply, but it has bugs. Make sure it's the same as the one I linked to
13:00|-|tyler29 [~tyler@ARennes-257-1-147-52.w86-210.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
13:02<monsti-#uml->>caker: how many umls acan you run one one core2duo host? i assume a 8gb motherboard
13:03<caker-#uml->>monsti: a good rule is as many as you can fit into free RAM on the host. that way, you avoid the UMLs swapping out
13:04<dgraves_-#uml->>caker, just add a ram disk! that'll give you something to swap too that's fast.
13:04<dgraves_-#uml->>oh wait... :-{
13:05<monsti-#uml->>so (8000-512) / 128 ?
13:05<dang-#uml->>jdike: panic: /proc/mm map for code failed
13:05<dang-#uml->>Do I need to chrown /proc/mm?
13:06<dang-#uml->>No, it's a+2
13:06<dang-#uml->>er a+w
13:09|-|tyler29 [~tyler@ARennes-257-1-145-58.w86-210.abo.wanadoo.fr] has joined #uml
13:17<monsti-#uml->>caker: can you please paste the link with the skas patch again? i just copied the content on windows and the patch file is now dead :)
13:18|-|krau [~cktakahas@200.184.118.132] has quit [Quit: Varei!!!]
13:18<caker-#uml->>11:27 < caker> http://marc.info/?l=user-mode-linux-devel&m=119712349923229&w=2
13:18<monsti-#uml->>thx a lot
13:20<monsti-#uml->>patch: **** malformed patch at line 131: bytecount) return err;
13:20<monsti-#uml->>any idea?
13:21<caker-#uml->>it wordwrapped and didn't pay attention to the \ on the end of the previous line
13:22<monsti-#uml->>ok i wget the article and then fix it with vim
13:22<monsti-#uml->>copy & paste isn't that good in this case ;:)
13:22<caker-#uml->>http://p.linode.com/98 <-- may be better
13:25<monsti-#uml->>find . -name "*.rej" | wc -l
13:25<monsti-#uml->>29
13:25<monsti-#uml->>:(
13:27|-|krau [~cktakahas@200.184.118.132] has joined #uml
13:34|-|tyler29 [~tyler@ARennes-257-1-145-58.w86-210.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
13:34<monsti-#uml->>caker: ok works :) the nopaste file hat some dos EOLs :(
13:35<jdike-#uml->>there should be a download as raw file option
13:35<jdike-#uml->>rafb has it
13:35[~]caker #uml shakes his fist at whitespace#uml-> shakes his fist at whitespace
13:36<caker-#uml->>ya .. http://p.linode.com/?dl=98
13:36<monsti-#uml->>yes that includes newlines :(
13:36<monsti-#uml->>in M$ dos format
13:37[~]caker #uml tries#uml-> tries
13:37[~]jdike #uml shakes his fists at FC7 kernel patches#uml-> shakes his fists at FC7 kernel patches
13:37<monsti-#uml->>`index.html?dl=98' saved [54995]
13:38<monsti-#uml->>after a dos2unix i have 53059
13:39<caker-#uml->>weird
13:42<monsti-#uml->>caker: thx a lot - skas is working now
13:43<caker-#uml->>word
13:45|-|tyler29 [~tyler@ARennes-257-1-85-129.w86-199.abo.wanadoo.fr] has joined #uml
13:51<jdike-#uml->>dgraves_ lied to me
13:51<dgraves_-#uml->>jdike, how's that?
13:52<jdike-#uml->>there's a set of ApplyPatch directives which seems to indicate the patch order
13:52<dgraves_-#uml->>jdike, i don't have any of them in my spec file...
13:52<dgraves_-#uml->>it was in sequential order.
13:52<jdike-#uml->>hmm
13:53<dgraves_-#uml->>Mine was an EL5\RHEL5 spec file.
13:53<dgraves_-#uml->>maybe that's a newer operative?
13:54|-|remus [~remus@76.231.178.131] has joined #uml
13:55<jdike-#uml->>what a FPOS
13:57<jdike-#uml->>anyway, I have linux-2.6.23.i686/ and vanilla/ and no patch sequence implied by the spec file goes into either
14:06<dgraves_-#uml->>huh.
14:06<dgraves_-#uml->>after my rpmbuild command, i had a linux-2.6.18... and it had the patch sequence.
14:06<dgraves_-#uml->>what was your rpmbuild command?
14:11<jdike-#uml->>I didn't try
14:11<jdike-#uml->>I'm trying to start with a bare kernel tree and build up a quilt sequence on top of it
14:12<jdike-#uml->>if I do rpmbuild, I'll have a fully patched tree and no idea how to back patches out
14:13<dgraves_-#uml->>you should end up with a vanilla and a patched one.
14:13<dgraves_-#uml->>you can take the vanilla one and then apply their patches.
14:14<dgraves_-#uml->>the stuff should apply cleanly (or fairly so) to the vanilla tree.
14:15<jdike-#uml->>they don't, as far as I can tell
14:15<jdike-#uml->>wait
14:16<jdike-#uml->>rpmbuild changes the vanilla tree?
14:16<dgraves_-#uml->>no, it creates a vanilla tree in the /usr/src/redhat/BUILD/XXX/vanilla dir
14:16<dgraves_-#uml->>that they deem "good" to apply their patches too.
14:16<dgraves_-#uml->>to.
14:17<jdike-#uml->>I got a vanilla tree after installing the srpm, but without running rpmbuild
14:19<dgraves_-#uml->>hmmm...
14:19<dgraves_-#uml->>that should make the patches apply cleanly.
14:20<dgraves_-#uml->>do they do any manual massaging to the tree in the spec file?
14:20<dgraves_-#uml->>sometimes they'll delete stuff, but all the patching should be obvious.
14:20<jdike-#uml->>I'll try rpmbuild and see if the vanilla tree is any more patchable
14:21<dgraves_-#uml->>isn't it a bunch of crock?
14:23<jdike-#uml->>this is convenient
14:23<jdike-#uml->>the rpmbuild output is showing the patch order
14:26<jdike-#uml->>although it shows an order I tried, and which failed
14:32<dgraves_-#uml->>jdike, yeah, it does put it out.
14:32<dgraves_-#uml->>but how did it fail?
14:32<fo0bar-#uml->>jdike: fyi, your skas3 patch works well against debian's 2.6.23. I probably won't be using it in production, but it's worth mentioning
14:41|-|krau [~cktakahas@200.184.118.132] has quit [Quit: Varei!!!]
15:01<monsti-#uml->>can i use a directory as root= in recent umls?
15:08|-|krau [~cktakahas@200.184.118.132] has joined #uml
15:29<jdike-#uml->>hostfs root doesn't really work well
15:30<monsti-#uml->>(none) / # /bin/mount
15:30<monsti-#uml->>bash: /bin/mount: Permission denied
15:30<monsti-#uml->>yes :)
15:30<jdike-#uml->>you basically have to run the UML as root, which is very much not recommended
15:31<monsti-#uml->>so there is no way to shift the root uid when the uml is running?
15:31<monsti-#uml->>e.g. "let uid23423 be the 0 i uml"?
15:32<jdike-#uml->>there was, sort of
15:33<jdike-#uml->>but it was a nasty kludge
15:33<jdike-#uml->>and there are still lots of permission problems which can't be fixed
15:34<monsti-#uml->>yes no mknode, e.g.
15:34<jdike-#uml->>I still can't reproduce what rpmbuild did
15:34<monsti-#uml->>ok no problem - i will deal with that
15:34<jdike-#uml->>yeah
15:35<monsti-#uml->>is there a way to save the state of an uml?
15:35<jdike-#uml->>suspend?
15:35<jdike-#uml->>no
15:39|-|tyler29 [~tyler@ARennes-257-1-85-129.w86-199.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
15:51|-|tyler29 [~tyler@ARennes-257-1-39-190.w81-53.abo.wanadoo.fr] has joined #uml
15:57|-|krau [~cktakahas@200.184.118.132] has quit [Ping timeout: 480 seconds]
16:02[~]jdike #uml having some success building the quilt tree backwards#uml-> having some success building the quilt tree backwards
16:04|-|kos_tom [~thomas@humanoidz.org] has quit [Quit: I like core dumps]
16:07|-|kos_tom [~thomas@humanoidz.org] has joined #uml
16:13|-|krau [~cktakahas@200.184.118.132] has joined #uml
16:14|-|tyler29 [~tyler@ARennes-257-1-39-190.w81-53.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
16:23|-|IntuitiveNipple [~TJ@alexandros.tjworld.net] has joined #uml
16:26|-|mgross [~mgross@207.173.77.239] has joined #uml
16:27|-|mgross [~mgross@207.173.77.239] has quit []
16:30|-|tyler29 [~tyler@ARennes-257-1-160-198.w86-214.abo.wanadoo.fr] has joined #uml
16:39<jdike-#uml->>finally
16:39<jdike-#uml->>by sticking quilt stuff into the spec file, I get a patch series
17:05|-|Urg[workz] [~plamen@83.228.65.158] has joined #uml
17:08|-|Urgleflogue [~plamen@83.228.65.158] has quit [Ping timeout: 480 seconds]
17:18|-|dang [~dang@aa-redwall.nexthop.com] has quit [Quit: Leaving.]
17:28|-|tyler29 [~tyler@ARennes-257-1-160-198.w86-214.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
17:43|-|kos_tom [~thomas@humanoidz.org] has quit [Quit: I like core dumps]
17:46<Magotari-#uml->>One more useless to everyone training project about half done.
17:46<Magotari-#uml->>Maybe I will try again with a more serious one after this.
17:48[~]jdike #uml begins bisecting the FC7 kernel#uml-> begins bisecting the FC7 kernel
18:26|-|hfb [~hfb@pool-71-106-219-180.lsanca.dsl-w.verizon.net] has quit [Quit: Leaving]
18:36<Magotari-#uml->>Yup. My training project compiled. Pretty nice so far.
18:43<Magotari-#uml->>Something is royally wrong. No skas0 or skas3 kernel, new or old will run.
18:44<jdike-#uml->>what are they doing?
18:44<Magotari-#uml->>Trying to run a single uml on a normal skas3 kernel. No uml or host modifications. Just a new host kernel, identical to the old one. Except core dumps. Hmm... I'm off to take a look at that.
18:50<jdike-#uml->>how are they dying?
19:06<fo0bar-#uml->>jdike: is nptl on a 32-bit guest (kernel and userland) with 64-bit host supported?
19:06<jdike-#uml->>yup
19:07<fo0bar-#uml->>hmm
19:07|-|IntuitiveNipple [~TJ@alexandros.tjworld.net] has quit [Quit: The only intuitive interface is the nipple; everything else is learned]
19:07[~]fo0bar #uml is getting signal 7 with /lib/tls in place#uml-> is getting signal 7 with /lib/tls in place
19:07<fo0bar-#uml->>but seems to work without it
19:08<jdike-#uml->>TLS doesn't cause SIGBUS
19:08<jdike-#uml->>you sure you don't have a full tmpfs?
19:09<fo0bar-#uml->>pretty sure
19:09[~]fo0bar #uml checks#uml-> checks
19:10<fo0bar-#uml->>yeah, 384MB guest, only one running, 1GB tmpfs
19:10[~]fo0bar #uml resets the userland#uml-> resets the userland
19:11<fo0bar-#uml->>(in retrospect I shouldn't have completely removed /lib/tls to test :)
19:11<jdike-#uml->>hehe
19:11<jdike-#uml->>moving it is more recommended
19:11<fo0bar-#uml->>yeah
19:12<fo0bar-#uml->>I do keep the skel image around as a sparse file, so it doesn't take long to re-create
19:25<fo0bar-#uml->>jdike: here's strace /usr/bin/file with nptl: http://www.pastebin.ca/821248
19:26<fo0bar-#uml->>hmm, actually it looks like /bin/ls will work fine by itself, but "/bin/ls -l" is signal 7
19:34<jdike-#uml->>fo0bar, what's the host?
19:35<fo0bar-#uml->>jdike: 2.6.23 amd64, skas3 patch applied on a c2q q6600, 4GB ram
19:35<jdike-#uml->>2.6.23 should be OK
19:36<jdike-#uml->>there were a couple of host bugs but they should be fixed in 2.6.23
19:38<jdike-#uml->>ooh
19:38<jdike-#uml->>one isn't
19:38<jdike-#uml->>grab ecd744eec3aa8bbc949ec04ed3fbf7ecb2958a0e from mainline
19:38<jdike-#uml->>that bug will cause random bus errors
19:40<fo0bar-#uml->>arch/x86... I'm guessing that won't apply cleanly against 2.6.23 :)
19:41<jdike-#uml->>be creative with -p and cd
19:41<fo0bar-#uml->>gotcha
19:45[~]jdike #uml sends that patch to -stable#uml-> sends that patch to -stable
19:46<jdike-#uml->>hmm
19:46<jdike-#uml->>I need to drop it into a 2.6.23 tree and rediff first
19:47<fo0bar-#uml->>gar... gitweb on git.kernel.org is throwing 500 when trying to grab the raw diff
19:48<fo0bar-#uml->>rrr
19:48<jdike-#uml->>whoops
19:48<fo0bar-#uml->>oh hey, the raw commitdiff works
19:48<fo0bar-#uml->>ok, it applies cleanly
19:49|-|real0ne [~test@41.251.5.131] has joined #uml
19:53|-|jdike [~jdike@pool-72-93-105-51.bstnma.fios.verizon.net] has quit [Quit: Leaving]
20:27|-|dang [~dang@nemesis.fprintf.net] has joined #uml
23:23|-|Infinito [argos@201-3-114-47.gnace701.dsl.brasiltelecom.net.br] has quit [Quit: Quitte]
23:58|-|balbir [~balbir@122.167.206.219] has quit [Read error: Operation timed out]
23:59|-|VS_ChanLog [~stats@ns.theshore.net] has left #uml [Rotating Logs]
23:59|-|VS_ChanLog [~stats@ns.theshore.net] has joined #uml
---Logclosed Tue Dec 18 00:00:07 2007