Lines Matching refs:at
304 The sources are also available from cvs at the project's cvs page,
721 appear to hang. In reality, it's waiting for a telnet to connect, at
824 Look at the boot log to see what pty it got (this example will assume
980 You can also add devices to a UML and remove them at runtime. See the
1066 You should be able to ping the host at this point.
1092 is for UML to just blindly throw all packets at the host and let it
1266 These were pointed out by Tim Robinson <timro at trkr dot net> in
1339 devices at boot time.
1567 renamed so the network weenies of the world would stop growling at me.
1679 you specified on the command line. These problems will be fixed at
1790 configured with a point-to-point address pointing at the UML ip
1934 of the backing file are stored in the COW file header at its creation,
2186 module. Then run UML with the boot device pointing at that directory:
2301 You'll get a prompt, at which you can run one of these commands:
2493 to gdb which will leave it stopped at the beginning of start_kernel.
2513 which you can do either by looking at ps on the host or at
2537 o look at its stack and anything else of interest
2545 Note that you can't do anything at this point that requires that a
2548 o when you're done looking at that process, reattach to the current
2662 Breakpoint 1 at 0xa0011923: file module.c, line 349.
2668 After you run UML and it sits there doing nothing, you hit return at
2701 mod_user=0x8070e00) at module.c:349
2705 mod_user=0x8070e00) at module.c:349
2706 0xa00e2e23 in execute_syscall (r=0xa8140284) at syscall_kern.c:411
2720 add symbol table from file "/home/jdike/linux/2.4/um/arch/um/fs/hostfs/hostfs.o" at
2757 is at module_list. If it's not, walk down the next links, looking at
2788 check it by looking at the module structure. The init and cleanup
3115 look at its stack:
3125 #1 0x10068ccd in usr1_pid (pid=1980) at process.c:30
3127 at process_kern.c:156
3129 at process_kern.c:161
3130 #4 0x10001d12 in schedule () at core.c:777
3131 #5 0x1006a744 in __down (sem=0x507d241c) at semaphore.c:71
3132 #6 0x1006aa10 in __down_failed () at semaphore.c:157
3133 #7 0x1006c5d8 in segv_handler (sc=0x5006e940) at trap_user.c:174
3134 #8 0x1006c5ec in kern_segv_handler (sig=11) at trap_user.c:182
3137 #11 0x1006c0aa in segv (address=1342179328, is_write=2) at trap_kern.c:50
3138 #12 0x1006c5d8 in segv_handler (sc=0x5006eaf8) at trap_user.c:174
3139 #13 0x1006c5ec in kern_segv_handler (sig=11) at trap_user.c:182
3144 at read_write.c:159
3146 at syscall_kern.c:254
3147 #18 0x1006af87 in really_do_syscall (sig=12) at syscall_user.c:35
3178 happened, so I have to go look at the sigcontent struct in frame 8:
3183 #1 0x10068ccd in usr1_pid (pid=1980) at process.c:30
3187 at process_kern.c:156
3191 at process_kern.c:161
3194 #4 0x10001d12 in schedule () at core.c:777
3197 #5 0x1006a744 in __down (sem=0x507d241c) at semaphore.c:71
3200 #6 0x1006aa10 in __down_failed () at semaphore.c:157
3203 #7 0x1006c5d8 in segv_handler (sc=0x5006e940) at trap_user.c:174
3206 #8 0x1006c5ec in kern_segv_handler (sig=11) at trap_user.c:182
3209 Cannot access memory at address 0x0.
3244 starts at address 0x1000b1b1 <handle_mm_fault+57>
3245 and ends at 0x1000b1b7 <handle_mm_fault+63>.
3258 starts at address 0x1000b1b7 <handle_mm_fault+63>
3259 and ends at 0x1000b1c3 <handle_mm_fault+75>.
3262 starts at address 0x1000b1d0 <handle_mm_fault+88>
3263 and ends at 0x1000b1da <handle_mm_fault+98>.
3266 starts at address 0x1000b1da <handle_mm_fault+98>
3267 and ends at 0x1000b1e1 <handle_mm_fault+105>.
3270 starts at address 0x1000b1f0 <handle_mm_fault+120>
3271 and ends at 0x1000b200 <handle_mm_fault+136>.
3274 starts at address 0x1000b200 <handle_mm_fault+136>
3275 and ends at 0x1000b208 <handle_mm_fault+144>.
3278 starts at address 0x1000b210 <handle_mm_fault+152>
3279 and ends at 0x1000b219 <handle_mm_fault+161>.
3281 Line 1168 of "memory.c" starts at address 0x1000b21e <handle_mm_fault+166>
3282 and ends at 0x1000b222 <handle_mm_fault+170>.
3289 lets go back to frame 11 and have a look at them:
3293 #11 0x1006c0aa in segv (address=1342179328, is_write=2) at trap_kern.c:50
3515 at ../sysdeps/unix/sysv/linux/sleep.c:78
3516 #2 0x1006ce9a in stop () at user_util.c:191
3517 #3 0x1006bf88 in segv (address=1342179328, is_write=2) at trap_kern.c:31
3518 #4 0x1006c628 in segv_handler (sc=0x5006eaf8) at trap_user.c:174
3519 #5 0x1006c63c in kern_segv_handler (sig=11) at trap_user.c:182
3523 at read_write.c:159
3525 at syscall_kern.c:254
3526 #10 0x1006af87 in really_do_syscall (sig=12) at syscall_user.c:35
3545 Going up the stack to the segv_handler frame and looking at where in
3559 at ../sysdeps/unix/sysv/linux/sleep.c:78
3562 #2 0x1006ce9a in stop () at user_util.c:191
3565 #3 0x1006bf88 in segv (address=1342179328, is_write=2) at trap_kern.c:31
3568 #4 0x1006c628 in segv_handler (sc=0x5006eaf8) at trap_user.c:174
3583 starts at address 0x1001c2a1 <block_write+1073>
3584 and ends at 0x1001c2bf <block_write+1103>.
3586 Line 110 of "block_dev.c" starts at address 0x1001c2bf <block_write+1103>
3587 and ends at 0x1001c2e3 <block_write+1139>.
3593 Looking at the source shows that the fault happened during a call to
3642 at 0x1001c2c2 as %ebp + 0xfffffdd4, so I figure exactly what that is,
3659 Now, I look at the structure to see what's in it, and particularly,
3684 0x50000000 page. Looking at it shows the kernel's idea of the state
3737 At this point, I jump to conclusions and start looking at my early
3764 Stepping into init_bootmem, and looking at bootmem_map before looking
3765 at what it contains shows the following:
3870 kernel BUG at page_alloc.c:100!
3904 out"> by Tim Robinson <timro at trkr dot net>
3919 point at the new headers. This will only be a problem if you build
3946 Documentation on IP Masquerading, and SNAT, can be found at
4053 mailing lists - either the developer list - user-mode-linux-devel at
4055 user-mode-linux-user at lists dot sourceforge do net (subscription
4067 list - user-mode-linux-devel at lists dot sourceforge dot net
4068 (subscription info) or the user list - user-mode-linux-user at lists
4096 at ../sysdeps/unix/sysv/linux/sigprocmask.c:49
4097 #1 0x10091411 in change_sig (signal=10, on=1) at process.c:218
4098 #2 0x10094785 in timer_handler (sig=26) at time_kern.c:32
4100 at ../sysdeps/unix/sysv/linux/i386/sigaction.c:125
4102 at trap_kern.c:66
4103 #5 0x10095c04 in segv_handler (sig=11) at trap_user.c:285
4138 pid. You can figure out the tracing thread pid by looking at the
4240 #1 0x100a2885 in idle_sleep (secs=10) at time.c:122
4241 #2 0x100a546f in do_idle () at process_kern.c:445
4242 #3 0x100a5508 in cpu_idle () at process_kern.c:471
4243 #4 0x100ec18f in start_kernel () at init/main.c:592
4244 #5 0x100a3e10 in start_kernel_proc (unused=0x0) at um_arch.c:71
4245 #6 0x100a383f in signal_tramp (arg=0x100a3dd8) at trap_user.c:50
4250 If this is the case, then some other process is at fault, and went to
4268 or no link at all, instead of the despammed email address pseudo-link,
4279 Rusty Russell <rusty at linuxcare.com.au> -
4293 Peter Moulder <reiter at netspace.net.au> - Fixed my config and build
4297 Bill Stearns <wstearns at pobox.com> -
4313 Jim Leu <jleu at mindspring.com> - Wrote the virtual ethernet driver
4321 Andrea Arcangeli <andrea at suse.de> - Redid some of the early boot
4329 Harald Welte <laforge at gnumonks.org> - Wrote the multicast
4336 Greg Lonnon <glonnon at ridgerun dot com> - Changed the ubd driver
4550 Bill Carr <Bill.Carr at compaq.com> made the Red Hat mkrootfs script
4553 Michael Jennings <mikejen at hevanet.com> sent in some material which
4557 SGI <http://www.sgi.com> (and more specifically Ralf Baechle <ralf at
4563 Laurent Bonnaud <Laurent.Bonnaud at inpg.fr> took the old grotty
4570 Rodrigo de Castro looked at my broken pte code and told me what was