Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
You can subscribe to this list here.
1999 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(15) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2000 |
Jan
(6) |
Feb
(1) |
Mar
(39) |
Apr
(13) |
May
(24) |
Jun
(11) |
Jul
(23) |
Aug
(85) |
Sep
(12) |
Oct
(103) |
Nov
(79) |
Dec
(112) |
2001 |
Jan
(52) |
Feb
(82) |
Mar
(84) |
Apr
(65) |
May
(105) |
Jun
(188) |
Jul
(174) |
Aug
(182) |
Sep
(103) |
Oct
(137) |
Nov
(143) |
Dec
(98) |
2002 |
Jan
(258) |
Feb
(236) |
Mar
(386) |
Apr
(307) |
May
(238) |
Jun
(170) |
Jul
(252) |
Aug
(230) |
Sep
(278) |
Oct
(394) |
Nov
(336) |
Dec
(194) |
2003 |
Jan
(290) |
Feb
(182) |
Mar
(175) |
Apr
(220) |
May
(209) |
Jun
(286) |
Jul
(279) |
Aug
(164) |
Sep
(208) |
Oct
(324) |
Nov
(204) |
Dec
(380) |
2004 |
Jan
(344) |
Feb
(332) |
Mar
(395) |
Apr
(357) |
May
(349) |
Jun
(352) |
Jul
(279) |
Aug
(269) |
Sep
(374) |
Oct
(442) |
Nov
(428) |
Dec
(253) |
2005 |
Jan
(225) |
Feb
(219) |
Mar
(245) |
Apr
(249) |
May
(203) |
Jun
(157) |
Jul
(171) |
Aug
(194) |
Sep
(200) |
Oct
(232) |
Nov
(190) |
Dec
(195) |
2006 |
Jan
(158) |
Feb
(190) |
Mar
(235) |
Apr
(161) |
May
(134) |
Jun
(169) |
Jul
(117) |
Aug
(161) |
Sep
(170) |
Oct
(297) |
Nov
(230) |
Dec
(205) |
2007 |
Jan
(197) |
Feb
(132) |
Mar
(151) |
Apr
(97) |
May
(109) |
Jun
(99) |
Jul
(57) |
Aug
(110) |
Sep
(56) |
Oct
(119) |
Nov
(39) |
Dec
(45) |
2008 |
Jan
(101) |
Feb
(116) |
Mar
(141) |
Apr
(98) |
May
(133) |
Jun
(61) |
Jul
(43) |
Aug
(76) |
Sep
(20) |
Oct
(32) |
Nov
(22) |
Dec
(41) |
2009 |
Jan
(35) |
Feb
(15) |
Mar
(18) |
Apr
(13) |
May
(13) |
Jun
(26) |
Jul
(12) |
Aug
(32) |
Sep
(21) |
Oct
(41) |
Nov
(35) |
Dec
(12) |
2010 |
Jan
(3) |
Feb
(35) |
Mar
(28) |
Apr
(20) |
May
(5) |
Jun
(14) |
Jul
(6) |
Aug
(8) |
Sep
(20) |
Oct
(20) |
Nov
(10) |
Dec
(12) |
2011 |
Jan
(14) |
Feb
(10) |
Mar
(14) |
Apr
(14) |
May
(13) |
Jun
(43) |
Jul
(13) |
Aug
(50) |
Sep
(30) |
Oct
(23) |
Nov
(15) |
Dec
(49) |
2012 |
Jan
(15) |
Feb
(28) |
Mar
(7) |
Apr
|
May
(12) |
Jun
(13) |
Jul
(28) |
Aug
(11) |
Sep
(19) |
Oct
(27) |
Nov
(5) |
Dec
(25) |
2013 |
Jan
(18) |
Feb
(19) |
Mar
(56) |
Apr
(26) |
May
(38) |
Jun
(24) |
Jul
(42) |
Aug
(24) |
Sep
(4) |
Oct
(3) |
Nov
(18) |
Dec
(4) |
2014 |
Jan
(10) |
Feb
(9) |
Mar
(3) |
Apr
|
May
(12) |
Jun
(34) |
Jul
(8) |
Aug
(18) |
Sep
(3) |
Oct
(27) |
Nov
(2) |
Dec
(1) |
2015 |
Jan
|
Feb
(10) |
Mar
(49) |
Apr
(2) |
May
(4) |
Jun
(7) |
Jul
(1) |
Aug
(17) |
Sep
(7) |
Oct
(35) |
Nov
(40) |
Dec
(4) |
2016 |
Jan
(9) |
Feb
|
Mar
(6) |
Apr
|
May
(10) |
Jun
(2) |
Jul
|
Aug
|
Sep
(5) |
Oct
|
Nov
|
Dec
(1) |
2017 |
Jan
(2) |
Feb
(4) |
Mar
(1) |
Apr
(4) |
May
(31) |
Jun
(9) |
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(2) |
2018 |
Jan
|
Feb
|
Mar
(1) |
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
1
(4) |
2
(7) |
3
(4) |
4
(7) |
5
(2) |
6
(11) |
7
(5) |
8
(10) |
9
(5) |
10
(14) |
11
(5) |
12
(4) |
13
(8) |
14
(6) |
15
(6) |
16
(15) |
17
(7) |
18
(3) |
19
(4) |
20
(12) |
21
(3) |
22
(9) |
23
(19) |
24
(16) |
25
(3) |
26
(3) |
27
(2) |
28
(1) |
29
|
30
(2) |
31
(6) |
|
|
|
|
From: Jan Evert van Grootheest <j.e.van.grootheest@hc...> - 2005-05-08 20:12:15
|
Hi, One UML instance I stopped got this in its log (screen is a useful thing...). I don't understand what's going on, but I thought I'd report it, hoping it allows you to improbe UML. By the way, this is self compiled from vanilla 2.6.11.6. I think I cannot provide the kernel configuration because the disk it was compiled on crashed. But I can tell you that it is a monolithic kernel, no module support. Also, this UML (single CPU) has 58M assigned to it on a 128M host (dual PII, debian testing). Thanks, Jan Evert PS: I'm not subscribed Stopping apt-proxy [wait 1 2 3Kernel panic - not syncing: Kernel mode fault at addr 0x8, ip 0xa001fe59 EIP: 0073:[<a001fe59>] CPU: 0 Not tainted ESP: 007b:a1b237bc EFLAGS: 00010292 Not tainted EAX: 00000008 EBX: a091d000 ECX: a1b237eb EDX: 00000008 ESI: a0926540 EDI: a142c2e8 EBP: a1b237d4 DS: 007b ES: 007b Call Trace: a1b23330: [<a00482ad>] notifier_call_chain+0x2d/0x50 a1b23350: [<a00362d2>] panic+0x72/0x120 a1b23364: [<a001fe59>] chan_window_size+0x9/0x50 a1b23370: [<a00172b1>] segv+0x241/0x280 a1b2337c: [<a001fe59>] chan_window_size+0x9/0x50 a1b233e0: [<a0015322>] change_signals+0x62/0x90 a1b23460: [<a0017695>] segv_handler+0x175/0x230 a1b23468: [<a001fe59>] chan_window_size+0x9/0x50 a1b23490: [<a001b731>] sig_handler_common_tt+0x91/0x110 a1b2349c: [<a00131d0>] copy_to_user_proc+0x0/0x50 a1b234d0: [<a002ccf2>] sig_handler+0x22/0x40 a1b234e0: [<a0151d28>] __restore+0x0/0x8 a1b23520: [<a001fe59>] chan_window_size+0x9/0x50 a1b23544: [<a0151e54>] sigemptyset+0x24/0x40 a1b23558: [<a00154d1>] set_signals+0x81/0x130 a1b23614: [<a0151e54>] sigemptyset+0x24/0x40 a1b2362c: [<a0169dab>] tcgetattr+0x6b/0xa0 a1b23658: [<a002bf44>] file_io+0x24/0x90 a1b23678: [<a002c021>] os_write_file+0x31/0x40 a1b23688: [<a0169050>] __libc_write+0x0/0x60 a1b2368c: [<a00131d0>] copy_to_user_proc+0x0/0x50 a1b23698: [<a00288cb>] do_ubd_request+0x6b/0xc0 a1b236f4: [<a0151e54>] sigemptyset+0x24/0x40 a1b23708: [<a0015322>] change_signals+0x62/0x90 a1b23718: [<a0027474>] ubd_handler+0x124/0x140 a1b23778: [<a002bf44>] file_io+0x24/0x90 a1b23798: [<a002bfe1>] os_read_file+0x31/0x40 a1b237a8: [<a0168ff0>] __libc_read+0x0/0x60 a1b237ac: [<a0013220>] copy_from_user_proc+0x0/0x50 a1b237d8: [<a00219ac>] winch_interrupt+0x5c/0xd0 a1b237f8: [<a0056223>] handle_IRQ_event+0x33/0x80 a1b23828: [<a005631b>] __do_IRQ+0xab/0xf0 a1b23840: [<a00154d1>] set_signals+0x81/0x130 a1b23858: [<a000fd30>] do_IRQ+0x30/0x40 a1b23868: [<a000feca>] sigio_handler+0xda/0x140 a1b23888: [<a001b731>] sig_handler_common_tt+0x91/0x110 a1b238c8: [<a002ccf2>] sig_handler+0x22/0x40 a1b238d8: [<a0151d28>] __restore+0x0/0x8 a1b23918: [<a0151d82>] sigprocmask+0x22/0x50 a1b23980: [<a002bf44>] file_io+0x24/0x90 a1b239a0: [<a002ca70>] os_kill_process+0x20/0x70 a1b239b0: [<a0169050>] __libc_write+0x0/0x60 a1b239c0: [<a0019433>] switch_to_tt+0x203/0x230 a1b23a00: [<a01969d5>] schedule+0x2d5/0x4f0 a1b23a70: [<a00391a8>] do_exit+0x188/0x350 a1b23ac0: [<a003940d>] do_group_exit+0x4d/0xf0 a1b23b00: [<a00464bf>] get_signal_to_deliver+0x26f/0x3f0 a1b23b3c: [<a0151e54>] sigemptyset+0x24/0x40 a1b23b50: [<a00154d1>] set_signals+0x81/0x130 a1b23b80: [<a0015322>] change_signals+0x62/0x90 a1b23bc0: [<a0015322>] change_signals+0x62/0x90 a1b23c60: [<a0015382>] unblock_signals+0x12/0x20 a1b23c70: [<a00329e7>] finish_task_switch+0x27/0x70 a1b23c90: [<a0032a4a>] schedule_tail+0x1a/0x190 a1b23cb0: [<a001aab1>] force_flush_all_tt+0x71/0x80 a1b23cd0: [<a0019853>] finish_fork_handler+0x163/0x170 a1b23d20: [<a0151d28>] __restore+0x0/0x8 |
From: Dick Middleton <gmane@li...> - 2005-05-08 19:20:19
|
Blaisorblade wrote: > On Saturday 07 May 2005 21:24, Dick Middleton wrote: > >>Anybody got a patch for host skas which works for the Debian 2.6.11 >>kernel source? The 2,6,10 patch fails with 2.6.11. > > Yes, the 2.6.10 patch fails even with vanilla 2.6.11. Try the one for vanilla > 2.6.11, no? Scrub last message (slight misunderstanding) - no I've not tried plain vanilla kernel yet. Dick |
From: Antoine Martin <antoine@na...> - 2005-05-08 17:10:55
|
> > Also, will there be a performance benefit from running uml 32bit guest on a > > 64bit host (now or planned?) > Difficult question... the host OS will anyway run faster and that will benefit > a bit UML, but I don't know how much that is. However, for now you have the > big disadvantage that SKAS does not run on x86-64 hosts, so you loose the > possibility to run in SKAS mode. Without skas, there is no point in having a x86-64 host, the TT performance is quite bad compared to a (even slower) x86 host with skas. skas0 looks promising, but at the moment it locks up hard on x86_64. Antoine |
From: Antoine Martin <antoine@na...> - 2005-05-08 17:06:25
|
I can't figure out how to use the pcap transport within a working bridged environment: do I need a dedicated interface on the host to attach to or can I reuse an interface already bound to a bridge? I've got 'eth0 up promisc' on the host, attached to a bridge, I want to start a UML instance with pcap transport to have access to all the packets on the bridge, so I thought I would do: eth0=pcap,eth0,promisc But the interface does not show up in the guest, am I missing something or is there another way of achieving the same thing? I can attach a normal tun/tap promiscuous interface to the bridge but that is no use, it will not get all packets as the bridge will discard any packets not destined to its mac address. Thanks Antoine |
From: Blaisorblade <blaisorblade@ya...> - 2005-05-08 16:58:21
|
On Sunday 08 May 2005 00:48, Chas Wareing wrote: > Good Afternoon Blaisorblade -- > > Wanted to run something quick past you - > > Can one compile a 32bit guest kernel on a 64bit host using SKAS/SYSEMU? > Special options? Something like SUBARCH=i386 CFLAGS=-m32 LDFLAGS=-m32 should more or less do the job... However I'm not sure of this, maybe some more tricks are needed. > Here is the error during "make ARCH=um" > gcc -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing > -fno-common -ffreestanding -O2 -fno-omit-frame-pointer -g -U__x86_64__ > -fno-builtin -D__arch_um__ -DSUBARCH=\"x86_64\" -Iarch/um/include > -I/usr/src/uml-kernel/linux-2.6.11/arch/um/kernel/tt/include > -I/usr/src/uml-kernel/linux-2.6.11/arch/um/kernel/skas/include -D__x86_64__ > -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -c -o arch/um/kernel/process.o > arch/um/kernel/process.c arch/um/kernel/process.c: In function > `check_sysemu': > arch/um/kernel/process.c:262: error: `RAX' undeclared (first use in this > function) arch/um/kernel/process.c:262: error: (Each undeclared identifier > is reported only once arch/um/kernel/process.c:262: error: for each > function it appears in.) arch/um/kernel/process.c:288: error: `ORIG_RAX' > undeclared (first use in this function) arch/um/kernel/process.c: In > function `check_ptrace': > arch/um/kernel/process.c:339: error: `ORIG_RAX' undeclared (first use in > this function) make[1]: *** [arch/um/kernel/process.o] Error 1 > make: *** [arch/um/kernel] Error 2 The above command is trying to compile a 64-bit guest. Probably you should do a "make clean" or even a mrproper (save your .config!) to make it succeed. > Also, will there be a performance benefit from running uml 32bit guest on a > 64bit host (now or planned?) Difficult question... the host OS will anyway run faster and that will benefit a bit UML, but I don't know how much that is. However, for now you have the big disadvantage that SKAS does not run on x86-64 hosts, so you loose the possibility to run in SKAS mode. -- Paolo Giarrusso, aka Blaisorblade Skype user "PaoloGiarrusso" Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |
From: Antoine Martin <antoine@na...> - 2005-05-08 16:53:45
|
On Sat, 2005-05-07 at 17:53 +0200, Blaisorblade wrote: > On Friday 06 May 2005 19:38, Antoine Martin wrote: > > Now, I've hit some real problems. I've managed to crash the host twice > > within a short period of time. > > > I captured the messages from a serial > > console the second time > Would you check that you haven't got an hardware problem? It is repeatable and Andi Kleen says it is a kernel bug, he is working on a fix. See LKML for details: http://lkml.org/lkml/2005/5/8/47/index.html > The stack traces you get come from kernelspace tasks (one is named "kernel-4", > the other is "events/0"). And they have nothing in common with each other, > and come from a vanilla kernel (i.e. we haven't a SKAS patch to blame :-)). > > > (it seems that you only need to generate some > > load to trigger this bug - I was compiling some code with gcc): > You need to do that *inside* UML to generate the bug? Yep, it is pretty easy to trigger. Antoine |
From: Blaisorblade <blaisorblade@ya...> - 2005-05-08 16:50:03
|
On Saturday 07 May 2005 21:24, Dick Middleton wrote: > Anybody got a patch for host skas which works for the Debian 2.6.11 > kernel source? The 2,6,10 patch fails with 2.6.11. Yes, the 2.6.10 patch fails even with vanilla 2.6.11. Try the one for vanilla 2.6.11, no? -- Paolo Giarrusso, aka Blaisorblade Skype user "PaoloGiarrusso" Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |
From: Blaisorblade <blaisorblade@ya...> - 2005-05-08 16:45:25
|
On Friday 06 May 2005 19:38, Antoine Martin wrote: > Now, I've hit some real problems. I've managed to crash the host twice > within a short period of time. > I captured the messages from a serial > console the second time Would you check that you haven't got an hardware problem? The stack traces you get come from kernelspace tasks (one is named "kernel-4", the other is "events/0"). And they have nothing in common with each other, and come from a vanilla kernel (i.e. we haven't a SKAS patch to blame :-)). > (it seems that you only need to generate some > load to trigger this bug - I was compiling some code with gcc): You need to do that *inside* UML to generate the bug? -- Paolo Giarrusso, aka Blaisorblade Skype user "PaoloGiarrusso" Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |
From: Blaisorblade <blaisorblade@ya...> - 2005-05-08 16:45:25
|
On Friday 06 May 2005 15:12, Jason Clark wrote: > SHould be possible using COW files. Create your bootable CD, then create > a COW file that exists on the CD. Then, mount a partion as tmpfs and place > your RW file there. You will have to create the RW file at every boot > obviously. > I wonder if you could just mount /dev/rd/0 as ubd0. That would be pretty > neat. Technically it should be feasible, but IMHO it's not a good idea, at most you could use that as COW file; copying the whole UBD over a non-swappable ramdisk is slow and bad (while tmpfs is swappable memory, and both ramdisks and the ramfs filesystem, again, are not). -- Paolo Giarrusso, aka Blaisorblade Skype user "PaoloGiarrusso" Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |
From: Blaisorblade <blaisorblade@ya...> - 2005-05-08 16:45:25
|
On Friday 06 May 2005 17:09, Antoine Martin wrote: > > The 64-bit guest boots into existing 32-bit root_fs without problems, I > > will rebuild all my 64-bit guests and let you know how this goes. > > Actually, I got mixed up, the 64-bit filesystems worked but the 32-bit > didn't. I couldn't find any option to allow support for 32-bit binaries, > has it been removed? Does this mean that we need pure 64-bit fs? For now it's so. In fact when I read that I was quite astonished. If you want to run the 32-bit FS, for now stay with 32-bit UMLs. Jeff said he had some compatibility code but that it's still very rough. > > But so far, the performance increase over TT guests on a x86_64 box is > > quite simply breathtaking! > That is still true. No figures yet, just the feeling of interactivity. -- Paolo Giarrusso, aka Blaisorblade Skype user "PaoloGiarrusso" Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |