| --- | Log | opened Fri Apr 11 00:00:46 2008 |
| 00:27 | -!- | ferret_0567 [~ferret_05@cpe-70-120-93-94.satx.res.rr.com] has quit [Ping timeout: 480 seconds] |
| 00:36 | -!- | ram [~ram@63.97.245.98] has joined #uml |
| 00:36 | -!- | ferret_0567 [~ferret_05@cpe-70-120-93-94.satx.res.rr.com] has joined #uml |
| 00:59 | -!- | ferret_0567 [~ferret_05@cpe-70-120-93-94.satx.res.rr.com] has quit [Remote host closed the connection] |
| 01:11 | -!- | ferret_0567 [~ferret_05@cpe-70-120-93-94.satx.res.rr.com] has joined #uml |
| 01:25 | -!- | balbir [~balbir@122.167.180.194] has joined #uml |
| 01:31 | -!- | ferret_0567 [~ferret_05@cpe-70-120-93-94.satx.res.rr.com] has quit [Quit: leaving] |
| 01:55 | -!- | ram [~ram@63.97.245.98] has quit [Ping timeout: 480 seconds] |
| 02:18 | -!- | ferret_0567 [~ferret_05@cpe-70-120-93-94.satx.res.rr.com] has joined #uml |
| 02:18 | -!- | ferret_0567 [~ferret_05@cpe-70-120-93-94.satx.res.rr.com] has quit [] |
| 02:19 | -!- | ferret_0567 [~ferret_05@cpe-70-120-93-94.satx.res.rr.com] has joined #uml |
| 03:33 | -!- | Urgleflogue [~plamen@83.228.65.158] has quit [Quit: 01001110 01100101 01110010 01100100 00100001] |
| 08:11 | -!- | krau [~cktakahas@189.81.98.80] has quit [Quit: Varei!!!] |
| 08:42 | -!- | krau [~cktakahas@200.184.118.132] has joined #uml |
| 08:43 | -!- | dang [~dang@75.38.192.168] has quit [Quit: Leaving.] |
| 09:02 | -!- | dang [~dang@aa-redwall.ghs.com] has joined #uml |
| 10:01 | -!- | balbir [~balbir@122.167.180.194] has quit [Read error: Operation timed out] |
| 10:03 | -!- | ram [~ram@63.97.245.98] has joined #uml |
| 10:34 | -!- | jdike [~jdike@pool-72-93-105-206.bstnma.fios.verizon.net] has joined #uml |
| 10:34 | <jdike:#uml> | Hi guys |
| 11:05 | -!- | ram [~ram@63.97.245.98] has quit [Ping timeout: 480 seconds] |
| 11:56 | -!- | hfb [~hfb@pool-71-118-254-245.lsanca.dsl-w.verizon.net] has joined #uml |
| 12:10 | -!- | ram [~ram@63.127.234.137] has joined #uml |
| 12:28 | -!- | linux__alien [~linux__al@59.92.66.62] has joined #uml |
| 12:28 | <linux__alien:#uml> | when i start UML i get the Log messages automatically . Is this expected coz i ve not given loglevel=7 in the cmd line |
| 12:29 | <linux__alien:#uml> | even if i dont give loglevel=7 i get the log messages. any idea on why i am getting it ? |
| 12:35 | <linux__alien:#uml> | anyone here? |
| 12:36 | <jdike:#uml> | have you tried reading the relevant documentation? |
| 12:37 | <linux__alien:#uml> | yes |
| 12:37 | <linux__alien:#uml> | to an extent atleast |
| 12:37 | <linux__alien:#uml> | if not the whole |
| 12:40 | <jdike:#uml> | what documentation is contradicted by the behavior you see? |
| 12:40 | <linux__alien:#uml> | All Kernel Messages with a loglevel smaller than the |
| 12:40 | <linux__alien:#uml> | console loglevel will be printed to the console |
| 12:40 | <linux__alien:#uml> | this is what the doc says |
| 12:40 | <linux__alien:#uml> | i am not sure about the console loglevel |
| 12:40 | <jdike:#uml> | which doc? |
| 12:40 | <linux__alien:#uml> | http://www.cyberciti.biz/howto/question/static/linux-kernel-parameters.php |
| 12:43 | <jdike:#uml> | how does this contradict what you're seeing? |
| 12:43 | <linux__alien:#uml> | this line |
| 12:43 | <linux__alien:#uml> | TCP: Hash tables configured (established 4096 bind 4096) |
| 12:43 | <linux__alien:#uml> | in the code is in tcp_init and its with KERN_INFO in printk |
| 12:44 | <linux__alien:#uml> | so my doubt is will all KERN_INFO get printed to the console even if loglevel=7 is not given |
| 12:45 | <jdike:#uml> | what's the default loglevel? |
| 12:45 | <linux__alien:#uml> | i am sorry i dont know that |
| 12:47 | <jdike:#uml> | #define DEFAULT_CONSOLE_LOGLEVEL 7 /* anything MORE serious than KERN_DEBUG */ |
| 12:52 | <linux__alien:#uml> | Thanks so which means i would get everything by default :) |
| 12:52 | <linux__alien:#uml> | Thanks for the info |
| 12:52 | <linux__alien:#uml> | that means even loglevel 6 and lesser than that would get printed too ? |
| 12:56 | -!- | linux__alien [~linux__al@59.92.66.62] has quit [Quit: Leaving] |
| 12:56 | <jdike:#uml> | sigh |
| 13:47 | <fo0bar:#uml> | heh |
| 13:47 | <fo0bar:#uml> | jdike: how's it going? do you need anything from me? |
| 13:47 | <jdike:#uml> | BAH HUMBUG |
| 13:47 | <jdike:#uml> | no, I'm fine |
| 13:48 | <fo0bar:#uml> | I probably won't be online much of today. I got t-boned in an intersection yesterday and spent the evening at the hospital |
| 13:48 | <caker:#uml> | fo0bar: ouch! |
| 13:48 | <fo0bar:#uml> | so now I'm dealing with 50 different people who either want to give me money or take it away from me :) |
| 13:48 | <caker:#uml> | are you ok? |
| 13:48 | <fo0bar:#uml> | yeah. I've got whiplash, but not too serious |
| 13:49 | <jdike:#uml> | yow |
| 13:49 | <caker:#uml> | poor, poor prius |
| 13:49 | <caker:#uml> | it's dead, I assume |
| 13:49 | <fo0bar:#uml> | they took me to the hospital and did a bunch of xrays at a precaution because of my neck surgery last year |
| 13:49 | <fo0bar:#uml> | most likely |
| 13:49 | <fo0bar:#uml> | I didn't see the outside of it because they put me directly on a stretcher |
| 13:49 | <fo0bar:#uml> | but they had to pry the driver side door open |
| 13:50 | <fo0bar:#uml> | and I lost a perfectly good pizza in the process :( |
| 13:50 | * | fo0bar:#uml was driving from the pizza place to his old apartment on account of no food left there |
| 13:50 | <caker:#uml> | I belive comprehensive covers lost pizza |
| 13:51 | <fo0bar:#uml> | hehe |
| 13:52 | <jdike:#uml> | if it doesn't, find a new insurance company |
| 13:52 | -!- | ram [~ram@63.127.234.137] has quit [Ping timeout: 480 seconds] |
| 13:52 | <jdike:#uml> | one that understands the important things in life |
| 14:41 | -!- | ferret_0567 [~ferret_05@cpe-70-120-93-94.satx.res.rr.com] has quit [Ping timeout: 480 seconds] |
| 14:41 | -!- | ferret_0567 [~ferret_05@cpe-70-120-93-94.satx.res.rr.com] has joined #uml |
| 14:48 | <jdike:#uml> | looks like the clocksource is getting corrupter |
| 14:48 | <jdike:#uml> | corrupted |
| 15:14 | -!- | ferret_0567 [~ferret_05@cpe-70-120-93-94.satx.res.rr.com] has quit [Remote host closed the connection] |
| 15:36 | <jdike:#uml> | caker, there? |
| 15:36 | <caker:#uml> | yes |
| 15:36 | <jdike:#uml> | I'm trying to get a core dump from fo0bar's UMLs, and failing |
| 15:36 | <jdike:#uml> | no core dump limits, the UML pwd is 777 |
| 15:37 | <jdike:#uml> | what else is there? |
| 15:37 | <caker:#uml> | /proc/sys/kernel/core_pattern ? |
| 15:37 | <caker:#uml> | don't his scripts su ? |
| 15:37 | <jdike:#uml> | not there |
| 15:38 | <jdike:#uml> | but there is a coredump_filter, which is 00000003 |
| 15:38 | <jdike:#uml> | they su to nobody |
| 15:39 | <caker:#uml> | mabye set a fake kernel to dump ulimit to see if yours is getting stompped? |
| 15:39 | <jdike:#uml> | whoops, core_pattern is "core" |
| 15:39 | <jdike:#uml> | the coredump_filter is in /proc/<pid> |
| 15:39 | <caker:#uml> | I've never seen coredump_filter before... |
| 15:39 | <jdike:#uml> | the coredump limits are the first thing UML prints |
| 15:40 | <caker:#uml> | ah :) |
| 15:40 | <jdike:#uml> | for exactly this reason |
| 15:40 | * | caker:#uml tries |
| 15:40 | <jdike:#uml> | I guess I'll just make it spin instead of panic |
| 15:43 | <caker:#uml> | ulimit -c unlimited; ./2.6.24.2-linode40 <-- produced a core |
| 15:43 | <jdike:#uml> | yeah |
| 15:43 | <jdike:#uml> | always works here too |
| 15:44 | <caker:#uml> | maybe his scripts change the working dir? |
| 15:44 | * | caker:#uml shrugs |
| 15:44 | -!- | balbir [~balbir@122.167.206.111] has joined #uml |
| 15:44 | <jdike:#uml> | they do, but the UML pwd is 777 |
| 15:44 | <jdike:#uml> | so that shouldn't be an issue |
| 15:44 | <jdike:#uml> | anyhoo the thing is going to spin instead, which is just as good |
| 15:45 | <caker:#uml> | k |
| 15:45 | * | caker:#uml wanted to be useful |
| 15:45 | <jdike:#uml> | hehe |
| 15:45 | <jdike:#uml> | just annoying that I waiting 30 min for one to crap out and it didn't have the manners to leave a core behind |
| 15:45 | <jdike:#uml> | waited |
| 15:57 | -!- | balbir [~balbir@122.167.206.111] has quit [Ping timeout: 480 seconds] |
| 16:03 | -!- | ram [~ram@63.127.235.177] has joined #uml |
| 16:15 | <jdike:#uml> | I might understand the problem |
| 16:32 | <fo0bar:#uml> | so... did I do something wrong? |
| 16:33 | <jdike:#uml> | you drove through the wrong intersection at the wrong time, with a pizza |
| 16:33 | <fo0bar:#uml> | beside that |
| 16:33 | <jdike:#uml> | oh |
| 16:34 | <jdike:#uml> | you use NTP |
| 16:49 | <jdike:#uml> | looks like it's confirmed |
| 16:56 | <jdike:#uml> | Here's what I think is the problem - we'll see in about an hour |
| 16:57 | <jdike:#uml> | the system clock has to tell the timekeeping system about itself |
| 16:57 | <jdike:#uml> | in particular, how to convert cycles to ns |
| 16:57 | <jdike:#uml> | used here - (ret * cs->mult) >> cs->shift |
| 16:58 | <jdike:#uml> | cycles get multiplied by something, then shifted, and the result is nanoseconds |
| 16:59 | <jdike:#uml> | I pretended I had a nanosecond clock, so mult is 1 and shift is 0 |
| 16:59 | <jdike:#uml> | Enter NTP |
| 16:59 | <jdike:#uml> | it adjusts the time by bumping mult up or down to speed up or slow down the clock |
| 17:00 | <jdike:#uml> | However, the only adjustment down for my clock results in mult == 0 |
| 17:00 | <jdike:#uml> | so the cycles-to-ns calculation now always returns 0 |
| 17:01 | <jdike:#uml> | this makes it look like time has stopped |
| 17:01 | <jdike:#uml> | so jiffies are never updated again and anything that counts on jiffies increasing stops |
| 17:02 | <fo0bar:#uml> | ahh |
| 17:02 | <fo0bar:#uml> | this explains why triggering was so erratic |
| 17:02 | <jdike:#uml> | right |
| 17:02 | <fo0bar:#uml> | because ntpd basically does whatever it feels like |
| 17:03 | <jdike:#uml> | yeah, the clock needs to slow down enough to get NTP interested |
| 17:03 | <jdike:#uml> | err, speed up |
| 17:03 | <fo0bar:#uml> | and it would only happen if time was adjusted forward, yes? |
| 17:04 | <jdike:#uml> | well, it would happen if NTP thought the clock was ahead of reality |
| 17:04 | <jdike:#uml> | so it would slow it down |
| 17:04 | <fo0bar:#uml> | ok |
| 17:04 | <jdike:#uml> | speeding up is now problem |
| 17:05 | <jdike:#uml> | mult == 2 and time is progressing twice as fast, and catches up really quickly |
| 17:05 | <jdike:#uml> | s/now/so |
| 17:05 | <jdike:#uml> | no |
| 17:05 | <jdike:#uml> | what I did was switch UML's clock to usec |
| 17:05 | <jdike:#uml> | so the mult starts at 1000 |
| 17:06 | <jdike:#uml> | and if NTP feels like adjusting it, it goes to either 999 or 1001 |
| 17:10 | <jdike:#uml> | 15 minutes and all's quiet |
| 17:12 | -!- | ram [~ram@63.127.235.177] has quit [Ping timeout: 480 seconds] |
| 17:14 | -!- | dang [~dang@aa-redwall.ghs.com] has quit [Quit: Leaving.] |
| 17:25 | <jdike:#uml> | 30 minutes |
| 17:35 | <fo0bar:#uml> | excellent |
| 17:37 | <jdike:#uml> | 40 |
| 17:39 | -!- | krau [~cktakahas@200.184.118.132] has quit [Quit: Varei!!!] |
| 17:41 | <jdike:#uml> | 45 |
| 17:41 | <jdike:#uml> | I'd say it's looking hopeful at this point |
| 17:42 | <fo0bar:#uml> | great |
| 17:42 | <fo0bar:#uml> | are there any downsides to the way you're doing this that you know of? |
| 17:42 | <jdike:#uml> | nope |
| 17:44 | <jdike:#uml> | http://pastebin.com/m15e76043 |
| 17:44 | <jdike:#uml> | that's the patch |
| 17:44 | <jdike:#uml> | two lines |
| 17:44 | <fo0bar:#uml> | I'm a little surprised this hasn't been reported earlier. do people generally not run ntpd inside UML? |
| 17:45 | <jdike:#uml> | dunno |
| 17:45 | <fo0bar:#uml> | really the only reason I run it is because I use the same deployment system for both physical and UML servers |
| 17:45 | <jdike:#uml> | NTP didn't used to make any sense |
| 17:46 | <jdike:#uml> | all timekeeping was based on the host's gettimeofday, which relied on NTP on the host |
| 17:46 | <jdike:#uml> | the timekeeping rework added some separation, so that UML now keeps its own time, with guidance from the host |
| 17:48 | <fo0bar:#uml> | was that before 2.6.18? because I used to have horrible drifting on 2.6.18 guests before I ended up cobbling together some backported patches |
| 17:48 | <jdike:#uml> | really? |
| 17:48 | <fo0bar:#uml> | but only in some instances for unknown reasons |
| 17:48 | <jdike:#uml> | gettimeofday drifting? |
| 17:49 | <fo0bar:#uml> | yeah |
| 17:49 | * | fo0bar:#uml looks for the patch |
| 17:49 | <fo0bar:#uml> | as I'm sure I don't have any pre-patch kernels around to reproduce |
| 17:49 | <jdike:#uml> | gettimeofday more or less directly called the host's gettimeofday, I think |
| 17:52 | <fo0bar:#uml> | http://pastebin.ca/981567 <-- sorry, it doesn't have functions listed |
| 17:54 | <jdike:#uml> | there are a few changes in there |
| 17:55 | <jdike:#uml> | but moving the timer_irq call looks like it would affect accounting |
| 17:55 | -!- | snipermatze [~matze@pD9E64CD5.dip.t-dialin.net] has joined #uml |
| 17:56 | -!- | snipermatze [~matze@pD9E64CD5.dip.t-dialin.net] has quit [] |
| 17:56 | <jdike:#uml> | 1 hour |
| 17:58 | <jdike:#uml> | gotta go |
| 17:59 | <jdike:#uml> | you can get the patch with git-diff arch/um/kernel/time.c in /root/jdike/linux-2.6 |
| 17:59 | <jdike:#uml> | there's a change in arch/um/kernel/process.c which you're welcome to, but I'm pretty sure it doesn't do anything |
| 18:00 | <fo0bar:#uml> | thanks, I'll test it on other machines |
| 18:00 | <jdike:#uml> | OK |
| 18:00 | -!- | jdike [~jdike@pool-72-93-105-206.bstnma.fios.verizon.net] has quit [Quit: Leaving] |
| 18:01 | -!- | jdike [~jdike@pool-72-93-105-206.bstnma.fios.verizon.net] has joined #uml |
| 18:01 | <jdike:#uml> | one thing I forgot |
| 18:02 | <jdike:#uml> | I changed the permissions of the jail directories to 777 in a futile attempt to get core dumps |
| 18:02 | <jdike:#uml> | so you might want to change them back to 755 |
| 18:02 | -!- | jdike [~jdike@pool-72-93-105-206.bstnma.fios.verizon.net] has quit [] |
| 18:50 | -!- | hfb [~hfb@pool-71-118-254-245.lsanca.dsl-w.verizon.net] has quit [Quit: Leaving] |
| 19:18 | -!- | ferret_0567 [~ferret_05@cpe-70-120-93-94.satx.res.rr.com] has joined #uml |
| 19:22 | -!- | ferret_0567 [~ferret_05@cpe-70-120-93-94.satx.res.rr.com] has quit [Read error: Connection reset by peer] |
| 19:29 | -!- | dang [~dang@75.38.192.168] has joined #uml |
| 19:34 | -!- | ferret_0567 [~ferret_05@cpe-70-120-93-94.satx.res.rr.com] has joined #uml |
| 19:49 | <ferret_0567:#uml> | does the UML host audio relay use OSS on the host? |
| 20:08 | <ferret_0567:#uml> | fs/buffer.c: In function ‘alloc_page_buffers’: |
| 20:08 | <ferret_0567:#uml> | fs/buffer.c:51: sorry, unimplemented: inlining failed in call to ‘init_buffer’: function body not available |
| 20:08 | <ferret_0567:#uml> | WTF? Why won't my UML kernel build? |
| 23:08 | -!- | ferret_0667 [~ferret_05@cpe-70-120-93-94.satx.res.rr.com] has joined #uml |
| 23:08 | -!- | ferret_0567 [~ferret_05@cpe-70-120-93-94.satx.res.rr.com] has quit [Read error: No route to host] |
| 23:08 | -!- | ferret_0667 [~ferret_05@cpe-70-120-93-94.satx.res.rr.com] has quit [] |
| 23:08 | -!- | ferret_0567 [~ferret_05@cpe-70-120-93-94.satx.res.rr.com] has joined #uml |
| 23:51 | -!- | ferret_0567 [~ferret_05@cpe-70-120-93-94.satx.res.rr.com] has quit [Remote host closed the connection] |
| 23:57 | -!- | ferret_0567 [~ferret_05@cpe-70-120-93-94.satx.res.rr.com] has joined #uml |
| 23:57 | -!- | ferret_0567 [~ferret_05@cpe-70-120-93-94.satx.res.rr.com] has quit [] |
| 23:59 | -!- | VS_ChanLog [~stats@ns.theshore.net] has left #uml [Rotating Logs] |
| 23:59 | -!- | VS_ChanLog [~stats@ns.theshore.net] has joined #uml |
| --- | Log | closed Sat Apr 12 00:00:40 2008 |
![[FSF Associate Member]](/assets/fsf.png){kind=small}
