From: Henry N. <Henry.Ne@Arcor.de> - 2006-07-17 07:37:44
|
Hallo, have started a patch for kernel 2.6.17, is not runable. Need to change some things in starup code for colinux 'co_early_cpu_init'. It would be nice, if someone could help here. Please read the readme file. Files are here: http://www.henrynestler.com/colinux/patches/devel/kernel-2.6.17/ -- Henry Nestler README: coLinux patch for kernel 2.6.17 =============================== WARNING! Patch is under development and properly not runable! files: quilt-2.6.17-*.tgz Multiple patch files, handled by quilt colinux-2.6.17-*.patch(.gz) Combined single patch file colinux-2.6.17-*.stat Output from diffstat config-2.6.17 Configuration skipped-2.6.12.diff These hunks are not copied - All patch-hunks from kernel 2.6.12 inserted into kernel 2.6.17 - Compiler runs clean for vmlinux and Modules. - coLinux would properly not run with this kernel. Have not tested it. - Please check many of 'TODO' in patch files. - Some things should do before starting: * arch/i386/kernel/cooperative.c: Linker error: Unresolved symbol 'per_cpu__cpu_gdt_table'. How should handle the variable 'per_cpu(cpu_gdt_table, cpu)' ? Have set it in same code as in cpu_init() does it. * Function co_early_cpu_init() I'm not full understand. Should 'gdt' allocated or copied from boot values (see cpu_init)? Is this right here to get it from 'alloc_bootmem_pages'? Is an access via 'gdt[GDT_ENTRY_TSS]' right there? * Check, that all access to variables '__pa' and '__va' are save for colinux. Have only copied all lines from old kernel, so I'm not shure about new handling with this variables. * CONFIG_HZ=1000 and CONFIG_HZ_1000 or CONFIG_HZ=100 and CONFIG_HZ_100 ? What is the right value? * Why is not "define HZ" under colinux, and "define USER_HZ" in other cases? * linux-2.6.17-source/fs/cofusefs/file.c: 'i_sem' was changed into 'i_mutex'. How to handle? 'FUSE_LARGE_READ' is temporaly not usable (returns ENOSYS). - arch/i386/kernel/timers/timer_cooperative.c: 'get_offset_cooperative()' returns a signed. Why need to calculate a negative value? The DIV should releace with a MUL, see real TSC. - cocd (serial) could be broken. 'flip' is not longer known. - Kernel config ISA (and all other bus types) is blocked by COOPERATIVE. Without ISA mostly all other devices are hide from config now. 2006-06-16 <Henry at BigFoot.de> |
From: Henry N. <Henry.Ne@Arcor.de> - 2006-07-24 11:04:05
|
Henry Nestler wrote: > have started a patch for kernel 2.6.17, is not runable. Need to change > some things in starup code for colinux 'co_early_cpu_init'. It would be > nice, if someone could help here. Please read the readme file. > > Files are here: > http://www.henrynestler.com/colinux/patches/devel/kernel-2.6.17/ Think, function 'co_early_cpu_init' is ok now. Colinux kernel is starting, but is crashing after the first 'printk' switches back from windows to linux. http://www.henrynestler.com/colinux/patches/devel/kernel-2.6.17/debug-20060723.txt shows the debug output. The 'printk' is the last, before it's crashing. The printk can be empty or filled with text, this made no difference: Every switch back from windows to linux crash the windows host. -- Henry Nestler |
From: Anders E. C \(KI/EAB\) <and...@er...> - 2006-07-24 13:12:13
|
Hi all, Working with Henry, I've taken a stab at moving the=20 kernel forward in a step-by-step manner and made some=20 progress. If we could get some more devel attention=20 to this effort, the chances of actually getting to=20 -current in a timely manner would grow significantly.=20 So, the more eyeballs the better! There are patches for 2.6.{13,14,15} at http://www.henrynestler.com/colinux/patches/devel/ Status: 2.6.13 Used for a couple of weeks with no issues. 2.6.14 Completed yesterday, and just BSODed on me with=20 a PAGE FAULT IN UNPAGED AREA message during an rsync run. 2.6.15 Completed today, but my gentoo userland doesn't=20 populate /dev/* at all with this kernel so the=20 boot process hangs at fsck / I'm mostly offline for the coming weeks, but if we=20 could get some developer attention and comments/fixes=20 to the list that would be much appreciated... /Anders |
From: Henry N. <Henry.Ne@Arcor.de> - 2006-07-25 09:03:45
|
Anders Eriksson C (KI/EAB) wrote: > Hi all, > > Working with Henry, I've taken a stab at moving the > kernel forward in a step-by-step manner and made some > progress. If we could get some more devel attention > to this effort, the chances of actually getting to > -current in a timely manner would grow significantly. > So, the more eyeballs the better! > > There are patches for 2.6.{13,14,15} at > http://www.henrynestler.com/colinux/patches/devel/ > > Status: > > 2.6.13 > Used for a couple of weeks with no issues. > > 2.6.14 > Completed yesterday, and just BSODed on me with > a PAGE FAULT IN UNPAGED AREA message during an rsync run. > > 2.6.15 > Completed today, but my gentoo userland doesn't > populate /dev/* at all with this kernel so the > boot process hangs at fsck / Here are coLinux binaries with your patches as devel-2.6.{13,14,15}-hn : http://www.henrynestler.com/colinux/testing/ The kernel configuration in this binaries was optimized for speed building. More modules we would enable after the kernel is usable. These builds are very fresh and not good tested. If you try thes binaries, please save all your work before. Im preffer shutdown and restart your windows, before you start new coLinux kernel. This clears all the windows disk caches, and minimized risk for losing datas form last opened files. Many thanks to Anders. -- Henry Nestler |
From: Sunil K. <de...@gm...> - 2006-07-26 18:38:08
|
I have used vmware to run colinux in it before. It works perfectly. if a crash trashes your vm, restore the vm image and you are good to go. On 7/24/06, Henry Nestler <Hen...@ar...> wrote: > > Anders Eriksson C (KI/EAB) wrote: > > Hi all, > > > > Working with Henry, I've taken a stab at moving the > > kernel forward in a step-by-step manner and made some > > progress. If we could get some more devel attention > > to this effort, the chances of actually getting to > > -current in a timely manner would grow significantly. > > So, the more eyeballs the better! > > > > There are patches for 2.6.{13,14,15} at > > http://www.henrynestler.com/colinux/patches/devel/ > > > > Status: > > > > 2.6.13 > > Used for a couple of weeks with no issues. > > > > 2.6.14 > > Completed yesterday, and just BSODed on me with > > a PAGE FAULT IN UNPAGED AREA message during an rsync run. > > > > 2.6.15 > > Completed today, but my gentoo userland doesn't > > populate /dev/* at all with this kernel so the > > boot process hangs at fsck / > > Here are coLinux binaries with your patches as devel-2.6.{13,14,15}-hn : > http://www.henrynestler.com/colinux/testing/ > > The kernel configuration in this binaries was optimized for speed > building. More modules we would enable after the kernel is usable. > > These builds are very fresh and not good tested. > If you try thes binaries, please save all your work before. Im preffer > shutdown and restart your windows, before you start new coLinux kernel. > This clears all the windows disk caches, and minimized risk for losing > datas form last opened files. > > Many thanks to Anders. > > -- > Henry Nestler > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > coLinux-devel mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-devel > |
From: Henry N. <Henry.Ne@Arcor.de> - 2006-07-28 22:10:38
|
Hello Sunil, Sunil Kumar wrote: > I have used vmware to run colinux in it before. It works perfectly. if a > crash trashes your vm, restore the vm image and you are good to go. Do you have installed a Windows in VMware, and run in this the coLinux? Is your VMware installed in native Linux or Windows? I have no VMware installed. An other question: Could you simulate NX and PAE in your VMware virtual machine to get the error point from this old bug? -- Henry Nestler |
From: Sunil K. <de...@gm...> - 2006-07-28 20:16:30
|
when I tried it last time, I ran colinux in vmware running windows VM inside linux host. I doubt if NX and PAE will make sense inside a VM but I will try it over the weekend and let you know. vmware server is free now, and I think you should try it. It is very good for destructive testing. On 7/27/06, Henry Nestler <Hen...@ar...> wrote: > > Hello Sunil, > > Sunil Kumar wrote: > > I have used vmware to run colinux in it before. It works perfectly. if a > > crash trashes your vm, restore the vm image and you are good to go. > > Do you have installed a Windows in VMware, and run in this the coLinux? > Is your VMware installed in native Linux or Windows? > > I have no VMware installed. > > An other question: > Could you simulate NX and PAE in your VMware virtual machine to get the > error point from this old bug? > > -- > Henry Nestler > |
From: <2...@pe...> - 2006-08-24 03:57:13
|
On Thu, 24 Aug 2006, Fr=E9d=E9ric L. W. Meunier wrote: > I ran that version you released for a week without any problems (I only= =20 > launched it once). Today, I installed 20060817, and when I launched it th= e=20 > computer rebooted after a few seconds. > > I didn't get a BSOD, even though I don't have "Automatically restart"=20 > enabled, but I have this in Event Viewer: > > The computer has rebooted from a bugcheck. The bugcheck was: 0x100000d1= =20 > (0xc0102570, 0x000000ff, 0x00000000, 0xc0102570). A dump was saved in:=20 > C:\WINDOWS\Minidump\Mini082406-01.dmp. > > I'm using XP Professional SP2 with all updates. Duh. I forgot to read your readme.txt. Anyway, you can add AMD Athlon XP 1700+ with 1Gb RAM (I only=20 use 256Mb for coLinux) to your results. --=20 How to contact me - http://www.pervalidus.net/contact.html |
From: Henry N. <Henry.Ne@Arcor.de> - 2006-08-24 09:28:23
|
Fr=E9d=E9ric L. W. Meunier wrote: > On Thu, 24 Aug 2006, Fr=E9d=E9ric L. W. Meunier wrote: >=20 >> I ran that version you released for a week without any problems (I=20 What build date? On the same machine with same settings? Without such crash? >> only launched it once). Today, I installed 20060817, and when I=20 >> launched it the computer rebooted after a few seconds. >> >> I didn't get a BSOD, even though I don't have "Automatically restart"=20 >> enabled, but I have this in Event Viewer: >> >> The computer has rebooted from a bugcheck. The bugcheck was:=20 >> 0x100000d1 (0xc0102570, 0x000000ff, 0x00000000, 0xc0102570). A dump=20 >> was saved in: C:\WINDOWS\Minidump\Mini082406-01.dmp. >> >> I'm using XP Professional SP2 with all updates. >=20 > Duh. I forgot to read your readme.txt. >=20 > Anyway, you can add AMD Athlon XP 1700+ with 1Gb RAM (I only use 256Mb=20 > for coLinux) to your results. Thanks. --=20 Henry Nestler |
From: <2...@pe...> - 2006-09-16 19:29:56
|
On Thu, 7 Sep 2006, Henry Nestler wrote: > The old workarrount (sep-disable-2.6.15.patch) was only for Intel cpu > types. This should fixed now for all cpu types in this build: > http://www.henrynestler.com/colinux/testing/devel-2.6.15-hn/20060906/ > > Please read the readme file. More history is in kernel source patches: > http://www.henrynestler.com/colinux/patches/devel/kernel-2.6.15/patches-2.6.15-20060906hn.tgz I've been running this version without any problems for 9 days, but today, while compiling a kernel with 'make -j4', I noticed the following: Sep 16 15:52:38 pervalidus kernel: general protection fault: 0000 [#1] Sep 16 15:52:38 pervalidus kernel: Modules linked in: Sep 16 15:52:38 pervalidus kernel: CPU: 0 Sep 16 15:52:38 pervalidus kernel: EIP: 0060:[<c0104b56>] Not tainted VLI Sep 16 15:52:38 pervalidus kernel: EFLAGS: 00010002 (2.6.15-co-0.7.1-hn17) Sep 16 15:52:38 pervalidus kernel: EIP is at math_state_restore+0x16/0x40 Sep 16 15:52:38 pervalidus kernel: eax: 8005003b ebx: c126b030 ecx: 00000000 edx: 0000007b Sep 16 15:52:38 pervalidus kernel: esi: c03a4000 edi: c312d520 ebp: c03a5ec8 esp: c03a5ec0 Sep 16 15:52:38 pervalidus kernel: ds: 007b es: 007b ss: 0068 Sep 16 15:52:38 pervalidus kernel: Process watchdog/0 (pid: 3, threadinfo=c03a4000 task=c126b030) Sep 16 15:52:38 pervalidus kernel: Stack: c126b1f0 c312d6e0 c03a5f14 c0103654 c126b1f0 00000000 c126b030 c312d6e0 Sep 16 15:52:38 pervalidus kernel: c312d520 c03a5f14 c7174000 0000007b 0000007b ffffffff c0101183 00000060 Sep 16 15:52:38 pervalidus kernel: 00010002 c126b030 c6e6daa0 c126b030 042c1d80 c7175fb4 c027a56c c03a5f54 Sep 16 15:52:38 pervalidus kernel: Call Trace: Sep 16 15:52:38 pervalidus kernel: [<c0103925>] show_stack+0x75/0x90 Sep 16 15:52:38 pervalidus kernel: [<c0103a78>] show_registers+0x118/0x190 Sep 16 15:52:38 pervalidus kernel: [<c0103c25>] die+0xb5/0x130 Sep 16 15:52:38 pervalidus kernel: [<c01043c0>] do_general_protection+0x150/0x170 Sep 16 15:52:38 pervalidus kernel: [<c01035ff>] error_code+0x4f/0x60 Sep 16 15:52:38 pervalidus kernel: [<c0103654>] device_not_available+0x24/0x29 Sep 16 15:52:38 pervalidus kernel: [<c027a56c>] schedule+0x31c/0x610 Sep 16 15:52:38 pervalidus kernel: Code: 89 c7 f3 a5 89 d1 83 e1 03 74 02 f3 a4 5a 5e 5f 5d c3 8d 76 00 55 89 e5 56 53 be 00 e0 ff ff 21 e6 8b 1e 0f 06 f6 43 0d 20 74 1a <0f> ae 8b 20 02 00 00 8b 5e 0c 83 cb 01 89 5e 0c 8d 65 f8 5b 5e Sep 16 15:52:47 pervalidus kernel: <3>BUG: soft lockup detected on CPU#0! Sep 16 15:52:47 pervalidus kernel: Sep 16 15:52:47 pervalidus kernel: Pid: 26134, comm: cc1 Sep 16 15:52:47 pervalidus kernel: EIP: 9de4:[<c02c2ba0>] CPU: 0 Sep 16 15:52:47 pervalidus kernel: EIP is at contig_page_data+0x260/0x554 Sep 16 15:52:47 pervalidus kernel: EFLAGS: c0133db4 Not tainted (2.6.15-co-0.7.1-hn17) Sep 16 15:52:47 pervalidus kernel: EAX: feaff000 EBX: 00000046 ECX: c3149dcc EDX: 00000615 Sep 16 15:52:47 pervalidus kernel: ESI: 00000000 EDI: 00000001 EBP: c010d26a DS: f4c0 ES: f250 Sep 16 15:52:47 pervalidus kernel: CR0: 8005003b CR2: 40405000 CR3: 07593000 CR4: 00000600 Sep 16 15:52:47 pervalidus kernel: [<c0100b85>] show_regs+0x105/0x130 Sep 16 15:52:47 pervalidus kernel: [<c012eadd>] softlockup_tick+0x4d/0x60 Sep 16 15:52:47 pervalidus kernel: [<c011da8a>] do_timer+0x3a/0xf0 Sep 16 15:52:47 pervalidus kernel: [<c0107032>] timer_interrupt+0x22/0x60 Sep 16 15:52:47 pervalidus kernel: [<c012ec05>] handle_IRQ_event+0x35/0x80 Sep 16 15:52:47 pervalidus kernel: [<c012ecac>] __do_IRQ+0x5c/0xb0 Sep 16 15:52:47 pervalidus kernel: [<c0104c2d>] do_IRQ+0x1d/0x30 Sep 16 15:52:47 pervalidus kernel: [<c010d135>] co_handle_jiffies+0x55/0x70 Sep 16 15:52:47 pervalidus kernel: [<c012f9b5>] co_callback+0x75/0x160 Sep 16 15:52:47 pervalidus kernel: [<c0107ae3>] proxy_interrupt_handler+0x53/0x60 Sep 16 15:52:47 pervalidus kernel: [<c0108a9b>] IRQ_proxy_0x53_interrupt+0x1b/0x30 Sep 16 15:52:47 pervalidus kernel: [<c0144e5e>] free_page_and_swap_cache+0x1e/0x40 Sep 16 15:52:47 pervalidus kernel: [<c013d5ff>] zap_pte_range+0x14f/0x220 Sep 16 15:52:47 pervalidus kernel: [<c013d767>] unmap_page_range+0x97/0x150 Sep 16 15:52:47 pervalidus kernel: [<c013d8ea>] unmap_vmas+0xca/0x1a0 Sep 16 15:52:47 pervalidus kernel: [<c0141c2e>] exit_mmap+0x4e/0xd0 Sep 16 15:52:47 pervalidus kernel: [<c0113ca3>] mmput+0x23/0x80 Sep 16 15:52:47 pervalidus kernel: [<c0117307>] exit_mm+0x67/0xe0 Sep 16 15:52:47 pervalidus kernel: [<c0117ca0>] do_exit+0xf0/0x370 Sep 16 15:52:47 pervalidus kernel: [<c0117f8d>] do_group_exit+0x2d/0x80 Sep 16 15:52:47 pervalidus kernel: [<c0117ff1>] sys_exit_group+0x11/0x20 Sep 16 15:52:47 pervalidus kernel: [<c0102629>] syscall_call+0x7/0xb I've no idea what it means or if it's related to coLinux. Nothing happened to coLinux, no crashes, kernel panic, just this in the log. -- How to contact me - http://www.pervalidus.net/contact.html |
From: Henry N. <Henry.Ne@Arcor.de> - 2006-08-01 07:53:31
Attachments:
sep-disable-2.6.15.patch
|
Thanks, Daniel for reporting this bug. Kernel 2.6.15 got a blue screen on WindowsXP with Intel P4 DRIVER_IRQL_NOT_LESS_OR_EQUAL *** STOP: 0x000000D1 (0xC01027D0,0x000000FF,0x00000000,0xC01027D0) >>> objdump -D vmlinux >>> c01027d0 <sysenter_entry>: <<<==== crash address ===== c01027d0: 8b a4 24 04 de ff ff mov 0xffffde04(%esp,1),%esp c01027d7 <sysenter_past_esp>: c01027d7: fb sti c01027d8: 6a 7b push $0x7b c01027da: 55 push %ebp <<< end <<< Source and binaries for Kernel 2.6.15 changed: http://www.henrynestler.com/colinux/testing/devel-2.6.15-hn/20060731/ -- Henry Nestler |
From: <2...@pe...> - 2006-08-24 03:53:47
|
I ran that version you released for a week without any problems (I only launched it once). Today, I installed 20060817, and when I launched it the computer rebooted after a few seconds. I didn't get a BSOD, even though I don't have "Automatically restart" enabled, but I have this in Event Viewer: The computer has rebooted from a bugcheck. The bugcheck was: 0x100000d1 (0xc0102570, 0x000000ff, 0x00000000, 0xc0102570). A dump was saved in: C:\WINDOWS\Minidump\Mini082406-01.dmp. I'm using XP Professional SP2 with all updates. On Mon, 31 Jul 2006, Henry Nestler wrote: > Thanks, > > Daniel for reporting this bug. > > Kernel 2.6.15 got a blue screen on WindowsXP with Intel P4 > DRIVER_IRQL_NOT_LESS_OR_EQUAL > *** STOP: 0x000000D1 (0xC01027D0,0x000000FF,0x00000000,0xC01027D0) > >>>> objdump -D vmlinux >>> > c01027d0 <sysenter_entry>: <<<==== crash address ===== > c01027d0: 8b a4 24 04 de ff ff mov 0xffffde04(%esp,1),%esp > > c01027d7 <sysenter_past_esp>: > c01027d7: fb sti > c01027d8: 6a 7b push $0x7b > c01027da: 55 push %ebp > <<< end <<< > > > Source and binaries for Kernel 2.6.15 changed: > http://www.henrynestler.com/colinux/testing/devel-2.6.15-hn/20060731/ -- How to contact me - http://www.pervalidus.net/contact.html |
From: daniele_dll <dan...@ya...> - 2006-08-24 15:28:30
|
Hi, is a lot of time that i don't write on this mailing-list, and i don't know if henry remember about me :) I'm not a kernel developer and nor a c/c++ coder, however i know some c/c++ programming and kernel mode programming but my work is relative to userspace windows applications and sometimes backend sites programming. I know that there is an attempt to implement a framebuffer support into co-linux but a lot of time i thinked to a possible alternative but i never had the time to propose it! The way in what a framebuffer work is simply but heavy for a computer, and when at this must be added another "layer" that must do other work, i think that the slow down is really serious! The most "simply" solution is to write a kernel/X module/driver that work as a bridge between co-linux and the console, something like X <-> Kernel <-> Linux.sys <-> Console, in this way, kernel can send operations to do speeding up a tons the drawing and reducing a lot the cpu usage, but hard and is necessary a lot of time! So i've thinked about a middle-way: why not to write an svga/vesa module for the kernel? if we can use the X SVGA/VESA driver and write a bridge for commands into the colinux kernel that acquire requests done by X and other SVGA/VESA apps and send it to the linux.sys that redirect them to the console (at the moment i don't know how the console works, but for example, in this case, using two pipes can be ok [one for recive commands by the windows kernel-mode driver linux.sys and one for sends mouse/keyboard operations to the kernel mode driver]) At the moment, but i repeat i didn't read the code of the current implementation of framebuffer, is necessary that colinux kernel write into the shared memory segment the image, after the console, that must take the shared memory and copy it into the fltk and after the SO must take it and write into the video card memory. Naturally all this work is killing for the system because is heavy and slower (but i repeat another time i didn't read the code of current implementation :)) So my proposal is this: - Write a bridge that "emulate" a SVGA/VESA module into the kernel - Write a SDL (for linux)/DirectX (for windows) console (in this way we can use hardware surfaces spedding up a lot drawing, infact the OS don't need to copy the memory used for the buffer of the drawed image into the video card memory because using hardware surfaces you do operations directly into the video memory) - To comunicate use a faster way [on windows can be that pipes are faster that shared memory] When something of this kind get completed, a lot of advantages come: - is possibile to "fork" the X driver to implement a "better" way of doing requests to speedup the drawing - is possibile to implement special commands in the SVGA/VESA driver (mantaining the compatibility with the standard) that speed up the X rendering What do you think about this proposal? It make sense? or it is a lot of junk? :D I undestand that this can seems another proposal by someone that don't undestand how much work there is behind something of this, but be sure that i understand (not all of this, but we can say 80% of the stuff) and i know well that alot of co-linux developers works and i'm angry when i think that there is a really intersteing project like this and i haven't the time to do more! (I work around 12/14 hours at day ^^) However you have done a great job boys!!!! Best Regards, Daniele PS: sorry for my horrible english :) Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com |
From: wang l. <lia...@gm...> - 2006-08-24 12:34:44
|
Hi Anders, You do a greak work, and it is more useful if you can give a document about how to do this work. 2006/7/24, Anders Eriksson C (KI/EAB) <and...@er...>: > > Hi all, > > Working with Henry, I've taken a stab at moving the > kernel forward in a step-by-step manner and made some > progress. If we could get some more devel attention > to this effort, the chances of actually getting to > -current in a timely manner would grow significantly. > So, the more eyeballs the better! > > There are patches for 2.6.{13,14,15} at > http://www.henrynestler.com/colinux/patches/devel/ > > Status: > > 2.6.13 > Used for a couple of weeks with no issues. > > 2.6.14 > Completed yesterday, and just BSODed on me with > a PAGE FAULT IN UNPAGED AREA message during an rsync run. > > 2.6.15 > Completed today, but my gentoo userland doesn't > populate /dev/* at all with this kernel so the > boot process hangs at fsck / > > I'm mostly offline for the coming weeks, but if we > could get some developer attention and comments/fixes > to the list that would be much appreciated... > > /Anders > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > coLinux-devel mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-devel > |
From: Anders E. C \(KI/EAB\) <and...@er...> - 2006-08-25 16:46:11
|
Hi Wang, =20 There're really nothing magical to it. =20 I took the big kernel diff and split it up in feature chunks and started to use quilt to manage them. (Henry uses quilt these days too..) =20 Then I've got myself a copy of git (the version management tool used by the kernel devels), and merge the colinux patch to each version resolving issues as they arise. Usin git means that you can pinpoint the exact commit to the kernel source which cause a problem for colinux, thus increasing the information you have available when cooking up changes. =20 Right now I'm addressing a problem in 2.6.16-rc4 with GDT handling, and git-isect has identified this commit as the thing that causes w2k to reboot immediately: =20 2b932f6cf052920fb3a6281499e08209b08f5086 is first bad commit commit 2b932f6cf052920fb3a6281499e08209b08f5086 Author: James Bottomley <James.Bottomley@SteelEye.com> Date: Fri Feb 24 13:04:14 2006 -0800 =20 [PATCH] x86: fix broken SMP boot sequence =20 Recent GDT changes broke the SMP boot sequence if the booting CPU is numbered anything other than zero. There's also a subtle source of error in that the boot time CPU now uses cpu_gdt_table (which is actually the GDT for booting CPUs in head.S). This patch fixes both problems by making GDT descriptors themselves allocated from a per_cpu area and switching to them in cpu_init(), which now means that cpu_gdt_table is exclusively used for booting CPUs again. =20 Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com> Cc: Zachary Amsden <za...@vm...> Cc: Matt Tolentino <met...@sn...> Signed-off-by: Andrew Morton <ak...@os...> Signed-off-by: Linus Torvalds <tor...@os...> =20 :040000 040000 df9714527dfeb229d1d476adff92a6d5124d8cc6 223e49e8300b3f972713d10ea1c97c94cb7bfd76 M arch :040000 040000 b3a802e3dba3091e446a472b6e0a7393560327ec 14b42476ee5714fa1968ed192a1d1c9bd70e2124 M include =20 =20 That particular commit, in patch form, looks like: =20 ~/src/colinux-devel/build/linux-git $ git-diff-tree -p 2b932f6cf052920fb3a6281499e08209b08f5086=20 2b932f6cf052920fb3a6281499e08209b08f5086 diff --git a/arch/i386/kernel/cpu/common.c b/arch/i386/kernel/cpu/common.c index 7eb9213..4ecd4b3 100644 --- a/arch/i386/kernel/cpu/common.c +++ b/arch/i386/kernel/cpu/common.c @@ -4,6 +4,7 @@ #include <linux/delay.h> #include <linux/smp.h> #include <linux/module.h> #include <linux/percpu.h> +#include <linux/bootmem.h> #include <asm/semaphore.h> #include <asm/processor.h> #include <asm/i387.h> @@ -18,6 +19,9 @@ #endif =20 #include "cpu.h" =20 +DEFINE_PER_CPU(struct Xgt_desc_struct, cpu_gdt_descr); +EXPORT_PER_CPU_SYMBOL(cpu_gdt_descr); + DEFINE_PER_CPU(unsigned char, cpu_16bit_stack[CPU_16BIT_STACK_SIZE]); EXPORT_PER_CPU_SYMBOL(cpu_16bit_stack); =20 @@ -571,8 +575,9 @@ void __devinit cpu_init(void) int cpu =3D smp_processor_id(); struct tss_struct * t =3D &per_cpu(init_tss, cpu); struct thread_struct *thread =3D ¤t->thread; - struct desc_struct *gdt =3D get_cpu_gdt_table(cpu); + struct desc_struct *gdt; __u32 stk16_off =3D (__u32)&per_cpu(cpu_16bit_stack, cpu); + struct Xgt_desc_struct *cpu_gdt_descr =3D = &per_cpu(cpu_gdt_descr, cpu); =20 if (cpu_test_and_set(cpu, cpu_initialized)) { printk(KERN_WARNING "CPU#%d already initialized!\n", cpu); @@ -590,6 +595,25 @@ void __devinit cpu_init(void) } =20 /* + * This is a horrible hack to allocate the GDT. The problem + * is that cpu_init() is called really early for the boot CPU + * (and hence needs bootmem) but much later for the secondary + * CPUs, when bootmem will have gone away + */ + if (NODE_DATA(0)->bdata->node_bootmem_map) { + gdt =3D (struct desc_struct *)alloc_bootmem_pages(PAGE_SIZE); + /* alloc_bootmem_pages panics on failure, so no check */ + memset(gdt, 0, PAGE_SIZE); + } else { + gdt =3D (struct desc_struct = *)get_zeroed_page(GFP_KERNEL); + if (unlikely(!gdt)) { + printk(KERN_CRIT "CPU%d failed to allocate GDT\n", cpu); + for (;;) + local_irq_enable(); + } + } + + /* * Initialize the per-CPU GDT with the boot GDT, * and set up the GDT descriptor: */ @@ -601,10 +625,10 @@ void __devinit cpu_init(void) ((((__u64)stk16_off) << 32) & 0xff00000000000000ULL) | (CPU_16BIT_STACK_SIZE - 1); =20 - cpu_gdt_descr[cpu].size =3D GDT_SIZE - 1; - cpu_gdt_descr[cpu].address =3D (unsigned long)gdt; + cpu_gdt_descr->size =3D GDT_SIZE - 1; + cpu_gdt_descr->address =3D (unsigned long)gdt; =20 - load_gdt(&cpu_gdt_descr[cpu]); + load_gdt(cpu_gdt_descr); load_idt(&idt_descr); =20 /* diff --git a/arch/i386/kernel/efi.c b/arch/i386/kernel/efi.c index ecad519..e3e42fd 100644 --- a/arch/i386/kernel/efi.c +++ b/arch/i386/kernel/efi.c @@ -103,17 +103,19 @@ static void efi_call_phys_prelog(void) */ local_flush_tlb(); =20 - cpu_gdt_descr[0].address =3D __pa(cpu_gdt_descr[0].address); - load_gdt((struct Xgt_desc_struct *) __pa(&cpu_gdt_descr[0])); + per_cpu(cpu_gdt_descr, 0).address =3D + __pa(per_cpu(cpu_gdt_descr, 0).address); + load_gdt((struct Xgt_desc_struct *)__pa(&per_cpu(cpu_gdt_descr, 0))); } =20 static void efi_call_phys_epilog(void) { unsigned long cr4; =20 - cpu_gdt_descr[0].address =3D - (unsigned long) __va(cpu_gdt_descr[0].address); - load_gdt(&cpu_gdt_descr[0]); + per_cpu(cpu_gdt_descr, 0).address =3D + (unsigned long)__va(per_cpu(cpu_gdt_descr, 0).address); + load_gdt((struct Xgt_desc_struct *)__va(&per_cpu(cpu_gdt_descr, 0))); + cr4 =3D read_cr4(); =20 if (cr4 & X86_CR4_PSE) { diff --git a/arch/i386/kernel/head.S b/arch/i386/kernel/head.S index 2bee649..e0b7c63 100644 --- a/arch/i386/kernel/head.S +++ b/arch/i386/kernel/head.S @@ -534,5 +534,3 @@ ENTRY(cpu_gdt_table) .quad 0x0000000000000000 /* 0xf0 - unused */ .quad 0x0000000000000000 /* 0xf8 - GDT entry 31: double-fault TSS */ =20 - /* Be sure this is zeroed to avoid false validations in Xen */ - .fill PAGE_SIZE_asm / 8 - GDT_ENTRIES,8,0 diff --git a/arch/i386/kernel/i386_ksyms.c b/arch/i386/kernel/i386_ksyms.c index 3999bec..0553250 100644 --- a/arch/i386/kernel/i386_ksyms.c +++ b/arch/i386/kernel/i386_ksyms.c @@ -3,8 +3,6 @@ #include <linux/module.h> #include <asm/checksum.h> #include <asm/desc.h> =20 -EXPORT_SYMBOL_GPL(cpu_gdt_descr); - EXPORT_SYMBOL(__down_failed); EXPORT_SYMBOL(__down_failed_interruptible); EXPORT_SYMBOL(__down_failed_trylock); diff --git a/arch/i386/kernel/smpboot.c b/arch/i386/kernel/smpboot.c index fb00ab7..eba7f53 100644 --- a/arch/i386/kernel/smpboot.c +++ b/arch/i386/kernel/smpboot.c @@ -898,12 +898,6 @@ static int __devinit do_boot_cpu(int api unsigned long start_eip; unsigned short nmi_high =3D 0, nmi_low =3D 0; =20 - if (!cpu_gdt_descr[cpu].address && - !(cpu_gdt_descr[cpu].address =3D = get_zeroed_page(GFP_KERNEL))) { - printk("Failed to allocate GDT for CPU %d\n", cpu); - return 1; - } - ++cpucount; =20 /* diff --git a/include/asm-i386/desc.h b/include/asm-i386/desc.h index 494e73b..89b8b82 100644 --- a/include/asm-i386/desc.h +++ b/include/asm-i386/desc.h @@ -24,11 +24,13 @@ struct Xgt_desc_struct { unsigned short pad; } __attribute__ ((packed)); =20 -extern struct Xgt_desc_struct idt_descr, cpu_gdt_descr[NR_CPUS]; +extern struct Xgt_desc_struct idt_descr; +DECLARE_PER_CPU(struct Xgt_desc_struct, cpu_gdt_descr); + =20 static inline struct desc_struct *get_cpu_gdt_table(unsigned int cpu) { - return ((struct desc_struct *)cpu_gdt_descr[cpu].address); + return (struct desc_struct *)per_cpu(cpu_gdt_descr, cpu).address; } =20 #define load_TR_desc() __asm__ __volatile__("ltr %w0"::"q" (GDT_ENTRY_TSS*8)) =20 So, now I'm considering what on earth happened with the cpu_gdt_descr stuff, and how we can get around it. I still don't have a grip on all the memory handling stuff, and I was planning on getting clued up on that after we got to -current. =20 Ideas? =20 Cheers, /Anders =20 ________________________________ From: wang lianwei [mailto:lia...@gm...]=20 Sent: den 24 augusti 2006 14:34 To: Anders Eriksson C (KI/EAB) Cc: Cooperative Linux Development; Henry Nestler Subject: Re: [coLinux-devel] 1st take at 2.6.{13,14,15} =09 =09 Hi Anders, =20 You do a greak work, and it is more useful if you can give a document about how to do this work.=20 =09 =20 2006/7/24, Anders Eriksson C (KI/EAB) <and...@er...>:=20 Hi all, =09 Working with Henry, I've taken a stab at moving the kernel forward in a step-by-step manner and made some=20 progress. If we could get some more devel attention to this effort, the chances of actually getting to -current in a timely manner would grow significantly. So, the more eyeballs the better! =09 There are patches for 2.6.{13,14,15} at http://www.henrynestler.com/colinux/patches/devel/ =09 Status: =09 2.6.13 Used for a couple of weeks with no issues. =09 2.6.14=20 Completed yesterday, and just BSODed on me with a PAGE FAULT IN UNPAGED AREA message during an rsync run. =09 2.6.15 Completed today, but my gentoo userland doesn't populate /dev/* at all with this kernel so the=20 boot process hangs at fsck / =09 I'm mostly offline for the coming weeks, but if we could get some developer attention and comments/fixes to the list that would be much appreciated... =09 /Anders =09 =09 ------------------------------------------------------------------------ -=20 Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash =09 http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDE V _______________________________________________ coLinux-devel mailing list coL...@li... =09 https://lists.sourceforge.net/lists/listinfo/colinux-devel =09 |
From: Henry N. <Henry.Ne@Arcor.de> - 2006-08-25 17:08:12
|
Hello Anders, I would also join into git. Can I start with selectable revision, without *all* the older version? Do you have links with "getting started git for kernel"? -- Henry Nestler |
From: Anders E. C \(KI/EAB\) <and...@er...> - 2006-08-25 17:46:30
|
Hi Henry,=20 I tend to peek at these at times: http://www.kernel.org/pub/software/scm/git/docs/core-tutorial.html http://linux.yyz.us/git-howto.html When you start with git, you effectively go "get 2.6", so you get each commit from the beginning of time (more or less). You only have to do this once though (my 'pack' directory is 288 MB). The definitive upshot is that you get to see _every_ patch committed to the kernel tree. Well worth it. After bootstrapping, I use e.g. git reset --hard v2.6.15 to get to that version. Then quilt push ... <fixup problems....Something wrong> git bisect start git bisect good v2.6.14 git bisect bad v2.6.15 .... and get to the offending commit. Hth, /Anders > -----Original Message----- > From: Henry Nestler [mailto:Henry.Ne@Arcor.de]=20 > Sent: den 25 augusti 2006 19:09 > To: Anders Eriksson C (KI/EAB) > Cc: Cooperative Linux Development > Subject: Re: [coLinux-devel] 1st take at 2.6.{13,14,15} >=20 > Hello Anders, >=20 > I would also join into git. Can I start with selectable revision,=20 > without *all* the older version? Do you have links with "getting=20 > started git for kernel"? >=20 > --=20 > Henry Nestler >=20 |
From: Henry N. <Henry.Ne@Arcor.de> - 2006-08-25 20:21:26
|
Thanks hello Anders, thanks. > I tend to peek at these at times: > http://www.kernel.org/pub/software/scm/git/docs/core-tutorial.html > http://linux.yyz.us/git-howto.html Don't work, the latest git snapshot give that error "'clone' command not found". They changed the command interface into: git-clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6.git The latest snapshot is not usable, it's breaking near the end with "git-fetch-pack: unable to read from git-index-pack". I'm got the full kernel source with git version 1.4.2 done. It's using 409MB on my disk. -- Henry Nestler |
From: Henry N. <Henry.Ne@Arcor.de> - 2006-09-07 08:16:47
|
Fr=E9d=E9ric L. W. Meunier wrote: > On Thu, 24 Aug 2006, Fr=E9d=E9ric L. W. Meunier wrote: >=20 >> I ran that version you released for a week without any problems (I=20 >> only launched it once). Today, I installed 20060817, and when I=20 >> launched it the computer rebooted after a few seconds. >> >> I didn't get a BSOD, even though I don't have "Automatically restart"=20 >> enabled, but I have this in Event Viewer: >> >> The computer has rebooted from a bugcheck. The bugcheck was:=20 >> 0x100000d1 (0xc0102570, 0x000000ff, 0x00000000, 0xc0102570). A dump=20 >> was saved in: C:\WINDOWS\Minidump\Mini082406-01.dmp. >> >> I'm using XP Professional SP2 with all updates. >=20 > Duh. I forgot to read your readme.txt. The old workarrount (sep-disable-2.6.15.patch) was only for Intel cpu=20 types. This should fixed now for all cpu types in this build: http://www.henrynestler.com/colinux/testing/devel-2.6.15-hn/20060906/ Please read the readme file. More history is in kernel source patches: http://www.henrynestler.com/colinux/patches/devel/kernel-2.6.15/patches-2= .6.15-20060906hn.tgz --=20 Henry Nestler |
From: Henry N. <Henry.Ne@Arcor.de> - 2006-09-16 20:35:19
|
Hello Frederic, Fr=E9d=E9ric L. W. Meunier wrote: > On Thu, 7 Sep 2006, Henry Nestler wrote: >=20 >> The old workarrount (sep-disable-2.6.15.patch) was only for Intel cpu >> types. This should fixed now for all cpu types in this build: >> http://www.henrynestler.com/colinux/testing/devel-2.6.15-hn/20060906/ >> >> Please read the readme file. More history is in kernel source patches= : >> http://www.henrynestler.com/colinux/patches/devel/kernel-2.6.15/patche= s-2.6.15-20060906hn.tgz >=20 > I've been running this version without any problems for 9 days,=20 > but today, while compiling a kernel with 'make -j4', I noticed=20 > the following: >=20 > Sep 16 15:52:38 pervalidus kernel: EIP: 0060:[<c0104b56>] Not tai= nted VLI > Sep 16 15:52:38 pervalidus kernel: EFLAGS: 00010002 (2.6.15-co-0.7.1-= hn17)=20 > Sep 16 15:52:38 pervalidus kernel: EIP is at math_state_restore+0x16/0x= 40 > Sep 16 15:52:38 pervalidus kernel: eax: 8005003b ebx: c126b030 ecx:= 00000000 edx: 0000007b > Sep 16 15:52:38 pervalidus kernel: esi: c03a4000 edi: c312d520 ebp:= c03a5ec8 esp: c03a5ec0 > Sep 16 15:52:38 pervalidus kernel: ds: 007b es: 007b ss: 0068 > Sep 16 15:52:38 pervalidus kernel: Process watchdog/0 (pid: 3, threadin= fo=3Dc03a4000 task=3Dc126b030) > ... > Sep 16 15:52:47 pervalidus kernel: <3>BUG: soft lockup detected on CPU= #0! > ... >=20 > I've no idea what it means or if it's related to coLinux.=20 > Nothing happened to coLinux, no crashes, kernel panic, just=20 > this in the log. >=20 oh, a bug on coprocessor handling? math_state_restore and device_not_available are called for floating=20 point errors. "BUG: soft lockup detected on CPU#" if I understand the kernel right, kernel detects a non running watchdog.=20 Think, followed by the other error. Please give a output from /proc/cpuinfo the 'flags'. It could be=20 interesting, if your CPU supports fxsave or fnsave. I think the watchdog process tryed to resotore the coprocessor, and that=20 failed. The kernel under coLinux typicaly have the CPU not for long=20 time, if you have heavy disk transfers. This could be a problem with=20 the watchdog task. Or it's a general race condition under coLinux. I=20 have no idea, what it is exactly. Thanks for the log output. --=20 Henry |
From: <2...@pe...> - 2006-09-16 23:14:36
|
On Sat, 16 Sep 2006, Henry Nestler wrote: > Hello Frederic, > > Fr=E9d=E9ric L. W. Meunier wrote: >> On Thu, 7 Sep 2006, Henry Nestler wrote: >>=20 >>> The old workarrount (sep-disable-2.6.15.patch) was only for Intel cpu >>> types. This should fixed now for all cpu types in this build: >>> http://www.henrynestler.com/colinux/testing/devel-2.6.15-hn/20060906/ >>>=20 >>> Please read the readme file. More history is in kernel source patches: >>> http://www.henrynestler.com/colinux/patches/devel/kernel-2.6.15/patches= -2.6.15-20060906hn.tgz >>=20 >> I've been running this version without any problems for 9 days, but toda= y,=20 >> while compiling a kernel with 'make -j4', I noticed the following: >>=20 >> Sep 16 15:52:38 pervalidus kernel: EIP: 0060:[<c0104b56>] Not tain= ted=20 >> VLI >> Sep 16 15:52:38 pervalidus kernel: EFLAGS: 00010002=20 >> (2.6.15-co-0.7.1-hn17) Sep 16 15:52:38 pervalidus kernel: EIP is at=20 >> math_state_restore+0x16/0x40 >> Sep 16 15:52:38 pervalidus kernel: eax: 8005003b ebx: c126b030 ecx:= =20 >> 00000000 edx: 0000007b >> Sep 16 15:52:38 pervalidus kernel: esi: c03a4000 edi: c312d520 ebp:= =20 >> c03a5ec8 esp: c03a5ec0 >> Sep 16 15:52:38 pervalidus kernel: ds: 007b es: 007b ss: 0068 >> Sep 16 15:52:38 pervalidus kernel: Process watchdog/0 (pid: 3,=20 >> threadinfo=3Dc03a4000 task=3Dc126b030) >> ... >> Sep 16 15:52:47 pervalidus kernel: <3>BUG: soft lockup detected on CPU#= 0! >> ... >>=20 >> I've no idea what it means or if it's related to coLinux. Nothing happen= ed=20 >> to coLinux, no crashes, kernel panic, just this in the log. >>=20 > > oh, a bug on coprocessor handling? > math_state_restore and device_not_available are called for floating point= =20 > errors. > > "BUG: soft lockup detected on CPU#" > if I understand the kernel right, kernel detects a non running watchdog.= =20 > Think, followed by the other error. > > Please give a output from /proc/cpuinfo the 'flags'. It could be=20 > interesting, if your CPU supports fxsave or fnsave. > > I think the watchdog process tryed to resotore the coprocessor, and that= =20 > failed. The kernel under coLinux typicaly have the CPU not for long time= , if=20 > you have heavy disk transfers. This could be a problem with the watchdog= =20 > task. Or it's a general race condition under coLinux. I have no idea, w= hat=20 > it is exactly. > > Thanks for the log output. processor=09: 0 vendor_id=09: AuthenticAMD cpu family=09: 6 model=09=09: 8 model name=09: AMD Athlon(tm) XP 1700+ stepping=09: 1 cpu MHz=09=09: 0.000 cache size=09: 256 KB fdiv_bug=09: no hlt_bug=09=09: no f00f_bug=09: no coma_bug=09: no fpu=09=09: yes fpu_exception=09: yes cpuid level=09: 1 wp=09=09: yes flags=09=09: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat = pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow bogomips=09: 730.72 --=20 How to contact me - http://www.pervalidus.net/contact.html |