Hmm, seems there is a new problem, with today''s onnv-gate bits &
xVM 3.1.4.
On an amd64 box (AMD Athlon(tm) 64 X2 Dual Core Processor 6400+)
with nVidia graphics, Xorg panics the dom0 kernel as soon as the
GUI is started. Everything was started in 64-bit mode.
panic[cpu0]/thread=ffffff02c49eb780:
BAD TRAP: type=e (#pf Page fault) rp=ffffff000f467740 addr=fffffe01aeb6be50
Xorg:
#pf Page fault
Bad kernel fault at addr=0xfffffe01aeb6be50
pid=778, pc=0xfffffffffb887ed3, sp=0xffffff000f467838, eflags=0x10246
cr0: 80050033<pg,wp,ne,et,mp,pe> cr4: 660<xmme,fxsr,mce,pae>
cr2: fffffe01aeb6be50
rdi: fffffe01aeb6be50 rsi: 0 rdx: 80000000d00006ff
rcx: 3 r8: 0 r9: 7ffff9400000
rax: 0 rbx: 80000000d00006ff rbp: ffffff000f4678d0
r10: 1 r11: 80000000d0200000 r12: 0
r13: 1 r14: fffffe01aeb6be50 r15: 80000000d00006ff
fsb: 7fffff290200 gsb: fffffffffbc5c0b0 ds: 0
es: 0 fs: 0 gs: 0
trp: e err: 3 rip: fffffffffb887ed3
cs: e030 rfl: 10246 rsp: ffffff000f467838
ss: e02b
ffffff000f467620 unix:die+ea ()
ffffff000f467730 unix:trap+13d9 ()
ffffff000f467740 unix:_cmntrap+12f ()
ffffff000f4678d0 unix:atomic_cas_64+3 ()
ffffff000f467970 unix:hati_pte_map+153 ()
ffffff000f4679f0 unix:hati_load_common+15a ()
ffffff000f467ab0 unix:hat_devload+13c ()
ffffff000f467b70 genunix:segdev_faultpages+1ca ()
ffffff000f467c60 genunix:segdev_fault+301 ()
ffffff000f467d70 genunix:as_fault+5ae ()
ffffff000f467df0 unix:pagefault+95 ()
ffffff000f467f00 unix:trap+bf3 ()
ffffff000f467f10 unix:_cmntrap+12f ()
syncing file systems...
...
> $C
ffffff000f4678d0 atomic_cas_64+3()
ffffff000f467970 hati_pte_map+0x153(ffffff02beee6168, 1ca, 0, 80000000d00006ff,
20, 0)
ffffff000f4679f0 hati_load_common+0x15a(ffffff02d14465d0, 7ffff9400000, 0, 20b,
20, 1, 80000000d0000)
ffffff000f467ab0 hat_devload+0x13c(ffffff02d14465d0, 7ffff9400000, 200000,
80000000d0000, 20b, 0)
ffffff000f467b70 segdev_faultpages+0x1ca(ffffff02d14465d0, ffffff02d70027e8,
7ffff9400000, 200000, 0, 2,
ffffff02d700fc40)
ffffff000f467c60 segdev_fault+0x301(ffffff02d14465d0, ffffff02d70027e8,
7ffff9400000, 1000, 0, 2)
ffffff000f467d70 as_fault+0x5ae(ffffff02d14465d0, ffffff02d13db2a0,
7ffff9400000, 1, 0, 2)
ffffff000f467df0 pagefault+0x95(7ffff9400000, 0, 2, 0)
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
ffffff000f467f00 trap+0xbf3(ffffff000f467f10, 7ffff9400000, 0)
ffffff000f467f10 0xfffffffffb80020f()
> ::cpuinfo -v
ID ADDR FLG NRUN BSPL PRI RNRN KRNRN SWITCH THREAD PROC
0 fffffffffbc75d70 1b 1 0 10 no no t-1 ffffff02c49eb780 Xorg
| |
RUNNING <--+ +--> PRI THREAD PROC
READY 60 ffffff000ed55c80 sched
EXISTS
ENABLE
ID ADDR FLG NRUN BSPL PRI RNRN KRNRN SWITCH THREAD PROC
1 ffffff02c3e2d000 1f 1 0 -1 no no t-1 ffffff000ef3fc80 (idle)
| |
RUNNING <--+ +--> PRI THREAD PROC
READY 60 ffffff000f1a8c80 sched
QUIESCED
EXISTS
ENABLE
> ::pgrep Xorg|::pmap
SEG BASE SIZE RES PATH
ffffff02bf6ad128 0000000000400000 2032k /usr/X11/bin/amd64/Xorg
ffffff02bf6ad0c8 000000000060c000 80k 52k /usr/X11/bin/amd64/Xorg
ffffff02bf6adcc8 0000000000800000 444k 352k [ anon ]
ffffff02d70027e8 00007ffff9400000 7800k
<<<<<<<<<<<<<<<<<<<<<<<<<<<<
ffffff02d70029c8 00007ffff9c00000 264k /usr/X11/lib/modules/amd64/l
ffffff02d7006000 00007ffff9c52000 8k 8k /usr/X11/lib/modules/amd64/l
ffffff02c85a21e8 00007ffffa000000 4k 4k [ anon ]
ffffff02d7566300 00007ffffa400000 1276k /usr/X11/lib/modules/drivers
ffffff02d707e300 00007ffffa63e000 308k 48k /usr/X11/lib/modules/drivers
ffffff02d68fb3c8 00007ffffa68b000 16k 12k [ anon ]
ffffff02d75628a8 00007ffffa7f0000 4k 4k [ anon ]
ffffff02d7132060 00007ffffa800000 4k /usr/X11/lib/modules/fonts/a
ffffff02d7562848 00007ffffa811000 4k 4k /usr/X11/lib/modules/fonts/a
ffffff02d7132d20 00007ffffac00000 4k 4k [ anon ]
...
The address 0x7ffff9400000 from pagefault() seems to
be the mapped video memory. And the PTE
80000000d00006ff (in register %rdx) looks like a
4-MB largepage.
I suspect that either changeset 6691: "6671130 Shanghai provides
better TLB management for 1GB pages"
or changeset 6695: "6423097 segvn_pagelock() may perform very poorly"
broke this...
This message posted from opensolaris.org
Ryan Scott
2008-May-23 18:38 UTC
Re: xVM 3.1.4 / Xorg panic with today''s onnv-gate bits...
Jürgen Keil wrote:> Hmm, seems there is a new problem, with today''s onnv-gate bits & xVM 3.1.4.How old are your xVM bits? (I know, we make those hard to update...) I updated to the latest of both onnv and xvm yesterday on my Ultra 20, and I''m not seeing a panic. It could also only happen on certain types of nvidia cards. From /var/log/Xorg.0.log, I''m running on: (II) NVIDIA(0): NVIDIA GPU Quadro FX 1500 (G71GL) at PCI:7:0:0 (GPU-0) I don''t have much insight into the Xorg side of things, so I''m just guessing here. -Ryan> > On an amd64 box (AMD Athlon(tm) 64 X2 Dual Core Processor 6400+) > with nVidia graphics, Xorg panics the dom0 kernel as soon as the > GUI is started. Everything was started in 64-bit mode. > > > panic[cpu0]/thread=ffffff02c49eb780: > BAD TRAP: type=e (#pf Page fault) rp=ffffff000f467740 addr=fffffe01aeb6be50 > > > Xorg: > #pf Page fault > Bad kernel fault at addr=0xfffffe01aeb6be50 > pid=778, pc=0xfffffffffb887ed3, sp=0xffffff000f467838, eflags=0x10246 > cr0: 80050033<pg,wp,ne,et,mp,pe> cr4: 660<xmme,fxsr,mce,pae> > cr2: fffffe01aeb6be50 > > rdi: fffffe01aeb6be50 rsi: 0 rdx: 80000000d00006ff > rcx: 3 r8: 0 r9: 7ffff9400000 > rax: 0 rbx: 80000000d00006ff rbp: ffffff000f4678d0 > r10: 1 r11: 80000000d0200000 r12: 0 > r13: 1 r14: fffffe01aeb6be50 r15: 80000000d00006ff > fsb: 7fffff290200 gsb: fffffffffbc5c0b0 ds: 0 > es: 0 fs: 0 gs: 0 > trp: e err: 3 rip: fffffffffb887ed3 > cs: e030 rfl: 10246 rsp: ffffff000f467838 > ss: e02b > > ffffff000f467620 unix:die+ea () > ffffff000f467730 unix:trap+13d9 () > ffffff000f467740 unix:_cmntrap+12f () > ffffff000f4678d0 unix:atomic_cas_64+3 () > ffffff000f467970 unix:hati_pte_map+153 () > ffffff000f4679f0 unix:hati_load_common+15a () > ffffff000f467ab0 unix:hat_devload+13c () > ffffff000f467b70 genunix:segdev_faultpages+1ca () > ffffff000f467c60 genunix:segdev_fault+301 () > ffffff000f467d70 genunix:as_fault+5ae () > ffffff000f467df0 unix:pagefault+95 () > ffffff000f467f00 unix:trap+bf3 () > ffffff000f467f10 unix:_cmntrap+12f () > > syncing file systems... > ... > > >> $C > ffffff000f4678d0 atomic_cas_64+3() > ffffff000f467970 hati_pte_map+0x153(ffffff02beee6168, 1ca, 0, 80000000d00006ff, 20, 0) > ffffff000f4679f0 hati_load_common+0x15a(ffffff02d14465d0, 7ffff9400000, 0, 20b, 20, 1, 80000000d0000) > ffffff000f467ab0 hat_devload+0x13c(ffffff02d14465d0, 7ffff9400000, 200000, 80000000d0000, 20b, 0) > ffffff000f467b70 segdev_faultpages+0x1ca(ffffff02d14465d0, ffffff02d70027e8, 7ffff9400000, 200000, 0, 2, > ffffff02d700fc40) > ffffff000f467c60 segdev_fault+0x301(ffffff02d14465d0, ffffff02d70027e8, 7ffff9400000, 1000, 0, 2) > ffffff000f467d70 as_fault+0x5ae(ffffff02d14465d0, ffffff02d13db2a0, 7ffff9400000, 1, 0, 2) > ffffff000f467df0 pagefault+0x95(7ffff9400000, 0, 2, 0) <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > ffffff000f467f00 trap+0xbf3(ffffff000f467f10, 7ffff9400000, 0) > ffffff000f467f10 0xfffffffffb80020f() > >> ::cpuinfo -v > ID ADDR FLG NRUN BSPL PRI RNRN KRNRN SWITCH THREAD PROC > 0 fffffffffbc75d70 1b 1 0 10 no no t-1 ffffff02c49eb780 Xorg > | | > RUNNING <--+ +--> PRI THREAD PROC > READY 60 ffffff000ed55c80 sched > EXISTS > ENABLE > > ID ADDR FLG NRUN BSPL PRI RNRN KRNRN SWITCH THREAD PROC > 1 ffffff02c3e2d000 1f 1 0 -1 no no t-1 ffffff000ef3fc80 (idle) > | | > RUNNING <--+ +--> PRI THREAD PROC > READY 60 ffffff000f1a8c80 sched > QUIESCED > EXISTS > ENABLE > >> ::pgrep Xorg|::pmap > SEG BASE SIZE RES PATH > ffffff02bf6ad128 0000000000400000 2032k /usr/X11/bin/amd64/Xorg > ffffff02bf6ad0c8 000000000060c000 80k 52k /usr/X11/bin/amd64/Xorg > ffffff02bf6adcc8 0000000000800000 444k 352k [ anon ] > ffffff02d70027e8 00007ffff9400000 7800k <<<<<<<<<<<<<<<<<<<<<<<<<<<< > ffffff02d70029c8 00007ffff9c00000 264k /usr/X11/lib/modules/amd64/l > ffffff02d7006000 00007ffff9c52000 8k 8k /usr/X11/lib/modules/amd64/l > ffffff02c85a21e8 00007ffffa000000 4k 4k [ anon ] > ffffff02d7566300 00007ffffa400000 1276k /usr/X11/lib/modules/drivers > ffffff02d707e300 00007ffffa63e000 308k 48k /usr/X11/lib/modules/drivers > ffffff02d68fb3c8 00007ffffa68b000 16k 12k [ anon ] > ffffff02d75628a8 00007ffffa7f0000 4k 4k [ anon ] > ffffff02d7132060 00007ffffa800000 4k /usr/X11/lib/modules/fonts/a > ffffff02d7562848 00007ffffa811000 4k 4k /usr/X11/lib/modules/fonts/a > ffffff02d7132d20 00007ffffac00000 4k 4k [ anon ] > ... > > > > > The address 0x7ffff9400000 from pagefault() seems to > be the mapped video memory. And the PTE > 80000000d00006ff (in register %rdx) looks like a > 4-MB largepage. > > > I suspect that either changeset 6691: "6671130 Shanghai provides > better TLB management for 1GB pages" > or changeset 6695: "6423097 segvn_pagelock() may perform very poorly" > broke this... > > > This message posted from opensolaris.org > _______________________________________________ > xen-discuss mailing list > xen-discuss@opensolaris.org
Ryan Scott
2008-May-23 19:38 UTC
Re: xVM 3.1.4 / Xorg panic with today''s onnv-gate bits...
Ryan Scott wrote:> Jürgen Keil wrote: >> Hmm, seems there is a new problem, with today''s onnv-gate bits & xVM 3.1.4. > > How old are your xVM bits? (I know, we make those hard to update...) > > I updated to the latest of both onnv and xvm yesterday on my Ultra 20, > and I''m not seeing a panic. > > It could also only happen on certain types of nvidia cards. From > /var/log/Xorg.0.log, I''m running on: > > (II) NVIDIA(0): NVIDIA GPU Quadro FX 1500 (G71GL) at PCI:7:0:0 (GPU-0) > > I don''t have much insight into the Xorg side of things, so I''m just > guessing here.Never mind, I was a day off. Since I bfu''d yesterday, the archives wouldn''t include the changes you mentioned. Have you filed a bug? -Ryan> > -Ryan > >> On an amd64 box (AMD Athlon(tm) 64 X2 Dual Core Processor 6400+) >> with nVidia graphics, Xorg panics the dom0 kernel as soon as the >> GUI is started. Everything was started in 64-bit mode. >> >> >> panic[cpu0]/thread=ffffff02c49eb780: >> BAD TRAP: type=e (#pf Page fault) rp=ffffff000f467740 addr=fffffe01aeb6be50 >> >> >> Xorg: >> #pf Page fault >> Bad kernel fault at addr=0xfffffe01aeb6be50 >> pid=778, pc=0xfffffffffb887ed3, sp=0xffffff000f467838, eflags=0x10246 >> cr0: 80050033<pg,wp,ne,et,mp,pe> cr4: 660<xmme,fxsr,mce,pae> >> cr2: fffffe01aeb6be50 >> >> rdi: fffffe01aeb6be50 rsi: 0 rdx: 80000000d00006ff >> rcx: 3 r8: 0 r9: 7ffff9400000 >> rax: 0 rbx: 80000000d00006ff rbp: ffffff000f4678d0 >> r10: 1 r11: 80000000d0200000 r12: 0 >> r13: 1 r14: fffffe01aeb6be50 r15: 80000000d00006ff >> fsb: 7fffff290200 gsb: fffffffffbc5c0b0 ds: 0 >> es: 0 fs: 0 gs: 0 >> trp: e err: 3 rip: fffffffffb887ed3 >> cs: e030 rfl: 10246 rsp: ffffff000f467838 >> ss: e02b >> >> ffffff000f467620 unix:die+ea () >> ffffff000f467730 unix:trap+13d9 () >> ffffff000f467740 unix:_cmntrap+12f () >> ffffff000f4678d0 unix:atomic_cas_64+3 () >> ffffff000f467970 unix:hati_pte_map+153 () >> ffffff000f4679f0 unix:hati_load_common+15a () >> ffffff000f467ab0 unix:hat_devload+13c () >> ffffff000f467b70 genunix:segdev_faultpages+1ca () >> ffffff000f467c60 genunix:segdev_fault+301 () >> ffffff000f467d70 genunix:as_fault+5ae () >> ffffff000f467df0 unix:pagefault+95 () >> ffffff000f467f00 unix:trap+bf3 () >> ffffff000f467f10 unix:_cmntrap+12f () >> >> syncing file systems... >> ... >> >> >>> $C >> ffffff000f4678d0 atomic_cas_64+3() >> ffffff000f467970 hati_pte_map+0x153(ffffff02beee6168, 1ca, 0, 80000000d00006ff, 20, 0) >> ffffff000f4679f0 hati_load_common+0x15a(ffffff02d14465d0, 7ffff9400000, 0, 20b, 20, 1, 80000000d0000) >> ffffff000f467ab0 hat_devload+0x13c(ffffff02d14465d0, 7ffff9400000, 200000, 80000000d0000, 20b, 0) >> ffffff000f467b70 segdev_faultpages+0x1ca(ffffff02d14465d0, ffffff02d70027e8, 7ffff9400000, 200000, 0, 2, >> ffffff02d700fc40) >> ffffff000f467c60 segdev_fault+0x301(ffffff02d14465d0, ffffff02d70027e8, 7ffff9400000, 1000, 0, 2) >> ffffff000f467d70 as_fault+0x5ae(ffffff02d14465d0, ffffff02d13db2a0, 7ffff9400000, 1, 0, 2) >> ffffff000f467df0 pagefault+0x95(7ffff9400000, 0, 2, 0) <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< >> ffffff000f467f00 trap+0xbf3(ffffff000f467f10, 7ffff9400000, 0) >> ffffff000f467f10 0xfffffffffb80020f() >> >>> ::cpuinfo -v >> ID ADDR FLG NRUN BSPL PRI RNRN KRNRN SWITCH THREAD PROC >> 0 fffffffffbc75d70 1b 1 0 10 no no t-1 ffffff02c49eb780 Xorg >> | | >> RUNNING <--+ +--> PRI THREAD PROC >> READY 60 ffffff000ed55c80 sched >> EXISTS >> ENABLE >> >> ID ADDR FLG NRUN BSPL PRI RNRN KRNRN SWITCH THREAD PROC >> 1 ffffff02c3e2d000 1f 1 0 -1 no no t-1 ffffff000ef3fc80 (idle) >> | | >> RUNNING <--+ +--> PRI THREAD PROC >> READY 60 ffffff000f1a8c80 sched >> QUIESCED >> EXISTS >> ENABLE >> >>> ::pgrep Xorg|::pmap >> SEG BASE SIZE RES PATH >> ffffff02bf6ad128 0000000000400000 2032k /usr/X11/bin/amd64/Xorg >> ffffff02bf6ad0c8 000000000060c000 80k 52k /usr/X11/bin/amd64/Xorg >> ffffff02bf6adcc8 0000000000800000 444k 352k [ anon ] >> ffffff02d70027e8 00007ffff9400000 7800k <<<<<<<<<<<<<<<<<<<<<<<<<<<< >> ffffff02d70029c8 00007ffff9c00000 264k /usr/X11/lib/modules/amd64/l >> ffffff02d7006000 00007ffff9c52000 8k 8k /usr/X11/lib/modules/amd64/l >> ffffff02c85a21e8 00007ffffa000000 4k 4k [ anon ] >> ffffff02d7566300 00007ffffa400000 1276k /usr/X11/lib/modules/drivers >> ffffff02d707e300 00007ffffa63e000 308k 48k /usr/X11/lib/modules/drivers >> ffffff02d68fb3c8 00007ffffa68b000 16k 12k [ anon ] >> ffffff02d75628a8 00007ffffa7f0000 4k 4k [ anon ] >> ffffff02d7132060 00007ffffa800000 4k /usr/X11/lib/modules/fonts/a >> ffffff02d7562848 00007ffffa811000 4k 4k /usr/X11/lib/modules/fonts/a >> ffffff02d7132d20 00007ffffac00000 4k 4k [ anon ] >> ... >> >> >> >> >> The address 0x7ffff9400000 from pagefault() seems to >> be the mapped video memory. And the PTE >> 80000000d00006ff (in register %rdx) looks like a >> 4-MB largepage. >> >> >> I suspect that either changeset 6691: "6671130 Shanghai provides >> better TLB management for 1GB pages" >> or changeset 6695: "6423097 segvn_pagelock() may perform very poorly" >> broke this... >> >> >> This message posted from opensolaris.org >> _______________________________________________ >> xen-discuss mailing list >> xen-discuss@opensolaris.org > > _______________________________________________ > xen-discuss mailing list > xen-discuss@opensolaris.org
Jürgen Keil
2008-May-26 08:43 UTC
Re: xVM 3.1.4 / Xorg panic with today''s onnv-gate bits...
> Ryan Scott wrote: > > Jürgen Keil wrote: > >> Hmm, seems there is a new problem, with today's onnv-gate bits & xVM 3.1.4. > > > > How old are your xVM bits? (I know, we make those hard to update...) > > > > I updated to the latest of both onnv and xvm yesterday on my Ultra 20, > > and I'm not seeing a panic. > > Never mind, I was a day off. Since I bfu'd yesterday, the archives > wouldn't include the changes you mentioned. Have you > filed a bug?Not yet. When does build 91 close? I've found out that the problem is caused by the putback for these bugs: 6671130 Shanghai provides better TLB management for 1GB pages 6679225 erratum 298 detection needed 6692442 errata updates needed for griffin processors (family 0x11) There is a bug in the new set_max_page_level() function, in usr/src/uts/i86pc/vm/hat_i86.c: 480 static void 481 set_max_page_level() 482 { 483 level_t lvl; 484 485 if (!kbm_largepage_support) { 486 lvl = 0; 487 } 488 if (x86_feature & X86_1GPG) { 489 lvl = 2; 490 if (chk_optimal_1gtlb && cpuid_opteron_erratum(CPU, 6671130)) { 491 lvl = 1; 492 } 493 if (plat_mnode_xcheck(LEVEL_SIZE(2) >> LEVEL_SHIFT(0))) { 494 lvl = 1; 495 } 496 } else { 497 lvl = 1; 498 } 499 mmu.max_page_level = lvl; 500 501 if ((lvl == 2) && (enable_1gpg == 0)) 502 mmu.umax_page_level = 1; 503 else 504 mmu.umax_page_level = lvl; 505 } Note how the test for "!kbm_largepage_support" does not affect mmu.max_page_level / mmu.umax_page_level any more. Under xen / xVM kbm_largepage_support == 0, and the max page level was set to 0 before this putback. Apparently there is an "else" missing for the if (!kbm_largepage_support). A change like this fixes the panic: diff --git a/usr/src/uts/i86pc/vm/hat_i86.c b/usr/src/uts/i86pc/vm/hat_i86.c --- a/usr/src/uts/i86pc/vm/hat_i86.c +++ b/usr/src/uts/i86pc/vm/hat_i86.c @@ -484,8 +484,7 @@ set_max_page_level() if (!kbm_largepage_support) { lvl = 0; - } - if (x86_feature & X86_1GPG) { + } else if (x86_feature & X86_1GPG) { lvl = 2; if (chk_optimal_1gtlb && cpuid_opteron_erratum(CPU, 6671130)) { lvl = 1; When does build 91 close? Any chance to get this fix into build 91? Otherwise, I guess build 91 will have a completely broken dom0 for users running the Xorg server in dom0 (I got the same panic both on systems with nvidia and ati video hw). This message posted from opensolaris.org _______________________________________________ xen-discuss mailing list xen-discuss@opensolaris.org
Jürgen Keil
2008-May-26 09:00 UTC
Re: xVM 3.1.4 / Xorg panic with today''s onnv-gate bits...
I wrote> Ryan Scott wrote:> > Have you filed a bug? > > Not yet.Someone was faster than me. Apparently there already is a bug filed, 6706850 "large page configured for xen hypervisor". This message posted from opensolaris.org
Stuart Maybee
2008-May-26 17:40 UTC
Re: xVM 3.1.4 / Xorg panic with today''s onnv-gate bits...
Actually, based on your e-mail report an internal bug was filed and the fix should be putback soon. see cr# 6706850 Jürgen Keil wrote:>> Ryan Scott wrote: >>> Jürgen Keil wrote: >>>> Hmm, seems there is a new problem, with today's onnv-gate bits & xVM 3.1.4. >>> How old are your xVM bits? (I know, we make those hard to update...) >>> >>> I updated to the latest of both onnv and xvm yesterday on my Ultra 20, >>> and I'm not seeing a panic. >> Never mind, I was a day off. Since I bfu'd yesterday, the archives >> wouldn't include the changes you mentioned. Have you >> filed a bug? > > Not yet. When does build 91 close? > > I've found out that the problem is caused by the putback for > these bugs: > > 6671130 Shanghai provides better TLB management for 1GB pages > 6679225 erratum 298 detection needed > 6692442 errata updates needed for griffin processors (family 0x11) > > There is a bug in the new set_max_page_level() function, > in usr/src/uts/i86pc/vm/hat_i86.c: > > 480 static void > 481 set_max_page_level() > 482 { > 483 level_t lvl; > 484 > 485 if (!kbm_largepage_support) { > 486 lvl = 0; > 487 } > 488 if (x86_feature & X86_1GPG) { > 489 lvl = 2; > 490 if (chk_optimal_1gtlb && cpuid_opteron_erratum(CPU, 6671130)) { > 491 lvl = 1; > 492 } > 493 if (plat_mnode_xcheck(LEVEL_SIZE(2) >> LEVEL_SHIFT(0))) { > 494 lvl = 1; > 495 } > 496 } else { > 497 lvl = 1; > 498 } > 499 mmu.max_page_level = lvl; > 500 > 501 if ((lvl == 2) && (enable_1gpg == 0)) > 502 mmu.umax_page_level = 1; > 503 else > 504 mmu.umax_page_level = lvl; > 505 } > > > Note how the test for "!kbm_largepage_support" > does not affect mmu.max_page_level / > mmu.umax_page_level any more. Under xen / > xVM kbm_largepage_support == 0, and > the max page level was set to 0 before this > putback. > > Apparently there is an "else" missing for the > if (!kbm_largepage_support). A change like > this fixes the panic: > > diff --git a/usr/src/uts/i86pc/vm/hat_i86.c b/usr/src/uts/i86pc/vm/hat_i86.c > --- a/usr/src/uts/i86pc/vm/hat_i86.c > +++ b/usr/src/uts/i86pc/vm/hat_i86.c > @@ -484,8 +484,7 @@ set_max_page_level() > > if (!kbm_largepage_support) { > lvl = 0; > - } > - if (x86_feature & X86_1GPG) { > + } else if (x86_feature & X86_1GPG) { > lvl = 2; > if (chk_optimal_1gtlb && cpuid_opteron_erratum(CPU, 6671130)) { > lvl = 1; > > > > When does build 91 close? Any chance to get this fix into build 91? > Otherwise, I guess build 91 will have a completely broken dom0 for > users running the Xorg server in dom0 (I got the same panic both on > systems with nvidia and ati video hw). > > > This message posted from opensolaris.org > _______________________________________________ > xen-discuss mailing list > xen-discuss@opensolaris.org_______________________________________________ xen-discuss mailing list xen-discuss@opensolaris.org