From: Jeff D. <jd...@ka...> - 2001-12-05 23:10:54
|
mi...@st... said: > would you be able to apply this to cvs ? its just to get cvs to ignore > the bins created in the tools dir OK, I'll drop that in. Jeff |
From: Jeff D. <jd...@ka...> - 2002-02-08 07:09:52
|
jam...@ho... said: > If this is in main.c root=/dev/ubd0 works and so does root=/dev/ubda > both of which still refer to the original ubd0 whole disk. > Does this meet your requirements for compatibility for ubd0..7 root= ? Yeah, I think so. > On using AIO in ubd.c I was thinking to use the glibc for the basic > <aio.h> stuff thread based but works everywhere, when one of the AIO > patches finally makes it into the mainline then it will also work > there without much change. Don't do that. I want either the existing mechanism or the new AIO mechanism to be chosen and I want the new AIO to be used directly, with no unnecessary libc help. The reason is that libc has to be used carefully. In particular, it can not be allowed to fork, which is what the existing libc AIO does. This is because the current stack is MAP_SHARED, and fork counts on the stack being COW between the two processes. If it isn't, then both processes run on the same stack and very bad things happen. > I would also like to add a struct request * and struct aiocb * to the > struct io_thread_req to allow the io_thread to get each io_req and > then prepare a aio_read/write and have the a _user side handler in > SIGIO mode to take the SIGEV_SIGNAL aio request complete and do the > write to cause ubd_handler to run. ubd_handler would get the io_req > back and do the equivialent of end_request on that request (using > LOCAL_END_REQUEST) This will require that while(1) loop or similar and > it might also end up queuing into the pipe to io_thread. io_thread > would nolonger do the write to wake up ubd_handler and instead just > start the aio and a signal handler for the aio would do the write > instead. Is this describing the glibc AIO interface or the new kernel AIO? Jeff |
From: Jeff D. <jd...@ka...> - 2002-04-16 20:50:30
|
hk...@us... said: > I saw the earlier append by Jeff regarding need for "TLB for IPI". If > someone I guess "someone" would be me :-) > could provide a little more here, and maybe contact info for > principal SMP developers, perhaps we could help move this along. The basic problem is that on an SMP box one process (or thread) can change the address space of a thread running on a different processor. The two major examples: The system is short on memory, so one processor runs the memory scanner, unmapping unused pages from other processes, which may currently be running on other processors. Those processes need to be told then that their address space has changed. A multi-threaded app has threads running simultaneously on multiple processors. Anything that changes the address space must be communicated to those other processors. This is more than explicit mmaps. Faulting in pages from the binary or demand-loading zero pages also count. We have an IPI mechanism in place now. Every processor gets a pipe - it registers for SIGIO on one end of the pipe, and another processor which wants to send an IPI writes a byte in the other end. i386 implements a little data structure for telling the target processor what needs doing. I think that code can just be stolen and dropped into UML. Once that's there, any time UML ends up in flush_tlb_*, it needs to see whether the address space changes being made need to be communicated to other processors. I'm not sure how this is done, but looking at how other arches manage should give you a clue. Then you fill in one of those little data structures, write into the appropriate pipe, and the target processor calls flush_tlb_* itself. One complication is that this causes flush_tlb_* to be invoked from interrupt context, which would require IRQ blocking around any flush_tlb_*. Offhand, it seems safe to me to move this into a tasklet, which would avoid this locking requirement. You want to address space update to happen soon, but I think it's safe to delay it till tasklet time. Jeff |
From: David C. <da...@da...> - 2002-10-22 19:40:36
|
Steve Schmidtke wrote: > Hmmm, it may be a side effect of the patch, but I doubt it. It's only the slirp transport which throws up the panic. > Is there > anything special about the mounts? Does the uml boot without them? > Also, slirp cannot NFS mount from servers that don't have "insecure" set > in their exports (it's a user process on the host and has to remap root > reserved ports, like NFS, to >=1024, possibly confusing things in the UML). Sorry, my mistake. It's not actually setting up mounts, it's setting up exports (there aren't any anyway). My console output is as follows: Starting kernel log daemon: klogd. Starting portmap daemon: portmap. Setting NIS domainname to: davidcoulson.net Starting NIS services: ypbind Not starting NFS kernel daemon: No exports. Kernel panic: kernel BUG at slab.c:1443! BTW, how should I set up my eth0 when using slirp? What IP address should I give it and how should routeing be configured? -- David Coulson http://davidcoulson.net/ d...@vi... http://journal.davidcoulson.net/ |
From: Steve S. <ste...@ho...> - 2002-10-22 20:24:49
|
da...@da... wrote: >Steve Schmidtke wrote: >>Hmmm, it may be a side effect of the patch, but I doubt it. > >It's only the slirp transport which throws up the panic. Try this change to the patch for slirp_header_cache(): - return(0); + return(-1); there may be random memory used if the function says it succeeded - if it fails, could you break on the hard header routines and bt them? I'd like to know where they are specifically being called from. If that doesn't work, try changing the interface type in slirp_init: - dev->type = ARPHRD_ETHER; + dev->type = ARPHRD_SLIP; slirp doesn't have the guts for real ethernet, and maybe shouldn't be pretending to be. >BTW, how should I set up my eth0 when using slirp? What IP address should I >give it and how should routeing be configured? Using the host address, or an address you plan to connect to, will cause problems, but otherwise any private address should do - the one slirp reccomends on boot is usually good. For routing, this is what I do: route add default dev eth0 Steve Schmidtke _________________________________________________________________ Get a speedy connection with MSN Broadband. Join now! http://resourcecenter.msn.com/access/plans/freeactivation.asp |
From: David C. <da...@da...> - 2002-10-22 20:40:15
|
Steve Schmidtke wrote: > Try this change to the patch for slirp_header_cache(): > > - return(0); > + return(-1); That did the job. I just did a dist-upgrade over slirp and it works great. > Using the host address, or an address you plan to connect to, will cause > problems, but otherwise any private address should do - the one slirp > reccomends on boot is usually good. For routing, this is what I do: > > route add default dev eth0 Like an idiot, I tried to test it with ping - Forgot that doesn't work as a non-root user. I just checked the slirp documentation again, and it seems that lots of IPs in the 10.2.0.0/24 network are used by slirp for special things, so I'll use 10.2.0.15 for the UML. Now to another problem. It maxes out at 10k/sec, due to the 115200 baud default. I tried to use 1250000 with the command '/usr/bin/slirp baudrate 1250000', but it ended up with UML thinking that 'baudrate' and '1250000' were options to it's command line, which obviously didn't work. Any suggestions? Thanks, David -- David Coulson http://davidcoulson.net/ d...@vi... http://journal.davidcoulson.net/ |
From: Steve S. <ste...@ho...> - 2002-10-22 21:12:25
|
>Steve Schmidtke wrote: >>Try this change to the patch for slirp_header_cache(): >> >>- return(0); >>+ return(-1); > >That did the job. I just did a dist-upgrade over slirp and it works great. good. The slip transport should be suffering from the same problem, I'll see if I can pretty something up for Jeff for those. I'm surprised the other transports don't show problems, they don't register hh functions either... >Like an idiot, I tried to test it with ping - Forgot that doesn't work as a >non-root user. From inside uml? The slackware 8 ping sort of works ;) >Now to another problem. It maxes out at 10k/sec, due to the 115200 baud >default. I tried to use 1250000 with the command '/usr/bin/slirp baudrate >1250000', but it ended up with UML thinking that 'baudrate' and '1250000' >were options to it's command line, which obviously didn't work. Any >suggestions? yes, and thanks, I'm not the only one with that problem... :) The proper solution for now is to write a slirp wrapper, something like this: #!/bin/sh exec /usr/local/bin/slirp 'baudrate 1250000' and call the wrapper from the setup string: eth0=slirp,,./bin/slirpwrapper.sh The dirty hack is to do this in slirp_setup: init->argw.argv[i++] = str; while(*str && *str!=',') { + if(*str=='_') *str=' '; str++; } if(*str!=',') Which changes underscores to spaces and lets you write: eth0=slirp,,slirp,baudrate_1250000 Jeff hasn't put in the hack, and with being able to call a wrapper, I don't see an issue leaving it that way for now. Either way, changing the baudrate will probably get you 20K+ per sec, which then seems to be limited by something in the slirp binary. There's a q&d hack I have for the slirp sources as well :) >Thanks, >David > >-- >David Coulson http://davidcoulson.net/ >d...@vi... http://journal.davidcoulson.net/ _________________________________________________________________ Choose an Internet access plan right for you -- try MSN! http://resourcecenter.msn.com/access/plans/default.asp |
From: David C. <da...@da...> - 2002-10-22 21:22:38
|
Steve Schmidtke wrote: > good. The slip transport should be suffering from the same problem, > I'll see if I can pretty something up for Jeff for those. I'm surprised > the other transports don't show problems, they don't register hh > functions either... Well, tuntap works fine here - I don't use any of the other transports frequently. > From inside uml? The slackware 8 ping sort of works ;) Interesting - How does it do that then? I don't see how slirp on the host can open a raw socket for the ping > yes, and thanks, I'm not the only one with that problem... :) I just made a ~/.slirprc and put; -b 8388608 Seems to work fine, and I don't have to do anything special. > Either way, changing the baudrate will probably get you 20K+ per sec, > which then seems to be limited by something in the slirp binary. > There's a q&d hack I have for the slirp sources as well :) Oh, poop. That answers my other question then. David -- David Coulson http://davidcoulson.net/ d...@vi... http://journal.davidcoulson.net/ |
From: Steve S. <ste...@ho...> - 2002-10-22 21:36:46
|
da...@da... wrote: >>From inside uml? The slackware 8 ping sort of works ;) > >Interesting - How does it do that then? I don't see how slirp on the host >can open a raw socket for the ping Well, any ping actually, will work pinging to the host slirp is attached to - that's a special case. I mentioned it to poke fun at myself for a bug I thought I had found. >I just made a ~/.slirprc Yup, even better. I'll remember it for the doc. Steve Schmidtke _________________________________________________________________ Unlimited Internet access for only $21.95/month. Try MSN! http://resourcecenter.msn.com/access/plans/2monthsfree.asp |
From: David C. <da...@da...> - 2002-10-22 21:48:30
|
Steve Schmidtke wrote: > Well, any ping actually, will work pinging to the host slirp is attached > to - that's a special case. I mentioned it to poke fun at myself for a > bug I thought I had found. Ah, yes :-) > Yup, even better. I'll remember it for the doc. And it all works great now I hacked the source code - I built a .deb, so if anyone else wants it, let me know. David -- David Coulson http://davidcoulson.net/ d...@vi... http://journal.davidcoulson.net/ |
From: Jeff D. <jd...@ka...> - 2002-11-04 04:56:40
|
ste...@ho... said: > The dirty hack is to do this in slirp_setup: > init->argw.argv[i++] = str; > while(*str && *str!=',') { > + if(*str=='_') *str=' '; > str++; > } > if(*str!=',') That nasty kludge is in. Jeff |
From: Jeff D. <jd...@ka...> - 2002-11-21 19:59:58
|
te...@ka... said: > diff -Naur a/arch/um/Kconfig b/arch/um/Kconfig > --- a/arch/um/Kconfig Thu Nov 21 13:53:19 2002 > +++ b/arch/um/Kconfig Thu Nov 21 13:51:13 2002 Applied, thanks. Jeff |
From: Jeff D. <jd...@ka...> - 2002-12-15 02:34:34
|
ms...@on... said: > Has there been any discussion about porting UML to Alpha? > Any thoughts? Is it possible? It's possible. There are no current working ports of UML besides x86, but the ppc port was very close to totally working at one point. There are Sparc and IA64 ports in the works. The fact that there are no maintained ports in the UML pool means that a new port will be more work than it ought to be, but since there have been porting efforts in the past, a new one shouldn't be too painful. Jeff |
From: Stroesser, B. <Bod...@fu...> - 2004-09-27 09:25:22
|
On Saturday 25 September 2004 21:35, BlaisorBlade wrote:=20 > ... > This particular part is Ok, but could you, please, avoid trumpling over and removing the sysemu code? It's absolutely not needed. > If you enclose the last two ptrace calls in "if (!use_sysemu)" and you move the "handle_syscall" after them, you get your fix + no change for sysemu. Sorry. I didn't intend to break sysemu! Did I miss something or does it come from my confusing mail format? Here is the code of handle_trap() after applying the patch: --- static void handle_trap(int pid, union uml_pt_regs *regs) { int err, syscall_nr, status; syscall_nr =3D PT_SYSCALL_NR(regs->skas.regs); UPT_SYSCALL_NR(regs) =3D syscall_nr; if(syscall_nr < 0){ relay_signal(SIGTRAP, regs); return; } if(!use_sysemu) { err =3D ptrace(PTRACE_POKEUSER, pid, PT_SYSCALL_NR_OFFSET, __NR_getpid); if(err < 0) panic("handle_trap - nullifying syscall failed, errno =3D %d\n", errno); err =3D ptrace(PTRACE_SYSCALL, pid, 0, 0); if(err < 0) panic("handle_trap - continuing to end of syscall failed, " "errno =3D %d\n", errno); CATCH_EINTR(err =3D waitpid(pid, &status, WUNTRACED)); if((err < 0) || !WIFSTOPPED(status) ||=20 (WSTOPSIG(status) !=3D SIGTRAP)) panic("handle_trap - failed to wait at end of syscall, " "err =3D %d, errno =3D %d, status =3D %x\n", err, errno, status); } handle_syscall(regs); } > ... > A side note: posting HTML messages is bad (on LKML it is enough to be totally & completely ignored, I guess); and the above is what the inline patch becomes while answering to an HTML message - could you please either send plain-text or move the patches to attachments (I strongly prefer the first solution)? OK. Thank you for the advice. Unfortunately I'm missing experience in writing to mailing lists. And I have to do it with our companies Outlook client... In the meantime I found a switch to modify the settings to "text only". Hope it's better now? Bodo |
From: BlaisorBlade <bla...@ya...> - 2004-09-29 17:36:29
|
On Monday 27 September 2004 11:20, Stroesser, Bodo wrote: > On Saturday 25 September 2004 21:35, BlaisorBlade wrote: > > ... > > This particular part is Ok, but could you, please, avoid trumpling > > over and removing the sysemu code? It's absolutely not needed. > > > If you enclose the last two ptrace calls in "if (!use_sysemu)" and you > > move the "handle_syscall" after them, you get your fix + no change for > sysemu. > Sorry. I didn't intend to break sysemu! Did I miss something or does it > come from my confusing mail format? > Here is the code of handle_trap() after applying the patch: Ah, ok. Please accept my excuses, I didn't read well the patch (was I too tired?). However ok, it is correct, and the code is written this way in 2.6.9-rc2, in fact, as with the original sysemu patch - the problem was in some little changes done by Jeff in his tree. > > ... > > A side note: posting HTML messages is bad (on LKML it is enough to be > > totally & completely ignored, I guess); and the above is what the inline > patch becomes while answering to an HTML message - could you please > either send plain-text or move the patches to attachments (I strongly > prefer the first solution)? > OK. Thank you for the advice. Unfortunately I'm missing experience in > writing to mailing lists. And I have to do it with our companies Outlook > client... > In the meantime I found a switch to modify the settings to "text only". > Hope it's better now? Ok, that's perfect! If you want to get advices on such questions, you may want to take a look at the LKML FAQ: http://www.tux.org/lkml/ (The only important question I remember is "when/why to send the patch inline/attached/send an URL from the Web"). And these two documents about patch submission format: http://linux.yyz.us/patch-format.html http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt (Note: when you find differences, do whatever you prefer; inserting the kernel version is a good idea, like the 1st doc says). Bye -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |