Bugs item #1699695, was opened at 2007-04-13 06:07 Message generated for change (Comment added) made by jessorensen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1699695&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: kucharsk (kucharsk) Assigned to: Amit Shah (amitshah) Summary: Entering Solaris kmdb may cause Solaris to double trap Initial Comment: Attempts to enter the Solaris kmdb debugger once the system either causes Solaris to panic or causes a user mode double trap (trap 8) to be reported. This does not occur when running software QEMU, so it appears KVM may be saving an incorrect CS value on the stack for certain traps. This is kvm-18 running on Fedora Core 6 x86_64 kernel 2.6.20-1.2933.fc6 on a dual CPU rev. F Opteron platform: processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 65 model name : Dual-Core AMD Opteron(tm) Processor 2218 stepping : 2 cpu MHz : 2613.392 cache size : 1024 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm cr8_legacy bogomips : 5231.22 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc ---------------------------------------------------------------------- >Comment By: Jes Sorensen (jessorensen) Date: 2010-06-11 12:45 Message: Hi The fix for this went into upstream with the following commit. Closing! Jes commit 41d6af119206e98764b4ae6d264d63acefcf851e Author: Amit Shah <amit.shah@xxxxxxxxxxxx> Date: Thu Feb 28 16:06:15 2008 +0530 KVM: is_long_mode() should check for EFER.LMA is_long_mode currently checks the LongModeEnable bit in EFER instead of the LongModeActive bit. This is wrong, but we survived this till now since it wasn't triggered. This breaks guests that go from long mode to compatibility mode. This is noticed on a solaris guest and fixes bug #1842160 Signed-off-by: Amit Shah <amit.shah@xxxxxxxxxxxx> Signed-off-by: Avi Kivity <avi@xxxxxxxxxxxx> ---------------------------------------------------------------------- Comment By: Amit Shah (amitshah) Date: 2007-12-01 08:59 Message: Logged In: YES user_id=201894 Originator: NO The patch is: http://www.mail-archive.com/kvm-devel%40lists.sourceforge.net/msg08947.html I have to write up a test case before this goes in mainline; hopefully that'll be done within a week. ---------------------------------------------------------------------- Comment By: Carlo Marcelo Arenas Belon (carenas) Date: 2007-12-01 06:17 Message: Logged In: YES user_id=36771 Originator: NO can you post a link to your proposed patch that should fix the last GP reported?, could it be the same reported in BUG1842160? ---------------------------------------------------------------------- Comment By: Carlo Marcelo Arenas Belon (carenas) Date: 2007-11-28 20:28 Message: Logged In: YES user_id=36771 Originator: NO the last stable qemu: qemu (0.9.0) have the same problem when running a 64bit guest OpenSolaris (with or without kqemu). the last qemu snapshot (without kvm) as used by qemu fails with a triple fault as shown by : qemu: fatal: triple fault RAX=0000000000000010 RBX=000000000000000f RCX=0000000000000000 RDX=00000000000cc4f1 RSI=000000000000000a RDI=fffffffffb8545db RBP=fffffffffbc27198 RSP=fffffffffbc27188 R8 =6e776f6e6b6e753c R9 =ffffffffffc29b03 R10=fffffffffbc2aa50 R11=0000000000000000 R12=00000000000000c8 R13=fffffffffbc271e0 R14=fffffffffbc272a8 R15=fffffffffb8ee828 RIP=fffffffffba92596 RFL=00000202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0000 0000000000000000 00000000 00000000 CS =0030 0000000000000000 00000fff 00a09b00 SS =0038 0000000000000000 ffffffff 00ef9300 DS =0000 0000000000000000 00000000 00000000 FS =0000 0000000200000000 00000000 00000000 GS =0000 fffffffffbc26ef0 00000000 00000000 LDT=0000 0000000000000000 00000000 00008200 TR =0070 fffffffffbc28d40 00000067 fb0089c2 GDT= fffffffffb7fe000 000001ef IDT= fffffffffbc276f0 00000fff CR0=80050011 CR2=0000000000000000 CR3=0000000007c00000 CR4=000000b8 CCS=fffffffffbc2aa50 CCD=6e776f6e6fabcaec CCO=SUBQ FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000 XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000 XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000 XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000 XMM08=00000000000000000000000000000000 XMM09=00000000000000000000000000000000 XMM10=00000000000000000000000000000000 XMM11=00000000000000000000000000000000 XMM12=00000000000000000000000000000000 XMM13=00000000000000000000000000000000 XMM14=00000000000000000000000000000000 XMM15=00000000000000000000000000000000 Aborted ---------------------------------------------------------------------- Comment By: Amit Shah (amitshah) Date: 2007-11-22 08:04 Message: Logged In: YES user_id=201894 Originator: NO OK, that #GP is what I had seen earlier (kvm not handling LME/LMA properly); I had sent the patch to the mailing list, but it's not yet merged. That patch should solve this GP. ---------------------------------------------------------------------- Comment By: kucharsk (kucharsk) Date: 2007-11-21 22:37 Message: Logged In: YES user_id=1767421 Originator: YES I'm currently unable to get Solaris to boot in 64-bit mode due to a different #GP occurring elsewhere; the same image boots just fine in 64-bit mode if run with "--no-kvm." Solaris DOES boot properly in 32-bit mode. ---------------------------------------------------------------------- Comment By: Amit Shah (amitshah) Date: 2007-11-21 21:54 Message: Logged In: YES user_id=201894 Originator: NO Hm, If a #GP is being injected, kvm should report why and where. There shouldn't have been the need to modify guest code for that. I'll check into this. Thanks for pointing out the problem area. Can you confirm that Solaris now boots fine in both, 32-bit and 64-bit modes? ---------------------------------------------------------------------- Comment By: kucharsk (kucharsk) Date: 2007-11-21 20:51 Message: Logged In: YES user_id=1767421 Originator: YES The problem still exists in kvm-53. By modifying some Solaris code, I was able to track down the initial fault, and it appears that Solaris is (erroneously) receiving a #GP when using wrmsr to write a "1" to MSR 0x1d9, the diagnostic MSR. ---------------------------------------------------------------------- Comment By: Amit Shah (amitshah) Date: 2007-11-21 16:18 Message: Logged In: YES user_id=201894 Originator: NO There's no double trap anymore I believe. 64-bit Solaris boots fine for me with kvm-53. Though I can't enter the kmdb. ---------------------------------------------------------------------- Comment By: Amit Shah (amitshah) Date: 2007-11-08 06:58 Message: Logged In: YES user_id=201894 Originator: NO Ah, so that must be it. KVM's detection of long mode was (still is) not reliable; I've still some more work to do before the patch is pushed upstream, but it doesn't bite anyone now, so it's fine I guess. ---------------------------------------------------------------------- Comment By: kucharsk (kucharsk) Date: 2007-11-08 04:59 Message: Logged In: YES user_id=1767421 Originator: YES I'm not sure what state you're catching Solaris in, but when transitioning to long mode, Solaris ALWAYS enables PAE before setting LME. However, when dropping back into compatibility mode, which Solaris did in Solaris 10 prior to Solaris 10 1/06, Solaris deactivates long mode by doing the following: 1) Clear CR0.PG 2) Clear CR4.PAE 3) Clear EFER.LME 4) Set CR0.PG So if CR4.PAE is clear but EFER.LME is set you may be catching it between steps 2 and 3 on its way back to 32-bit compatibility mode. This was done then because Solaris 10 relied on real mode drivers to boot pre-GRUB, and as such during boot the CPU was constantly flipping back and forth between compatibility and long mode until enough infrastructure was available that the kernel could run in long mode full time. ---------------------------------------------------------------------- Comment By: Amit Shah (amitshah) Date: 2007-11-03 16:15 Message: Logged In: YES user_id=201894 Originator: NO I didn't expect the patch to fix this issue. This just fixes a #GP caused due to entering long mode. Even though you cite the code, at least the 10-GA version I have exhibits this behaviour. I also have a pre-installed solaris VM that has grub, but I'm not sure which version it is. Both exhibit similar behaviour as I noted in my last comment. Maybe the newer builds fail or do some things differently. ---------------------------------------------------------------------- Comment By: kucharsk (kucharsk) Date: 2007-11-03 03:32 Message: Logged In: YES user_id=1767421 Originator: YES I don't see any difference in behavior in kvm-50 running on 2.6.23.1-10.fc7 with the same change made to is_long_mode(); I'd be curious to know which version you are testing with. In fact, I see the trap behavior if I try the kmdb entry/continue with a 64-bit kernel; with a 32-bit kernel I see the following from kvm instead: unhandled vm exit: 0x3d50101 vcpu_id 0 rax 00000000fec38018 rbx 00000000ff02b328 rcx 0000000000000000 rdx 0000000000000000 rsi 00000000fec1ee60 rdi 00000000ff022008 rsp 00000000fec37edc rbp 00000000fec37ee8 r8 0000000000000000 r9 0000000000000000 r10 0000000000000000 r11 0000000000000000 r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 0000000000000000 rip 00000000fe800377 rflags 00000202 cs 0158 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type b l 0 g 0 avl 0) ds 0160 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) es 0160 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) ss 0160 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) fs 0000 (00000000/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) gs 01b0 (fec200f8/000006c7 p 1 dpl 0 db 1 s 1 type 3 l 0 g 0 avl 0) tr 0150 (fec214a0/00000067 p 1 dpl 0 db 0 s 0 type 9 l 0 g 0 avl 0) ldt 0000 (00000000/0000ffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) gdt fe7fe000/2cf idt fec207d0/7ff cr0 80050011 cr2 0 cr3 20ee000 cr4 b8 cr8 0 efer 800 Aborted ---------------------------------------------------------------------- Comment By: kucharsk (kucharsk) Date: 2007-11-03 03:24 Message: Logged In: YES user_id=1767421 Originator: YES I made the change to kvm-48 but didn't notice any difference in behavior. Also, in your post to kvm-devel you say that you found LME to be set BEFORE PAE: > is_long_mode currently checks the LongModeEnable bit in > EFER instead of the LongModeActive bit. This should work > for most cases, but for some broken implementations that > set the LME bit before enabling PAE in CR4 to enter long > mode. > > This is noticed on a solaris guest on an AMD host (but might > not be specific to AMD). However: 1) Solaris does not do that, it ALWAYS follows the order given in the AMD documentation 2) The AMD documentation states the steps to enter long mode can be done in ANY order once CR0.PG is set to 0 to disable paging, but gives the steps in this order: 1) Set CR4.PAE to 1 to enable PAE 2) Load CR3 with the base address of the 64-bit page tables 3) Set EFER.LME to 1 to enable long mode 4) Set CR0.PG to 1 to start paging and set EFER.LMA to 1 To see how Solaris handles this: <http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/i86pc/dboot/dboot_grub.s#160> shows how it's done in GRUB and <http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/i86pc/ml/mpcore.s#412> shows how Solaris does the same for additional CPUs it starts. You can see from the code that Solaris ALWAYS sets CR4.PAE BEFORE setting EFER.LME. I will try downloading kvm-50, will make the change and will report back. ---------------------------------------------------------------------- Comment By: Amit Shah (amitshah) Date: 2007-11-02 22:41 Message: Logged In: YES user_id=201894 Originator: NO If you got a #GP while booting solaris, I have a fix that I just posted to the kvm-devel list. With that patch, I can boot a solaris guest (but it doesn't go beyond a point, complaining of some fs corruption). Entering kmdb and trying out :c and also tudebug/W 1 and then :c don't cause any dump or double trap, though, for me, it seems to get stuck after this. Nothing happens in the debug mode. No kernel messages as well. This is true for both, 64-bit and 32-bit solaris kernels. ---------------------------------------------------------------------- Comment By: kucharsk (kucharsk) Date: 2007-10-29 20:27 Message: Logged In: YES user_id=1767421 Originator: YES You must use a newer version of Solaris such as the OpenSolaris build available directly from Sun or from third parties such as the BeleniX live CD or Nexenta: OpenSolaris: http://www.opensolaris.org/os/downloads/sol_ex_dvd/ (requires free registration) BeleniX: http://www.genunix.org/distributions/belenix_site/binfiles/belenix0.6.1.iso Nexenta Install CD: http://mirrors.cat.pdx.edu/gnusolaris/elatte_installcd_alpha7_i386.zip This is because the Solaris 10 GA release used an old booter that relied on real mode drivers. The booter changed to GRUB in the Solaris 10 1/06 release and in OpenSolaris. ---------------------------------------------------------------------- Comment By: Amit Shah (amitshah) Date: 2007-10-29 18:43 Message: Logged In: YES user_id=201894 Originator: NO Using kvm-git, I was able to install solaris-10-GA-x86-dvd.iso, with no special qemu options. However, I don't get a grub menu on bootup. Also, it just keeps rebooting and doesn't actually load anything. ---------------------------------------------------------------------- Comment By: Amit Shah (amitshah) Date: 2007-10-23 22:14 Message: Logged In: YES user_id=201894 Originator: NO Thanks for the patience to test it out each release. I'm sorry we don't have a solution yet, and no promises either. But I will get to this first thing I get the necessary time. ---------------------------------------------------------------------- Comment By: kucharsk (kucharsk) Date: 2007-10-23 22:09 Message: Logged In: YES user_id=1767421 Originator: YES This problem continues in kvm-48. ---------------------------------------------------------------------- Comment By: kucharsk (kucharsk) Date: 2007-10-04 04:45 Message: Logged In: YES user_id=1767421 Originator: YES Double trap behavior continues in kvm-45. ---------------------------------------------------------------------- Comment By: kucharsk (kucharsk) Date: 2007-09-21 02:59 Message: Logged In: YES user_id=1767421 Originator: YES The double trap behavior is back with kvm-42. Note the wild reported value for cs: pid=0, pc=0x30, sp=0x38, eflags=0xfffffffffbc46a50 cr0: 80050011<pg,wp,et,pe> cr4: b8<pge,pae,pse,de> cr2: 0 cr3: a000000 cr8:0 rdi: fffffffffbc46a50 rsi: fffffffffbc6be60 rdx: 0 rcx: 0 r8: fffffffffbc46dd0 r9: fffffffffbb601d0 rax: fffffffffbc46dd0 rbx: ffffffffffa23030 rbp: fffffffffbc46a50 r10: ffffffffff83b698 r11: ffffffffff8390bc r12: fffffffffbc46ca8 r13: fffffffffbc25ba0 r14: fffffffffbc26fd0 r15: fffffffffbc6be60 fsb: 200000000 gsb: fffffffffbc26fd0 ds: 0 es: 0 fs: 0 gs: 0 trp: 8 err: fffffffffb8001d4 rip: 30 cs: 202 rfl: fffffffffbc46a50 rsp: 38 ss: 0 ---------------------------------------------------------------------- Comment By: kucharsk (kucharsk) Date: 2007-09-14 06:12 Message: Logged In: YES user_id=1767421 Originator: YES The "new" behavior continues in kvm-39. On continuation from the Solaris kmdb debugger, kvm still dies with an unhandled vm exit: unhandled vm exit: 0x3d50101 rax 0000000080050001 rbx 00000000fec38500 rcx 0000000000000018 rdx 00000000fec3c47c rsi 00000000fec38500 rdi 00000000fec38508 rsp 00000000fec3c45c rbp 00000000fec3c4a0 r8 0000000000000000 r9 0000000000000000 r10 0000000000000000 r11 0000000000000000 r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 0000000000000000 rip 00000000fe832a33 rflags 00000212 cs 0158 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type b l 0 g 0 avl 0) ds 0160 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) es 0160 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) ss 0160 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) fs 0000 (00000000/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) gs 01b0 (fec1fdec/000006b3 p 1 dpl 0 db 1 s 1 type 3 l 0 g 0 avl 0) tr 0150 (fec21170/00000067 p 1 dpl 0 db 0 s 0 type 9 l 0 g 0 avl 0) ldt 0000 (00000000/0000ffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) gdt fe7fe000/2cf idt fec204b0/7ff cr0 80050001 cr2 0 cr3 50b0000 cr4 b8 cr8 0 efer 800 Aborted For easier testing, I have confirmed this same issue occurs when booting the BeleniX Live CD from http://www.genunix.org/distributions/belenix_site/binfiles/ramdata/belenix0.6.1.iso. ---------------------------------------------------------------------- Comment By: kucharsk (kucharsk) Date: 2007-08-28 00:40 Message: Logged In: YES user_id=1767421 Originator: YES In kvm-36, the behavior appears to have changed. On continuation from the Solaris kmdb debugger, kvm now dies with an uhandled vm exit: unhandled vm exit: 0x3d50101 rax 0000000080050001 rbx 00000000fec3a800 rcx 0000000000000018 rdx 00000000fec3e77c rsi 00000000fec3a800 rdi 00000000fec3a808 rsp 00000000fec3e75c rbp 00000000fec3e7a0 r8 0000000000000000 r9 0000000000000000 r10 0000000000000000 r11 0000000000000000 r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 0000000000000000 rip 00000000fe832503 rflags 00000212 cs 0158 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type b l 0 g 0 avl 0) ds 0160 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) es 0160 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) ss 0160 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) fs 0000 (00000000/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) gs 01b0 (fec220e8/000006af p 1 dpl 0 db 1 s 1 type 3 l 0 g 0 avl 0) tr 0150 (fec23460/00000067 p 1 dpl 0 db 0 s 0 type 9 l 0 g 0 avl 0) ldt 0000 (00000000/0000ffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) gdt fe7fe000/2cf idt fec227a0/7ff cr0 80050001 cr2 0 cr3 6487000 cr4 b8 cr8 0 efer 800 Whether the behavior has truly changed or this vm exit is masking the earlier bug is unknown at this time. ---------------------------------------------------------------------- Comment By: kucharsk (kucharsk) Date: 2007-08-25 09:17 Message: Logged In: YES user_id=1767421 Originator: YES This problem still exists but have been unable to try newer versions as of yet. I am working on using the latest Solaris Express DVD to come up with a one step reproducible test case, though bug 1698925 complicates matters somewhat. ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2007-08-25 04:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Amit Shah (amitshah) Date: 2007-08-10 19:55 Message: Logged In: YES user_id=201894 Originator: NO It'll be great if you can make the image available. In the meanwhile, please also try the latest git tree or a tree which is later than the commit 80917728e43e248155c019f743655806b582b099 This has fixes for debug register usage on AMD processors. ---------------------------------------------------------------------- Comment By: kucharsk (kucharsk) Date: 2007-07-25 05:50 Message: Logged In: YES user_id=1767421 Originator: YES Also, the intitial Solaris install will need to be done in --no-kvm mode due to bug #1760056, among others. ---------------------------------------------------------------------- Comment By: kucharsk (kucharsk) Date: 2007-07-25 05:09 Message: Logged In: YES user_id=1767421 Originator: YES I'm working on making an image available for download. You can reproduce this easily on your own by doing the following: 1) Download and install OpenSolaris from opensolaris.org 2) Once the image is installed, boot the image 3) When the grub menu appears, press "e" and edit the line "kernel$ /platform/i86pc/kernel/$ISADIR/unix" to read "kernel$ /platform/i86pc/kernel/$ISADIR/unix -kd" 4) Boot the image, you should see: Loading kmdb... Welcome to kmdb Loaded modules: [ unix krtld genunix ] [0]> At this point at ":c" followed by a carriage return will result in a double trap. If you first enter: tudebug/W 1 :c A register dump will precede the double trap. The register dump will show that the value of %cs at the time of the double trap is usually either 0x246 or 0x282 - values that Solaris not only doesn't use, but that also indicate RPL 2; OpenSolaris only uses RPL levels 0 and 3. That seems to indicate %cs corruption somewhere along the line. ---------------------------------------------------------------------- Comment By: Amit Shah (amitshah) Date: 2007-07-24 16:42 Message: Logged In: YES user_id=201894 Originator: NO Where can I download the solaris image from? ---------------------------------------------------------------------- Comment By: kucharsk (kucharsk) Date: 2007-07-24 06:24 Message: Logged In: YES user_id=1767421 Originator: YES Problem persists in kvm-31 with kernel 2.6.21-1.3228.fc7. ---------------------------------------------------------------------- Comment By: kucharsk (kucharsk) Date: 2007-04-25 09:06 Message: Logged In: YES user_id=1767421 Originator: YES This problem continues in kvm-20 with kernel 2.6.20-1.2944.fc6. ---------------------------------------------------------------------- Comment By: kucharsk (kucharsk) Date: 2007-04-13 06:08 Message: Logged In: YES user_id=1767421 Originator: YES The CS value is suspected as that is how Solaris determines whether the trap was a user mode trap or not, but at the time the trap is actually taken Solaris should not be running with a user mode CS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1699695&group_id=180599 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
