Re: two Xen failures

2013-07-25 Thread Roger Pau Monné
On 25/07/13 17:15, Julian Elischer wrote:
> I have a VPS on RootBSD (freebsd developer's discount).
> They use Xen on their vps servers.
> 
> yesterday I tried to upgrade my server to -current and came across two
> interesting failure modes.
> 
> 1/ I somehow wrote a kernel that made the loader crash when loading it
> (not running it).
> this was Not Good (TM)  because the loader loads the kernel BEFORE it
> gets to the prompt so there was no way for me to type in the name of an
> alternate kernel. (actually I may have been ab;e to do it from the stage
> 2 loader if I could remember the syntax and hte stage 2 lader could load
> ELF binaries (I remember it could only do a.out .. is that still true?))
> 
> It's distressing that the loader can be made to crash from loading a
> misformed kernel.
> I still have it if anyone is still interested in pulling it apart to see
> what is weird about it.
> 
> 2/ it is impossible for me to make a -current kernel that can mount root.
> it finds the drive, then it tastes it to see if there is a lable it
> wants, fails and then I get an infinite (apparently) set of "waiting for
> root device : usbus0"
> (or similar)messages.

I've just tested a current XENHVM amd64 kernel and it seems to work 
just fine, tip commit is:

commit 0f5a145fe0fcb6e9907f1458db21e478f874b760
Author: glebius 
Date:   Tue Jul 23 10:25:34 2013 +

Add constant for PPP-Max-PayLoad tag.

Submitted by:   Dmitry Luhtionov 

Justin committed a change to blkfront not long ago that changed the 
translation of "xbd" devices to "ada" instead of "ad", you should 
rename your "ad" devices in /etc/fstab to "ada". Your problem 
however doesn't seem to be related to that change, or you will at 
least get a prompt asking for your root device instead of being 
stuck in an infinite wait.

I guess there's no way you can execute "xenstore-ls -fp" on the Dom0 in 
order to see the state of the PV devices?

Here is the full verbose bootlog:

GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
SMAP type=01 base= len=0009fc00
SMAP type=02 base=0009fc00 len=0400
SMAP type=02 base=000f len=0001
SMAP type=01 base=0010 len=0f6ff000
SMAP type=02 base=0f7ff000 len=1000
SMAP type=02 base=fc00 len=0400
Table 'FACP' at 0xfc009a20
Table 'APIC' at 0xfc009b20
APIC: Found table at 0xfc009b20
APIC: Using the MADT enumerator.
MADT: Found CPU APIC ID 0 ACPI ID 0: enabled
SMP: Added CPU 0 (AP)
MADT: Found CPU APIC ID 2 ACPI ID 1: enabled
SMP: Added CPU 2 (AP)
MADT: Found CPU APIC ID 4 ACPI ID 2: enabled
SMP: Added CPU 4 (AP)
MADT: Found CPU APIC ID 6 ACPI ID 3: enabled
SMP: Added CPU 6 (AP)
MADT: Found CPU APIC ID 8 ACPI ID 4: enabled
SMP: Added CPU 8 (AP)
MADT: Found CPU APIC ID 10 ACPI ID 5: enabled
SMP: Added CPU 10 (AP)
MADT: Found CPU APIC ID 12 ACPI ID 6: enabled
SMP: Added CPU 12 (AP)
MADT: Found CPU APIC ID 14 ACPI ID 7: disabled
MADT: Found CPU APIC ID 16 ACPI ID 8: disabled
MADT: Found CPU APIC ID 18 ACPI ID 9: disabled
MADT: Found CPU APIC ID 20 ACPI ID 10: disabled
MADT: Found CPU APIC ID 22 ACPI ID 11: disabled
MADT: Found CPU APIC ID 24 ACPI ID 12: disabled
MADT: Found CPU APIC ID 26 ACPI ID 13: disabled
MADT: Found CPU APIC ID 28 ACPI ID 14: disabled
MADT: Found CPU APIC ID 30 ACPI ID 15: disabled
MADT: Found CPU APIC ID 32 ACPI ID 16: disabled
MADT: Found CPU APIC ID 34 ACPI ID 17: disabled
MADT: Found CPU APIC ID 36 ACPI ID 18: disabled
MADT: Found CPU APIC ID 38 ACPI ID 19: disabled
MADT: Found CPU APIC ID 40 ACPI ID 20: disabled
MADT: Found CPU APIC ID 42 ACPI ID 21: disabled
MADT: Found CPU APIC ID 44 ACPI ID 22: disabled
MADT: Found CPU APIC ID 46 ACPI ID 23: disabled
MADT: Found CPU APIC ID 48 ACPI ID 24: disabled
MADT: Found CPU APIC ID 50 ACPI ID 25: disabled
MADT: Found CPU APIC ID 52 ACPI ID 26: disabled
MADT: Found CPU APIC ID 54 ACPI ID 27: disabled
MADT: Found CPU APIC ID 56 ACPI ID 28: disabled
MADT: Found CPU APIC ID 58 ACPI ID 29: disabled
MADT: Found CPU APIC ID 60 ACPI ID 30: disabled
MADT: Found CPU APIC ID 62 ACPI ID 31: disabled
MADT: Found CPU APIC ID 64 ACPI ID 32: disabled
MADT: Found CPU APIC ID 66 ACPI ID 33: disabled
MADT: Found CPU APIC ID 68 ACPI ID 34: disabled
MADT: Found CPU APIC ID 70 ACPI ID 35: disabled
MADT: Found CPU APIC ID 72 ACPI ID 36: disabled
MADT: Found CPU APIC ID 74 ACPI ID 37: disabled
MADT: Found CPU APIC ID 76 ACPI ID 38: disabled
MADT: Found CPU APIC ID 78 ACPI ID 39: disabled
MADT: Found CPU APIC ID 80 ACPI ID 40: disabled
MADT: Found CPU APIC ID 82 ACPI ID 41: disabled
MADT: Found CPU APIC ID 84 ACPI ID 42: disabled
MADT: Found CPU APIC ID 86 ACPI ID 43: disabled
MADT: Found CPU APIC ID 88 ACPI ID 44: disabled
MADT: Found CPU APIC ID 90 ACPI ID 45: disabled
MADT: Found CPU APIC ID 92 ACPI ID 46: disabled
MADT: Found CPU APIC ID 94 ACPI ID 47: disabled
MADT: Found CPU APIC ID 96 ACPI ID 48: disabled
MA

two Xen failures

2013-07-25 Thread Julian Elischer

I have a VPS on RootBSD (freebsd developer's discount).
They use Xen on their vps servers.

yesterday I tried to upgrade my server to -current and came across two 
interesting failure modes.


1/ I somehow wrote a kernel that made the loader crash when loading it 
(not running it).
this was Not Good (TM)  because the loader loads the kernel BEFORE it 
gets to the prompt so there was no way for me to type in the name of 
an alternate kernel. (actually I may have been ab;e to do it from the 
stage 2 loader if I could remember the syntax and hte stage 2 lader 
could load ELF binaries (I remember it could only do a.out .. is that 
still true?))


It's distressing that the loader can be made to crash from loading a 
misformed kernel.
I still have it if anyone is still interested in pulling it apart to 
see what is weird about it.


2/ it is impossible for me to make a -current kernel that can mount root.
it finds the drive, then it tastes it to see if there is a lable it 
wants, fails and then I get an infinite (apparently) set of "waiting 
for root device : usbus0"

(or similar)messages.
a kernel compiled from -current in Jan 1 this year boots just fine
but I hav enot tried bisecting further (it is after all my MAIN server)
I have tried a minimal kernel, a GENERIC kernel, and a XENHVM kernel.
All behave the same.

If I have some time I will try bisect further but I plan on asking 
RootBSD if htey can give me a different VPS to try fdo it on as I 
don't want to screw up my server.. (again).


Julian

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"