| --- | Log | opened Fri Feb 15 00:00:35 2008 |
| 00:23 | -!- | kokoko1 [~Slacker@203.148.64.252] has joined #uml |
| 00:47 | -!- | balbir [~balbir@122.167.198.85] has quit [Read error: Operation timed out] |
| 01:43 | -!- | balbir [~balbir@59.145.136.1] has joined #uml |
| 03:10 | -!- | ElectricElf [~dbharris@bas1-toronto48-1279276359.dsl.bell.ca] has quit [Read error: Operation timed out] |
| 03:12 | -!- | ElectricElf [~dbharris@bas1-toronto48-1279276359.dsl.bell.ca] has joined #uml |
| 04:20 | -!- | besonen_mobile__ [~besonen_m@71-220-235-129.eugn.qwest.net] has quit [Read error: Connection reset by peer] |
| 04:20 | -!- | besonen_mobile__ [~besonen_m@71-220-235-129.eugn.qwest.net] has joined #uml |
| 04:54 | -!- | remus [~remus@76.231.178.131] has quit [Read error: Connection reset by peer] |
| 04:55 | -!- | remus [~remus@76.231.178.131] has joined #uml |
| 05:05 | -!- | kos_tom [~thomas@humanoidz.org] has joined #uml |
| 05:43 | -!- | balbir [~balbir@59.145.136.1] has quit [Ping timeout: 480 seconds] |
| 06:01 | -!- | balbir [~balbir@59.145.136.1] has joined #uml |
| 06:52 | -!- | balbir [~balbir@59.145.136.1] has quit [Ping timeout: 480 seconds] |
| 07:08 | -!- | balbir [~balbir@59.145.136.1] has joined #uml |
| 07:32 | -!- | the_hydra [~mulyadi@125.161.247.93] has joined #uml |
| 07:32 | <the_hydra:#uml> | hi all |
| 07:43 | -!- | balbir [~balbir@59.145.136.1] has quit [Ping timeout: 480 seconds] |
| 07:58 | -!- | balbir [~balbir@59.145.136.1] has joined #uml |
| 08:11 | -!- | balbir [~balbir@59.145.136.1] has quit [Ping timeout: 480 seconds] |
| 09:03 | -!- | the_hydra [~mulyadi@125.161.247.93] has left #uml [] |
| 09:13 | -!- | dang [~dang@aa-redwall.ghs.com] has joined #uml |
| 09:48 | -!- | Infinito_ [~argos@200-101-125-148.gnace701.dsl.brasiltelecom.net.br] has joined #uml |
| 10:10 | -!- | ram [~ram@pool-71-117-243-179.ptldor.fios.verizon.net] has joined #uml |
| 10:46 | -!- | jdike [~jdike@pool-72-93-105-206.bstnma.fios.verizon.net] has joined #uml |
| 10:46 | <jdike:#uml> | Hi guys |
| 11:05 | -!- | balbir [~balbir@122.167.218.163] has joined #uml |
| 11:10 | -!- | kos_tom [~thomas@humanoidz.org] has quit [Quit: I like core dumps] |
| --- | Log | closed Fri Feb 15 11:23:16 2008 |
| --- | Log | opened Fri Feb 15 11:23:18 2008 |
| 11:23 | -!- | mikegrb [~michael@mikegrb.netrep.oftc.net] has joined #uml |
| 11:23 | -!- | Irssi: #uml: Total of 29 nicks [0 ops, 0 halfops, 0 voices, 29 normal] |
| --- | Log | closed Fri Feb 15 11:28:56 2008 |
| --- | Log | opened Fri Feb 15 11:35:35 2008 |
| 11:35 | -!- | mikegrb [~michael@mikegrb.netrep.oftc.net] has joined #uml |
| 11:35 | -!- | Irssi: #uml: Total of 29 nicks [0 ops, 0 halfops, 0 voices, 29 normal] |
| 11:35 | -!- | linbot [~supybot@ns.theshore.net] has joined #uml |
| 11:36 | -!- | VS_ChanLog [~stats@ns.theshore.net] has joined #uml |
| 11:37 | -!- | Irssi: Join to #uml was synced in 108 secs |
| 13:31 | -!- | aindilis [~aindilis@75.146.96.198] has quit [Remote host closed the connection] |
| 13:54 | -!- | ElectricElf [~dbharris@bas1-toronto48-1279276359.dsl.bell.ca] has quit [Read error: Operation timed out] |
| 13:55 | -!- | Infinito_ [~argos@200-101-125-148.gnace701.dsl.brasiltelecom.net.br] has quit [Quit: Leaving] |
| 14:03 | -!- | ElectricElf [~dbharris@bas1-toronto48-1279276359.dsl.bell.ca] has joined #uml |
| 14:34 | <fo0bar:#uml> | jdike: have you been getting feedback on skas4? I didn't see anything on lkml the last time you submitted |
| 14:49 | <jdike:#uml> | none on LKML so far |
| 14:54 | <flips:#uml> | jdike, 2.6.23.12 here, am I the only one getting random segfaults running under gdb? |
| 14:54 | <jdike:#uml> | what's segfaulting? |
| 14:55 | <flips:#uml> | things like memsets that are known-good |
| 14:56 | <jdike:#uml> | so the debuggee is segfaulting |
| 14:56 | <flips:#uml> | maybe |
| 14:56 | <jdike:#uml> | ? |
| 14:56 | <jdike:#uml> | you can't tell? |
| 14:56 | <flips:#uml> | seems to be uml |
| 14:57 | <flips:#uml> | I'm trying to reproduce, just a sec |
| 14:57 | <flips:#uml> | Program received signal SIGSEGV, Segmentation fault. |
| 14:57 | <flips:#uml> | 0x08140ca1 in dm_vcalloc (nmemb=8, elem_size=56) at include/asm/arch/string.h:186 |
| 14:57 | <flips:#uml> | 186 __asm__ __volatile__( |
| 14:58 | <jdike:#uml> | what are you gdb-ing? |
| 14:58 | <flips:#uml> | 2.6.23.12 with mods to dm-ioctl.c |
| 14:58 | <flips:#uml> | works fine not under uml |
| 14:58 | <jdike:#uml> | i.e. you are gdb-ing UML |
| 14:58 | <flips:#uml> | use |
| 14:58 | <flips:#uml> | yes |
| 14:58 | <jdike:#uml> | not running gdb inside UML |
| 14:59 | <jdike:#uml> | handle SIGSEGV pass nostop noprint |
| 14:59 | <flips:#uml> | right |
| 14:59 | <flips:#uml> | gdb -args ./linux ubd0=zuma/root ubd1=zuma/dev1 |
| 15:02 | <flips:#uml> | boots |
| 15:02 | <flips:#uml> | runs |
| 15:02 | <flips:#uml> | but what if I want to debug a segfault? |
| 15:03 | <jdike:#uml> | put a breakpoint on panic? |
| 15:03 | <flips:#uml> | ok :-) |
| 15:03 | <flips:#uml> | well |
| 15:04 | <flips:#uml> | annoying because you have to preplan |
| 15:04 | <flips:#uml> | but much better than printk debugging |
| 15:04 | <flips:#uml> | is there a known issue for this? |
| 15:04 | <jdike:#uml> | known issue? |
| 15:04 | <flips:#uml> | bug entered into bug tracker |
| 15:05 | <jdike:#uml> | it's a bug? |
| 15:05 | <flips:#uml> | walks and talks like a bug |
| 15:05 | <flips:#uml> | usability bug at best |
| 15:05 | <flips:#uml> | just doesn't work without the pass magic |
| 15:06 | <jdike:#uml> | well, UML uses SIGSEGV for page faults |
| 15:07 | <flips:#uml> | ah, anyway that is a good reason for entering a bug |
| 15:07 | <jdike:#uml> | gdb can't be expected to know the difference between a page fault SIGSEGV and a bug SIGSEGV |
| 15:07 | <flips:#uml> | then anybody can google for this and get the workaround, the reason and the wontfix |
| 15:07 | <flips:#uml> | I will enter the issue if you like |
| 15:08 | <jdike:#uml> | will bugzilla show up in google? |
| 15:08 | <flips:#uml> | bugzilla.kernel.org |
| 15:08 | <flips:#uml> | if not, we will fix google ;) |
| 15:08 | <jdike:#uml> | you will make google start mining online databases? |
| 15:08 | <flips:#uml> | already does |
| 15:08 | <flips:#uml> | it's just a question of which ones to focus on |
| 15:09 | <jdike:#uml> | OK, sounds like a plan to me |
| 15:11 | <flips:#uml> | I also get this a lot: |
| 15:11 | <flips:#uml> | F_SETLK failed, file already locked by pid 5752 |
| 15:11 | <flips:#uml> | Failed to lock 'zuma/root', err = 11 |
| 15:11 | <flips:#uml> | Failed to open 'zuma/root', errno = 11 |
| 15:11 | <flips:#uml> | ubda: Can't open "zuma/root": errno = 11 |
| 15:11 | <flips:#uml> | VFS: Cannot open root device "98:0" or unknown-block(98,0) |
| 15:12 | <flips:#uml> | the reason being a ./linux that did not die |
| 15:12 | <jdike:#uml> | yup |
| 15:12 | <flips:#uml> | needs to be kill minus nined |
| 15:12 | <flips:#uml> | is there a potential fix? |
| 15:13 | <jdike:#uml> | well, if there's some identifiable reason that the processes aren't dying, then yes |
| 15:14 | <jdike:#uml> | but if UML crashed, and you make it just exit, then it doesn't really have an opportunity to kill off the children |
| 15:15 | <flips:#uml> | have a uml killer daemon? |
| 15:15 | <flips:#uml> | there must be a way |
| 15:15 | <flips:#uml> | and yes, the cause is usually a uml crash |
| 15:16 | <jdike:#uml> | better be always |
| 15:16 | <flips:#uml> | always, probably |
| 15:16 | <jdike:#uml> | if not, then that is a bug |
| 15:16 | <flips:#uml> | still a bug, just a different kind |
| 15:17 | <flips:#uml> | I also see this often, seemingly randomly: |
| 15:17 | <flips:#uml> | 087fee6c: [<0806a29c>] show_regs+0xb4/0xb9 |
| 15:17 | <flips:#uml> | 087fee98: [<08058a14>] panic_exit+0x25/0x3f |
| 15:17 | <flips:#uml> | 087feeac: [<0807b7d8>] notifier_call_chain+0x21/0x4d |
| 15:17 | <flips:#uml> | 087feecc: [<0807b87a>] __atomic_notifier_call_chain+0x17/0x19 |
| 15:17 | <flips:#uml> | 087feee8: [<0807b891>] atomic_notifier_call_chain+0x15/0x17 |
| 15:17 | <flips:#uml> | ... |
| 15:18 | <jdike:#uml> | that's the panic notifier |
| 15:18 | <flips:#uml> | in other words, a traceback of the uml fault handler instead of the kernel stack |
| 15:18 | <flips:#uml> | right, but I don't get to see the kernel stack, whereas sometimes I do |
| 15:18 | <jdike:#uml> | where does the stack start? |
| 15:18 | <flips:#uml> | 087fee6c: [<0806a29c>] show_regs+0xb4/0xb9 |
| 15:18 | <flips:#uml> | 087fee98: [<08058a14>] panic_exit+0x25/0x3f |
| 15:18 | <flips:#uml> | 087feeac: [<0807b7d8>] notifier_call_chain+0x21/0x4d |
| 15:18 | <flips:#uml> | 087feecc: [<0807b87a>] __atomic_notifier_call_chain+0x17/0x19 |
| 15:18 | <flips:#uml> | 087feee8: [<0807b891>] atomic_notifier_call_chain+0x15/0x17 |
| 15:18 | <flips:#uml> | 087fef04: [<0807058e>] panic+0x52/0xdd |
| 15:18 | <flips:#uml> | 087fef24: [<08049a83>] mount_block_root+0xf8/0x10e |
| 15:18 | <flips:#uml> | 087fef78: [<08049ae5>] mount_root+0x4c/0x54 |
| 15:18 | <flips:#uml> | 087fef9c: [<08049be9>] prepare_namespace+0xfc/0x123 |
| 15:18 | <flips:#uml> | 087fefa4: [<080497ae>] kernel_init+0x79/0x85 |
| 15:18 | <flips:#uml> | 087fefb4: [<0806460f>] run_kernel_thread+0x37/0x40 |
| 15:18 | <flips:#uml> | 087fefe0: [<08058e21>] new_thread_handler+0x57/0x7e |
| 15:18 | <flips:#uml> | 087feffc: [<00000000>] obsolete_checksetup+0xf7fb7000/0x88 |
| 15:19 | <jdike:#uml> | that looks like a perfectly good kernel stack to me |
| 15:19 | <flips:#uml> | I often see that instead of a seg fault. Is this another facet of pass magic? |
| 15:20 | <flips:#uml> | sometimes I do see the kernel stack I am interested in, seemingly randomly |
| 15:20 | <flips:#uml> | well |
| 15:20 | <flips:#uml> | my example is probably wrong |
| 15:20 | <flips:#uml> | I need to capture next time |
| 15:20 | <jdike:#uml> | that particular stack is what happens when the filesystem is locked |
| 15:21 | <flips:#uml> | yes |
| 15:21 | <flips:#uml> | wrong cut n paste |
| 15:22 | <flips:#uml> | so why don't you distinquish automatically between segfaults generated from your page fault code and segfaults generted by the guest kernel? |
| 15:22 | <jdike:#uml> | me? |
| 15:22 | <flips:#uml> | uml |
| 15:22 | <jdike:#uml> | it does |
| 15:22 | <jdike:#uml> | page faults get fixed |
| 15:22 | <jdike:#uml> | bugs cause panics |
| 15:23 | <flips:#uml> | I mean, so the pass isn't needed, and also does not cover up guest kernel segfaults |
| 15:24 | <jdike:#uml> | sure it's needed |
| 15:24 | <jdike:#uml> | oh, nm |
| 15:24 | <jdike:#uml> | how can UML receive a page fault without gdb knowing about it |
| 15:24 | <jdike:#uml> | ? |
| 15:24 | <flips:#uml> | exactly my question |
| 15:24 | <flips:#uml> | seems to be a can't get there from here with gdb |
| 15:25 | <jdike:#uml> | that's a basic ptrace property |
| 15:25 | <flips:#uml> | s/gdb/ptrace/ |
| 15:25 | <jdike:#uml> | the only thing that knows the difference between a page fault and a bug is UML |
| 15:25 | <flips:#uml> | anyway, gdb could know about it, the issue is it has to be manually told to ignore, which creates another usability issue |
| 15:26 | <flips:#uml> | exactly |
| 15:26 | <jdike:#uml> | so there needs to be some UML processing before the difference is known |
| 15:26 | <flips:#uml> | and there is no way for these two (three?) things to cooperate, I presume |
| 15:27 | <flips:#uml> | the object-oriented fix for this kind of thing would to be add a method to gdb/ptrace/whatever that can be overriden |
| 15:27 | <jdike:#uml> | the knowledge of what memory areas are considered valid by the app would need to be exported to gdb somehow |
| 15:28 | <flips:#uml> | much as we do in kernel with certain faults |
| 15:28 | <jdike:#uml> | like what? |
| 15:29 | <flips:#uml> | see the fixups feature in do_fault |
| 15:30 | <jdike:#uml> | I wouldn't call that exporting |
| 15:31 | <flips:#uml> | you could call it nasty level crossing then |
| 15:31 | <flips:#uml> | it's a similar thing... take a fault that isn't differentiated properly, and differentiate by whatever means is necessary |
| 15:31 | <jdike:#uml> | but I wouldn't say that it suggests an interface for making gdb better informed |
| 15:32 | <flips:#uml> | anyway I have a clue what the issue is now, and how hard it would be to fix |
| 15:32 | <flips:#uml> | a lot of work in the name of a small improvement in fit and finish, |
| 15:33 | <flips:#uml> | it suggests what the nature of that interface would have to be |
| 15:33 | <flips:#uml> | maybe somebody has a cleverer technique |
| 15:33 | <flips:#uml> | but just handing it a list of "pass if the fault comes from here" seems the obvious way |
| 15:34 | <flips:#uml> | hmm |
| 15:37 | <flips:#uml> | actually, it is pass if the page has backing store |
| 15:37 | <jdike:#uml> | no |
| 15:38 | <jdike:#uml> | if it had backing store, there would be no fault in the first place |
| 15:39 | <flips:#uml> | ok, I don't know what you mean by uml uses SEGV for page faults then |
| 15:39 | <jdike:#uml> | someone calls vmalloc |
| 15:40 | <jdike:#uml> | kernel page tables are set up, but nothing else is done |
| 15:40 | <jdike:#uml> | someone accesses vmalloc memory |
| 15:40 | <jdike:#uml> | SIGSEGV, UML looks at page tables, maps in a page, retries the access |
| 15:42 | <flips:#uml> | ok, so the discrimator is the segv happened because the page has a not-present entry in the page tables |
| 15:43 | <flips:#uml> | so gdb/ptrace would need a way of asking uml that question in order to decide whether to pass |
| 15:43 | <jdike:#uml> | yeah |
| 15:44 | <flips:#uml> | worth somebody taking a run at if you did not have to do it yourself? |
| 15:46 | <flips:#uml> | another minor wart is xterms hanging around in the afterlife |
| 15:46 | <flips:#uml> | could also be fixed by a uml killer daemon utility |
| 15:47 | <jdike:#uml> | that might be fixable, assuming there are no UML processes also hanging around |
| 15:50 | -!- | Infinito [~argos@200-101-125-148.gnace701.dsl.brasiltelecom.net.br] has joined #uml |
| 16:00 | -!- | mjf [~mjf@r9fk174.net.upc.cz] has joined #uml |
| 16:25 | -!- | krau [~cktakahas@200.184.118.132] has quit [Ping timeout: 480 seconds] |
| 16:36 | -!- | krau [~cktakahas@200.184.118.136] has joined #uml |
| 17:05 | -!- | krau [~cktakahas@200.184.118.136] has quit [Quit: Varei!!!] |
| 17:21 | -!- | dang [~dang@aa-redwall.ghs.com] has quit [Remote host closed the connection] |
| 18:24 | -!- | Infinito [~argos@200-101-125-148.gnace701.dsl.brasiltelecom.net.br] has quit [Quit: Leaving] |
| 18:37 | -!- | mjf [~mjf@r9fk174.net.upc.cz] has quit [Quit: leaving] |
| 18:40 | -!- | jdike [~jdike@pool-72-93-105-206.bstnma.fios.verizon.net] has quit [Quit: Leaving] |
| 18:55 | -!- | flips [~phillips@phunq.net] has left #uml [Leaving] |
| 19:02 | -!- | Eman [~eman@dyn216-8-163-159.ADSL.mnsi.net] has joined #uml |
| 19:36 | -!- | silverblade [~silverbla@80.175.108.189] has joined #uml |
| 19:36 | <silverblade:#uml> | does UML have any uses on a regular desktop machine ? |
| 19:38 | <caker:#uml> | silverblade: the same uses as any of the other virt technologies that run Linux have |
| 19:38 | <silverblade:#uml> | oh hello caker lol |
| 19:38 | <caker:#uml> | :> |
| 19:39 | <silverblade:#uml> | i was considering toying around with it on my desktop machine but not quite sure what id do with it. i have a few test things like apache and mysql which id rather not have "polluting" my desktop environment... |
| 19:39 | <silverblade:#uml> | so i guess itd be useful for that? |
| 19:39 | -!- | krau [~cktakahas@189.70.3.242] has joined #uml |
| 19:43 | <caker:#uml> | silverblade: yes, it would |
| 19:44 | <silverblade:#uml> | how do you actually control the different virtual "machines"? i know with linode we have ssh, but whats the default method? |
| 19:45 | <caker:#uml> | silverblade: on a desktop install you can have UML start up terminals in a window |
| 19:46 | <silverblade:#uml> | oh neat |
| 19:46 | <silverblade:#uml> | what happens about memory? i know you can obviously limit the amount of ram but is it possible to remove restrictions? |
| 19:48 | <caker:#uml> | you assign memory to the UML kernel when you boot it |
| 19:48 | <caker:#uml> | mem= |
| 19:49 | <silverblade:#uml> | will it always use that amount? |
| 19:49 | <silverblade:#uml> | like a regular vm |
| 19:49 | <caker:#uml> | it ramps up to that amount, but if the UML is at all active it'll be using that amount in no time |
| 19:49 | <silverblade:#uml> | heh |
| 19:49 | <caker:#uml> | keep in mind UML is just a process on the host, so it can swap out, etc |
| 19:49 | <silverblade:#uml> | yeah |
| 19:50 | <silverblade:#uml> | i might try and knock together some nifty BOOTP stuff to make my 2nd desktop dualboot (its semi-headless) and use that as a host |
| 20:32 | -!- | aindilis [~aindilis@75.146.96.198] has joined #uml |
| 21:44 | -!- | ferret_0567 [~travis@72.191.26.86] has quit [Quit: keeping a cleaner screen environment for SSHing in] |
| 22:54 | -!- | remus [~remus@76.231.178.131] has quit [Remote host closed the connection] |
| 23:07 | -!- | dang [~dang@75.38.192.168] has joined #uml |
| 23:51 | -!- | linux__alien [~linux__al@59.92.19.236] has joined #uml |
| 23:52 | <linux__alien:#uml> | Is anyone running UML in Ubuntu ? Is it possible ? |
| 23:52 | <linux__alien:#uml> | i dont see a Ubuntu Filesystem in the UML page |
| 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 Feb 16 00:00:52 2008 |
