I tried booting again with -kv :
module /platform/i86pc/kernel/amd64/unix: text at [0xfffffffffb800000,
0xfffffffffb938f93] data at 0xfffffffffbc00000
module /kernel/amd64/genunix: text at [0xfffffffffb938fa0,
0xfffffffffbb8f897] data at 0xfffffffffbc80b40
Loading kmdb...
module /kernel/misc/amd64/kmdbmod: text at [0xfffffffffbcf0730,
0xfffffffffbd939a7] data at 0xfffffffffbd939b0
module /kernel/misc/amd64/ctf: text at [0xfffffffffbb8f8a0,
0xfffffffffbb9a1f7] data at 0xfffffffffbdaed10
SunOS Release 5.11 Version snv_125 64-bit
Copyright 1983-2009 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
features:
614dffff<cpuid,mwait,cx16,sse3,asysc,htt,sse2,sse,sep,pat,cx8,pae,mca,mmx,cmov,de,pge,mtrr,msr,tsc,lgpg>
mem = 8387812K (0x1fff39000)
Using default device instance data
initialized model-specific module 'cpu_ms.GenuineIntel' on chip 0 core
0 strand 0
root nexus = i86pc
pseudo0 at root
pseudo0 is /pseudo
scsi_vhci0 at root
scsi_vhci0 is /scsi_vhci
npe0 at root: space 0 offset 0
npe0 is /p...@0,0
PCI Express-device: i...@1f, isa0
NOTICE: Invalid iBFT table 0x1
pseudo-device: acpippm0
acpippm0 is /pseudo/acpi...@0
pseudo-device: ppm0
ppm0 is /pseudo/p...@0
ramdisk0 at root
ramdisk0 is /ramdisk
root on /ramdisk:a fstype ufs
SMBIOS v2.3 loaded (2026 bytes)acpinex0 at root
acpinex0 is /fw
pseudo-device: dld0
dld0 is /pseudo/d...@0
PCI Express-device: pci8086,3...@3, pcieb0
pcieb0 is /p...@0,0/pci8086,3...@3
PCIE-device: pci8086,3...@0,2, pcieb2
pcieb2 is /p...@0,0/pci8086,3...@3/pci8086,3...@0,2
PCIE-device: pci1014,2...@1, bge0
bge0 is /p...@0,0/pci8086,3...@3/pci8086,3...@0,2/pci1014,2...@1
PCIE-device: pci1014,2...@1,1, bge1
bge1 is /p...@0,0/pci8086,3...@3/pci8086,3...@0,2/pci1014,2...@1,1
Ethernet address = 0:14:5e:3d:5a:f3
ISA-device: asy0
asy0 is /p...@0,0/i...@1f/a...@1,3f8
ISA-device: asy1
asy1 is /p...@0,0/i...@1f/a...@1,2f8
PCI Express-device: pci8086,2...@1c, pci_pci0
pci_pci0 is /p...@0,0/pci8086,2...@1c
PCI Express-device: pci8086,2...@1e, pci_pci1
pci_pci1 is /p...@0,0/pci8086,2...@1e
PCI Express-device: pci1014,2...@1d, uhci0
uhci0
system>
The one thing I can think of, is that IBM warns on these blades that the
network connection for the BMC is shared (hijacked) from bge0, and that
if you PXE boot over bge0, the PXE code will reset the bge interface in
a way the will disconnect the SOL connection.
Given this, I wonder if the disconnection is a (delayed) consequence of
the bge0 driver loading shortly before the disconnection?
-Kyle
Kyle McDonald wrote:
Hi,
I have several types of IBM BladeCenter blades (mostly HS20 and LS20.)
The BladeCenter manages these blades through a BMC with IPMI, and
provides access to the serial console (ttyb) of the blades through the
Serial Over LAN (SOL) feature of the BMC.
When I user Solaris10 on these blades, Access to the serial console is
fine.
When I install SXCE (sNVb120 through 125 at least,) the console
connection is terminated (not gibberish - The BMC stops sending the SOL
data) shortly after the kernel boots, and the management module for the
BladeCenter reports that 'SOL is not ready' for the blade I'm using,
until I reboot it.
I've played a bit with the BMC BIOS Settings, but I don't think that's
the problem since this works fine in s10.
How can I collect more info, or narrow this problem down further so that
I can file a useful bug report?
The output from booting SXCE sNV b125, as you can see it disconnects
after loading the sysidcfg info, previous builds used to disconnect
while 'Configuring /dev' if I recall.
SunOS Release 5.11 Version snv_125 64-bit
Copyright 1983-2009 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
NOTICE: Invalid iBFT table 0x1
Configuring /dev
WARNING: emlxs: ddi_modopen drv/fct failed: err 2
Custom JumpStart
Reading ZFS config: done.
Setting up Java. Please wait...
Serial console, reverting to text install
Beginning system identification...
Searching for configuration file(s)...
Using sysid configuration file 172.30.171.30:/ex/Inst/SysID/Def/sysidcfg
Search complete.
Discoveri
system> console -T blade[3]
SOL is not ready
system>
The 'system>' prompt is the CLI for the mmanagement module. The 'console
-T blade[3]' command is me trying to reconnect to the SOL console.
Anyone know of any changes in sNV that might have triggered this?
It's making all of these blades useless for OpenSolaris.
-Kyle
_______________________________________________
driver-discuss mailing list
driver-disc...@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
