andrewk9 writes: > Bug 6205961 currently has a status of "2-Incomplete:Need More Info" (as > viewed via b.o.o). Your mention of this in the ARC case as a blocker to > supporting dump/sync implies that this bug has been accepted as a problem, > and should therefore have status 3 or higher. Also, the details of the bug > are not visible on b.o.o - we have the infamous "see comments". > > Is the bug confirmed a a problem? In which case please update the bug status. > Also, if you are able to provide some details of the bug, that would enable > external contributors to assist.
Indeed. The problem seems to be that the internal kernel so* functions (sockfs stuff) can block during panic. There's not much detail available beyond that. A dump of a stack would probably be helpful. It's possible that the issue is something that we can't really deal with at all without some massive refactoring. (I know that dumping after panic is a delicate and special operation -- you can't necessarily trust the system to be working right anymore.) My guess would be "needs a new project," not just "here's a bug." That's just a guess. Based on my embedded background, I would prefer to see dumping moved out of the system itself and placed in the hands of the booter. (The same guy who originally got us into memory ought to be smart enough to get us back out -- meaning GRUB on x86 and OBP on SPARC.) But maybe that's just me. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
