From: Patrick M. <um...@me...> - 2004-02-18 16:05:28
|
hello >patching file arch/i386/kernel/ldt.c >Hunk #1 FAILED at 24. i could manually correct this one >patching file arch/i386/kernel/process.c >Hunk #1 FAILED at 551. >Hunk #2 FAILED at 568. >... >patching file include/asm-i386/processor.h >Hunk #1 FAILED at 436. but these two i couldn't fix. ("copy_segments" function seems to be gone) anyone any ideas? thanks patrick |
From: <sko...@up...> - 2004-02-19 20:29:32
|
> but these two i couldn't fix. > ("copy_segments" function seems to be gone) Bad news: I applied the 2.6.3-rc2 patch to a 2.6.3 kernel. This patch cleanly applies and i can compile a UML-kernel. Than i applied the SKAS-patch by Gerd Knorr from http://www.suse.de/~kraxel/uml/patches/ and guess what happened when i tried to compile my host-kernel: LD .tmp_vmlinux1 mm/built-in.o(.text+0x1d86f): In function `write_proc_mm': : undefined reference to `mm_copy_segments' make: *** [.tmp_vmlinux1] Error 1 So the copy_segments function has been removed from 2.4.25 and 2.6.3. |
From: Gerd K. <kr...@by...> - 2004-02-20 10:36:07
|
Sven K=C3=B6hler <sko...@up...> writes: > Than i applied the SKAS-patch by Gerd Knorr from > http://www.suse.de/~kraxel/uml/patches/ > and guess what happened when i tried to compile my host-kernel: >=20 > LD .tmp_vmlinux1 > mm/built-in.o(.text+0x1d86f): In function `write_proc_mm': You didn't apply the second patch, did you? Gerd |
From: <sko...@up...> - 2004-02-20 12:34:15
|
> You didn't apply the second patch, did you? Should i? The description of the second path was: Various fixups to make the whole tree build for all architectures. So i thought it is to make it compile on PPC or whatever. |
From: Gerd K. <kr...@by...> - 2004-02-20 13:16:12
|
On Fri, Feb 20, 2004 at 01:30:54PM +0100, Sven K=F6hler wrote: > >You didn't apply the second patch, did you? >=20 > Should i? Yes. > The description of the second path was: > Various fixups to make the whole tree build for all > architectures. >=20 > So i thought it is to make it compile on PPC or whatever. "all architectures" includes both ppc and i386 ;) Gerd --=20 Es geht darum, da=DF ein Haufen Scriptkiddies gerade dabei sind, USENET i= n Bunt neu zu erfinden, und sie derzeit einen Haufen Fehler neu machen, die schon seit 20 Jahren nicht mehr Gegenstand der Forschung sind. -- Kristian K=F6hntopp =FCber blogs und blogger |
From: <sko...@up...> - 2004-02-20 13:22:21
|
>>The description of the second path was: >> Various fixups to make the whole tree build for all >> architectures. >> >>So i thought it is to make it compile on PPC or whatever. > > "all architectures" includes both ppc and i386 ;) OK, after applying the second patch, the kernel compiles again. |
From: Goetz B. <bo...@bl...> - 2004-02-20 17:19:59
|
On Thu, Feb 19 '04 at 21:27, Sven K?hler wrote: > >but these two i couldn't fix. > >("copy_segments" function seems to be gone) > > Bad news: > > I applied the 2.6.3-rc2 patch to a 2.6.3 kernel. This patch cleanly > applies and i can compile a UML-kernel. Sorry to hear you have problems patcing 2.6.3, but what about posting with a different subject (and with out a In-Reply-To: header) if it has nothing to do with the problem desribed in the subject line. Sorry, but I was hoping for a solution to the problem in the Subject line. -- /"\ Goetz Bock at blacknet dot de -- secure mobile Linux everNETting \ / (c) 2004 as GNU FDL 1.1 X [ 1. Use descriptive subjects - 2. Edit a reply for brevity - ] / \ [ 3. Reply to the list - 4. Read the archive *before* you post ] |
From: BlaisorBlade <bla...@ya...> - 2004-02-20 20:29:18
|
Alle 17:00, mercoled=EC 18 febbraio 2004, Patrick Moor ha scritto: > hello > > >patching file arch/i386/kernel/ldt.c > >Hunk #1 FAILED at 24. > > i could manually correct this one > > >patching file arch/i386/kernel/process.c > >Hunk #1 FAILED at 551. > >Hunk #2 FAILED at 568. > >... > >patching file include/asm-i386/processor.h > >Hunk #1 FAILED at 436. > > but these two i couldn't fix. > ("copy_segments" function seems to be gone) Yes, it went away, so a new skas patch must be built. I have one (tested) a= t=20 http://www.user-mode-linux.org/~blaisorblade/ However, what is good is that things seems to be more similar to 2.6 (the=20 inserted code comes straight from 2.6, even in the meaningless things), and= =20 since a 2.6 skas patch exists and I know it well, I have prepared soon a=20 2.4.25 skas patch. Also, since disabling /proc/mm lead to a compilation failure, I've replaced= =20 the option with a message that says you cannot disable it. Enjoy it and good bye! =2D-=20 Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: Nix <ni...@es...> - 2004-02-21 15:57:32
|
On Fri, 20 Feb 2004, BlaisorBlade informed the cosmos: > Yes, it went away, so a new skas patch must be built. I have one (tested) at > http://www.user-mode-linux.org/~blaisorblade/ Alas: Checking for the skas3 patch in the host...found Checking for /proc/mm...found Checking for /dev/anon on the host...Not available (open failed with errno 2) Linux version 2.4.24-1um (compiler@loki) (gcc version 2.95.4 20010319 (prerelease)) #1 Wed Feb 18 22:58:16 GMT 2004 On node 0 totalpages: 24576 zone(0): 24576 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: con=port:16380 con0=fd:0,fd:1 fakeide mem=96M ubd0=/mirror/uml/esperi-root-cow.image,/mirr or/uml/esperi-root.image tty_log_dir=/home/firewall/log/esperi umid=esperi eth0=tuntap,tap0,00:60:97:79:E2:C1 e th1=tuntap,tap1 root=/dev/ubd0 Calibrating delay loop... 465.30 BogoMIPS Memory: 94412k available Dentry cache hash table entries: 16384 (order: 5, 131072 bytes) Inode cache hash table entries: 8192 (order: 4, 65536 bytes) Mount cache hash table entries: 512 (order: 0, 4096 bytes) Buffer cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Checking for host processor cmov support...No Checking for host processor xmm support...No Checking that ptrace can change system call numbers...OK Checking that host ptys support output SIGIO...Yes Checking that host ptys support SIGIO on close...No, enabling workaround POSIX conformance testing by UNIFIX Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd VFS: Disk quotas vdquot_6.5.1 Journalled Block Device driver loaded pty: 256 Unix98 ptys configured Universal TUN/TAP device driver 1.5 (C)1999-2002 Maxim Krasnyansky Initializing software serial port version 1 mconsole (version 2) initialized on /home/firewall/.uml/esperi/mconsole Partition check: ubda: unknown partition table Initializing stdio console driver Netdevice 0 (00:60:97:79:e2:c1) : TUN/TAP backend - Netdevice 1 (00:60:97:79:e2:c1) : TUN/TAP backend - NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 8192 bind 8192) ip_conntrack version 2.1 (737 buckets, 5896 max) - 288 bytes per conntrack ip_tables: (C) 2000-2002 Netfilter core team ipt_recent v0.3.1: Stephen Frost <sf...@sn...>. http://snowman.net/projects/ipt_recent/ NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. NET4: Ethernet Bridge 008 for NET4.0 VFS: Mounted root (ext2 filesystem) readonly. Kernel panic: switch_mm_skas - PTRACE_SWITCH_MM failed, errno = 5 That's -EIO. (Of course, CONFIG_PROC_MM=y on the host and the host is running 2.4.25+skas-2.4.25.) The identical UML binary is quite happy on 2.4.24; this email passed through it. -- `note to the crown prosecution service: Machine guns dont have a 'stun' setting.' --- mjw |
From: Nicholas L. <nic...@pl...> - 2004-02-23 06:38:07
|
On Fri, Feb 20, 2004 at 09:25:57PM +0100, BlaisorBlade wrote: > > Yes, it went away, so a new skas patch must be built. I have one (tested) at > http://www.user-mode-linux.org/~blaisorblade/ Using this patch against against 2.4.25 with evmns, libata and the vserver patch, I get the following compilation error:- nic@stateless:/usr/src/linux-2.4.25-vs1.3.7/mm$ gcc -D__KERNEL__ -I/usr/src/linux-2.4.25-vs1.3.7/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -iwithprefix include -DKBUILD_BASENAME=proc_mm -c -o proc_mm.o proc_mm.c proc_mm.c: In function `open_proc_mm': proc_mm.c:109: error: too few arguments to function `mm_alloc' mm_alloc seems to come from: <linux/sched.h> ... extern struct mm_struct * mm_alloc(struct vx_info *); vx_info is defined in <linux/vserver/context.h> Looks like vserver has redefined:- -extern struct mm_struct * mm_alloc(void); +extern struct mm_struct * mm_alloc(struct vx_info *); I don't know the kernel well enough to add the appropiate call to: static int open_proc_mm(struct inode *inode, struct file *file) { struct mm_struct *mm = mm_alloc(); I'm guessing it might be something like mm_alloc(current->vx_info); -- Nicholas Lee - nj.lee at plumtree.co dot nz, somewhere on the fish Maui caught. gpg. 8072 4F86 EDCD 4FC1 18EF 5BDD 07B0 9597 6D58 D70C Quixotic Eccentricity |
From: Patrick M. <um...@me...> - 2004-02-24 16:07:53
|
hi > Yes, it went away, so a new skas patch must be built. I have one (tested) at > http://www.user-mode-linux.org/~blaisorblade/ works great over here! thanks a lot! greetings patrick |
From: BlaisorBlade <bla...@ya...> - 2004-02-22 15:29:21
|
Alle 16:50, sabato 21 febbraio 2004, Nix ha scritto: > On Fri, 20 Feb 2004, BlaisorBlade informed the cosmos: > > Yes, it went away, so a new skas patch must be built. I have one (tested) > > at http://www.user-mode-linux.org/~blaisorblade/ I'm running that patch and someone else reported success. > Checking for the skas3 patch in the host...found > Checking for /proc/mm...found > Checking for /dev/anon on the host...Not available (open failed with errno > 2) Linux version 2.4.24-1um (compiler@loki) (gcc version 2.95.4 20010319 > (prerelease)) #1 Wed Feb 18 22:58:16 GMT 2004 > On node 0 totalpages: 24576 > zone(0): 24576 pages. > zone(1): 0 pages. > zone(2): 0 pages. > Kernel command line: con=port:16380 con0=fd:0,fd:1 fakeide mem=96M > ubd0=/mirror/uml/esperi-root-cow.image,/mirr or/uml/esperi-root.image > tty_log_dir=/home/firewall/log/esperi umid=esperi > eth0=tuntap,tap0,00:60:97:79:E2:C1 e th1=tuntap,tap1 root=/dev/ubd0 > Calibrating delay loop... 465.30 BogoMIPS > Memory: 94412k available > Dentry cache hash table entries: 16384 (order: 5, 131072 bytes) > Inode cache hash table entries: 8192 (order: 4, 65536 bytes) > Mount cache hash table entries: 512 (order: 0, 4096 bytes) > Buffer cache hash table entries: 4096 (order: 2, 16384 bytes) > Page-cache hash table entries: 32768 (order: 5, 131072 bytes) > Checking for host processor cmov support...No > Checking for host processor xmm support...No > Checking that ptrace can change system call numbers...OK > Checking that host ptys support output SIGIO...Yes > Checking that host ptys support SIGIO on close...No, enabling workaround > POSIX conformance testing by UNIFIX > Linux NET4.0 for Linux 2.4 > Based upon Swansea University Computer Society NET3.039 > Initializing RT netlink socket > Starting kswapd > VFS: Disk quotas vdquot_6.5.1 > Journalled Block Device driver loaded > pty: 256 Unix98 ptys configured > Universal TUN/TAP device driver 1.5 (C)1999-2002 Maxim Krasnyansky > Initializing software serial port version 1 > mconsole (version 2) initialized on /home/firewall/.uml/esperi/mconsole > Partition check: > ubda: unknown partition table > Initializing stdio console driver > Netdevice 0 (00:60:97:79:e2:c1) : TUN/TAP backend - > Netdevice 1 (00:60:97:79:e2:c1) : TUN/TAP backend - > NET4: Linux TCP/IP 1.0 for NET4.0 > IP Protocols: ICMP, UDP, TCP, IGMP > IP: routing cache hash table of 512 buckets, 4Kbytes > TCP: Hash tables configured (established 8192 bind 8192) > ip_conntrack version 2.1 (737 buckets, 5896 max) - 288 bytes per conntrack > ip_tables: (C) 2000-2002 Netfilter core team > ipt_recent v0.3.1: Stephen Frost <sf...@sn...>. > http://snowman.net/projects/ipt_recent/ NET4: Unix domain sockets 1.0/SMP > for Linux NET4.0. > NET4: Ethernet Bridge 008 for NET4.0 > VFS: Mounted root (ext2 filesystem) readonly. > Kernel panic: switch_mm_skas - PTRACE_SWITCH_MM failed, errno = 5 > > That's -EIO. > > (Of course, CONFIG_PROC_MM=y on the host and the host is running > 2.4.25+skas-2.4.25.) Hmmm, I've looked at the faulting code and IMHO the most probable thing is a compilation problem (forgot make dep after applying the patch, for instance) - try saving your .config, running make mrproper, grepping through .config to check that CONFIG_PROC_MM=y and recompiling the bzImage: $ make dep bzImage Rebuilding modules *probably* is not necessary, but I'm not sure - rerun depmod with the newly created System.map with the already installed 2.4.25 modules to check that symbols can actually be resolved. More exactly, it seems that arch/i386/kernel/ptrace.c was recompiled after applying the patch but without CONFIG_PROC_MM on. Also, IMHO that kind of error cannot be returned by sys_ptrace, unless CONFIG_PROC_MM was off when compiling that file (I've also checked proc_mm_get_mm). Bye -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: Nix <ni...@es...> - 2004-02-22 18:12:16
|
On Sun, 22 Feb 2004, BlaisorBlade said: > Hmmm, I've looked at the faulting code and IMHO the most probable thing is a > compilation problem (forgot make dep after applying the patch, for instance) - > try saving your .config, running make mrproper, > grepping through .config to check that CONFIG_PROC_MM=y and recompiling the > bzImage: > $ make dep bzImage It's highly plausible that exactly that happened: I forgot `make oldconfig' during the first build and assumed (ha!) that `make dep' would fix everything up OK so that a config change would trigger rebuilds appropriately. Possibly this was a foolish assumption and a `make dep clean' was necessary. > More exactly, it seems that arch/i386/kernel/ptrace.c was recompiled after > applying the patch but without CONFIG_PROC_MM on. OK. > Also, IMHO that kind of error cannot be returned by sys_ptrace, unless > CONFIG_PROC_MM was off when compiling that file (I've also checked > proc_mm_get_mm). That's my conclusion too. I'll try rebuilding from scratch tomorrow evening and see if that works. (Oops.) -- `note to the crown prosecution service: Machine guns dont have a 'stun' setting.' --- mjw |
From: BlaisorBlade <bla...@ya...> - 2004-02-22 20:00:56
|
Alle 19:04, domenica 22 febbraio 2004, Nix ha scritto: > On Sun, 22 Feb 2004, BlaisorBlade said: > > Hmmm, I've looked at the faulting code and IMHO the most probable thing > > is a compilation problem (forgot make dep after applying the patch, for > > instance) - try saving your .config, running make mrproper, > > grepping through .config to check that CONFIG_PROC_MM=y and recompiling > > the bzImage: > > $ make dep bzImage > > It's highly plausible that exactly that happened: I forgot `make > oldconfig' during the first build and assumed (ha!) that `make dep' > would fix everything up OK so that a config change would trigger > rebuilds appropriately. Possibly this was a foolish assumption and a > `make dep clean' was necessary. When analyzing your bug I was really astonished - I thought at a such scenario ( 1st build without CONFIG_PROC_MM created ptrace.o but then failed - config updated - rebuild all but ptrace.o is not rebuilt) and posted my answer in that hypothesis, but I thought that was too hard to trigger and that I had made some errors. Make dep should have fixed things, so it's not your fault, but in this case it didn't - sometimes happens in 2.4 builds. Luckily, 2.6 finally fixed this (at least for what I've heard and for my personal experience). Good bye and best wishes for your new kernel! -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: Nix <ni...@es...> - 2004-02-25 08:06:52
|
On Sun, 22 Feb 2004, BlaisorBlade mused: > When analyzing your bug I was really astonished - I thought at a such scenario > ( 1st build without CONFIG_PROC_MM created ptrace.o but then failed - config > updated - rebuild all but ptrace.o is not rebuilt) and posted my answer in > that hypothesis, but I thought that was too hard to trigger and that I had > made some errors. ... and after a full rebuild it works. It's easy to trigger that scenario if one is sufficiently distracted when building :) Blasted blasted dependencies. > Good bye and best wishes for your new kernel! She lives, she lives! -- `note to the crown prosecution service: Machine guns dont have a 'stun' setting.' --- mjw |
From: BlaisorBlade <bla...@ya...> - 2004-02-25 19:11:52
|
Alle 07:30, luned=EC 23 febbraio 2004, Nicholas Lee ha scritto: > On Fri, Feb 20, 2004 at 09:25:57PM +0100, BlaisorBlade wrote: > > Yes, it went away, so a new skas patch must be built. I have one (teste= d) > > at http://www.user-mode-linux.org/~blaisorblade/ > > Using this patch against against 2.4.25 with evmns, libata and the > vserver patch, I get the following compilation error:- You mean libata for Serial ATA support, EVMS from IBM as a LVM+RAID, right?= =20 But what is vserver? > > nic@stateless:/usr/src/linux-2.4.25-vs1.3.7/mm$ gcc -D__KERNEL__ > -I/usr/src/linux-2.4.25-vs1.3.7/include -Wall -Wstrict-prototypes > -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer > -pipe -mpreferred-stack-boundary=3D2 -march=3Di686 -nostdinc -iwithpref= ix > include -DKBUILD_BASENAME=3Dproc_mm -c -o proc_mm.o proc_mm.c proc_mm.c:= In > function `open_proc_mm': > proc_mm.c:109: error: too few arguments to function `mm_alloc' > > > mm_alloc seems to come from: > > <linux/sched.h> > ... > extern struct mm_struct * mm_alloc(struct vx_info *); > > > vx_info is defined in <linux/vserver/context.h> > > > Looks like vserver has redefined:- > > -extern struct mm_struct * mm_alloc(void); > +extern struct mm_struct * mm_alloc(struct vx_info *); > > > I don't know the kernel well enough to add the appropiate call to: > > static int open_proc_mm(struct inode *inode, struct file *file) > { > struct mm_struct *mm =3D mm_alloc(); > > I'm guessing it might be something like > > mm_alloc(current->vx_info); If you want to try yourself: "current" type is struct task_struct *, which = is=20 defined in linux/sched.h; check if a such member is defined in that struct,= =20 and if it is so you can try doing what you suggest and running the resultin= g=20 kernel. But you could also "learn by samples": look in the "vserver" patch= =20 how the new mm_alloc is used, and what vx_info stands for (i.e. - what fiel= ds=20 it contains and when mm_alloc is passed something different than=20 current->vx_info). However, if you want something reliable enough, post a pointer to the exact= =20 patch file that you applied for "vserver", and a description of what it doe= s=20 (an URL describing it or the "vserver" project homepage could suffice for t= he=20 description). If I have time I could answer you saying what you do, i.e. if= a=20 such change can suffice or if the two patches interfere too much. =2D-=20 Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: Nicholas L. <nj...@pl...> - 2004-02-25 19:49:37
|
On Wed, Feb 25, 2004 at 04:54:39PM +0100, BlaisorBlade wrote: > Alle 07:30, lunedì 23 febbraio 2004, Nicholas Lee ha scritto: > > On Fri, Feb 20, 2004 at 09:25:57PM +0100, BlaisorBlade wrote: > > > Yes, it went away, so a new skas patch must be built. I have one (tested) > > > at http://www.user-mode-linux.org/~blaisorblade/ > > > > Using this patch against against 2.4.25 with evmns, libata and the > > vserver patch, I get the following compilation error:- > > You mean libata for Serial ATA support, EVMS from IBM as a LVM+RAID, right? > But what is vserver? http://www.linux-vserver.org/ > However, if you want something reliable enough, post a pointer to the exact > patch file that you applied for "vserver", and a description of what it does > (an URL describing it or the "vserver" project homepage could suffice for the > description). If I have time I could answer you saying what you do, i.e. if a > such change can suffice or if the two patches interfere too much. The particular patch in question is at: http://www.13thfloor.at/vserver/d_release/v1.3.7 Document is a bit tricky to understand so, I might go back and try the stable version instead: http://www.13thfloor.at/vserver/s_release/v1.26 vserver is basically virtual servers via capabilities. ie. Same kernel, different context. -- Nicholas Lee - nj.lee at plumtree.co dot nz, somewhere on the fish Maui caught. gpg. 8072 4F86 EDCD 4FC1 18EF 5BDD 07B0 9597 6D58 D70C Quixotic Eccentricity |
From: BlaisorBlade <bla...@ya...> - 2004-02-25 20:12:23
|
Alle 20:40, mercoled=EC 25 febbraio 2004, Nicholas Lee ha scritto: > On Wed, Feb 25, 2004 at 04:54:39PM +0100, BlaisorBlade wrote: > > Alle 07:30, luned=EC 23 febbraio 2004, Nicholas Lee ha scritto: > > > On Fri, Feb 20, 2004 at 09:25:57PM +0100, BlaisorBlade wrote: > > > > Yes, it went away, so a new skas patch must be built. I have one > > > > (tested) at http://www.user-mode-linux.org/~blaisorblade/ > > > > > > Using this patch against against 2.4.25 with evmns, libata and the > > > vserver patch, I get the following compilation error:- > > > > You mean libata for Serial ATA support, EVMS from IBM as a LVM+RAID, > > right? But what is vserver? > > http://www.linux-vserver.org/ > > > However, if you want something reliable enough, post a pointer to the > > exact patch file that you applied for "vserver", and a description of > > what it does (an URL describing it or the "vserver" project homepage > > could suffice for the description). If I have time I could answer you > > saying what you do, i.e. if a such change can suffice or if the two > > patches interfere too much. > > The particular patch in question is at: > http://www.13thfloor.at/vserver/d_release/v1.3.7 > > Document is a bit tricky to understand so, I might go back and try the > stable version instead: http://www.13thfloor.at/vserver/s_release/v1.26 > vserver is basically virtual servers via capabilities. ie. Same kernel, > different context. Yes, I got it. With the first look I gave, I can think that your fix is the= =20 right one - you already checked what I said you. I cannot guarantee that it= =20 works - but current->vx_info is very meaningful and makes a lot of sense. However, I'd recommend you to be careful about starting UML's from inside=20 vserver - if you want, test it first and be careful about crashes. Reports= =20 about both success or failure are needed and welcome! Bye and thanks. =2D-=20 Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |