Back to Home / #uml / 2009 / 06 / Prev Day | Next Day
#uml IRC Logs for 2009-06-29

---Logopened Mon Jun 29 00:00:46 2009
01:02-!-balbir_ [~balbir@] has joined #uml
01:10-!-balbir_ [~balbir@] has quit [Read error: Connection reset by peer]
01:26-!-balbir_ [~balbir@] has joined #uml
02:28-!-balbir_ [~balbir@] has quit [Ping timeout: 480 seconds]
03:15-!-balbir_ [~balbir@] has joined #uml
09:54-!-balbir_ [~balbir@] has quit [Ping timeout: 480 seconds]
11:12-!-balbir_ [~balbir@] has joined #uml
11:34-!-balbir_ [~balbir@] has quit [Ping timeout: 480 seconds]
11:54-!-silug [] has joined #uml
12:15-!-balbir_ [~balbir@] has joined #uml
13:32-!-balbir_ [~balbir@] has quit [Ping timeout: 480 seconds]
14:13<rjbell4:#uml>I'm finding some problems when I run with mem=512M, but not mem=256M. I've googled and found this problem reported a couple of times, but I can't see anything resolution.
14:13<rjbell4:#uml>Does anyone know anything about this problem?
14:13<caker:#uml>define problems
14:13<rjbell4:#uml>Loading kernel modules (nfs is most notable) results in unresolved symbol messages
14:14<rjbell4:#uml>One other person reported the problem to the debian bug tracker about NFS. Someone else posted to uml-devel about loop.ko.
14:15<rjbell4:#uml>There's also the message that the module was likely not compiled with "-mcmodel=kernel"
14:15<rjbell4:#uml>Simply reducing the amount of memory works fine.
14:16<rjbell4:#uml>But apparently I'm not the only one...
14:16<caker:#uml>which uml kernel version?
14:16<rjbell4:#uml>Debian bug report:
14:17<rjbell4:#uml>uml-devel report:
14:17<rjbell4:#uml>caker: Right now I'm using 2.6.27
14:18<caker:#uml>lame .. mabye try compiling that stuff in?
14:28<rjbell4:#uml>A little experimentation shows that mem=503M is fine, but mem=504M (or more) is broken
14:28<rjbell4:#uml>Thing is I've got to load some modules later, so having a broken module loading mechanism is a deal-breaker
14:34<rjbell4:#uml>And I/O memory counts as well. Although "mem=496M" is fine, adding a 32 MB iomem file will push it over the edge.
14:34<rjbell4:#uml>So it seems to be total memory footprint...
14:34<caker:#uml>what's your "mount | grep tmp" look like?
14:47<rjbell4:#uml>From a broken UML instance?
14:51<caker:#uml>no, from the host. UML writes its "memory file" to $TMP and then unlinks it
14:52<caker:#uml>it's standard operating procedure to make /tmp a tmpfs mount so UML's memory access is faster
15:07<rjbell4:#uml> /tmp on the host is on the rootfs
15:08<rjbell4:#uml>so I should set $TMP to a tmpfs mount somewhere, I gather, and that will result in better performance?
15:15<rjbell4:#uml>/var/run and /var/lock are both tmpfs on this (host) system. 'df -h' reports that both are 503M.
15:15<rjbell4:#uml>That's a very familiar number... (see my message at 2:28:00 PM ET)
15:16<rjbell4:#uml>I don't know how that relates yet, but it seems likely to be not-just-coincidental
15:20-!-the_hydra [~mulyadi@] has joined #uml
15:20<the_hydra:#uml>hi all
15:40*linbot:#uml attacks
15:44-!-the_hydra [~mulyadi@] has quit [Quit: Leaving]
15:45<rjbell4:#uml>caker: Using a larger tmpfs might be advisable, but it doesn't solve the problem I've been having
16:20-!-fo0bar [] has quit [Remote host closed the connection]
16:28-!-fo0bar [] has joined #uml
17:48-!-da-x [] has joined #uml
17:54-!-karrde_ [] has quit [Ping timeout: 480 seconds]
19:05<rjbell4:#uml>Is there a good way to start uml with the virtual console in screen? I know uml can create a pty that screen can attach to, but I'd like to automate this, and I don't quite see how to do that.
19:05<caker:#uml>./linux con=null con0=fd:0,fd:1 <-- then start a getty inside the UML on tty0
20:29<rjbell4:#uml>caker: Sorry I was so distracted for so long. Thanks for the help.
20:30<rjbell4:#uml>That's working for me. I guess what I didn't consider was giving up on tty1 and simply switching to tty0. That's a lot simpler.
21:55-!-balbir_ [~balbir@] has joined #uml
22:05-!-balbir_ [~balbir@] has quit [Ping timeout: 480 seconds]
22:16-!-balbir_ [~balbir@] has joined #uml
22:40-!-balbir_ [~balbir@] has quit [Read error: Operation timed out]
22:53-!-balbir_ [~balbir@] has joined #uml
23:23-!-balbir_ [~balbir@] has quit [Read error: Operation timed out]
23:33-!-balbir_ [~balbir@] has joined #uml
23:59-!-VS_ChanLog [] has left #uml [Rotating Logs]
23:59-!-VS_ChanLog [] has joined #uml
---Logclosed Tue Jun 30 00:00:06 2009