> Here is the DL185 b86 stack backtrace: > > fec3ade0 debug_enter+0x27(fe8b75ec) > fec3ae14 panicsys+Ox338(fe8b5a7c, d40dd910, fec3ae2c) 1) > d40dd8f0 upanic+Oxc3(fe8b5a7c, d40dd910) > d40dd904 panic+Ox12(fe8b5a7c, 0, fe8b5ce4, fe8b5c88, d40dda04, 3) > d40dd95c die+Oxed(O, d40dda04, 3, 0) > d40dd9f0 trap+Ox1152(d40dda04, 3, 0) > d40dda04 Oxfe80037c() > d40ddaf4 UDiv+Ox2a(d3c04040, b86c0004, 3, 1, 1) > d40ddb4c cmlb`cmlb_validate_geometry+Ox7f(d3c04040, 1, 0, 1) > d40ddb7c cmlb`cmlb_ualidate+Ox3a(d3c04040, 0, 1) > d40ddbe4 sd`sd_unit_attach+Oxa7b(d3428940) > d40ddbf4 sd`sdattach+Ox15(d3428940, 0) > d40ddc24 devi_attach+Ox6c(d3428940, 0) > d40ddc48 attach_node+Ox81(d3428940) > d40ddc68 i_ndi_config_node+Ox8f(d3428940, 6, 0) > d40ddc88 i_ddi_attachchild+Ox35(d3428940) > d40ddca4 devi_attach_node+ox98(d3428940, 1020008) > d40ddcd0 config_immediate_children+Oxc9(d3558198, 1020008, ffffffff) > d40ddd04 ndi_busop_bus_config+Ox70(d3558198, 1020008, 2, ffffffff, 0, 0) > d40ddd40 > scsa2usb`scsa2usb_scsi_bus_config+0x80(d3558198, 1020008, 2, ffffffff, 0) > d40ddd68 scsi`scsi_hba_bus_config+Ox30(d3558198, 1020008, 2, ffffffff, 0, 0) > d40ddd90 devi_config_common+Ox6b(d3558198, 1020008, ffffffff) > d40dddc8 mt_config_thread+0x40(d3d165d0, 0) > d40ddd8 thread_start+8()
Hmm, at cmlb`cmlb_validate_geometry+ox7f() we're calling cmlb_resync_geom_caches(), and in cmlb_resync_geom_caches there is a 64-bit divide, which calls __udiv64, which calls UDiv (both use non-standard stack frames). Most likely we're dividing by zero. http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/cmlb.c#1729 1729 spc = pgeomp->g_nhead * pgeomp->g_nsect; 1730 pgeomp->g_capacity = capacity; 1731 pgeomp->g_ncyl = pgeomp->g_capacity / spc; I think that could happen for a CD device, when there is a 16-bit overflow at line 1723, setting pgeomp->g_nsect to 0: 1721 if (ISCD(cl)) { 1722 pgeomp->g_nhead = 1; 1723 pgeomp->g_nsect = nsect * nhead; 1724 } else { 1725 pgeomp->g_nhead = nhead; 1726 pgeomp->g_nsect = nsect; 1727 } > I removed the Smart Array E200 card and disabled the > USB controller in the BIOS, and it still panics. Are you sure that USB is disabled? The stack starts with scsa2usb, so my guess would be that there is some usb mass storage device (possibly an optical usb device) in that system with a strange geometry... And usb doesn't seem to be disabled... This message posted from opensolaris.org _______________________________________________ opensolaris-help mailing list [email protected]
