Re: need a bit of early boot help
Mouse <[email protected]>
| Newsgroups | gmane.os.netbsd.ports.vax |
|---|---|
| Message-ID | <[email protected]> |
> NetBSD 1.6.1 [...] stops in a suspicious place: Right after printing > "root file system type: ffs", on the next line, it prints an 'S' and > hangs. [simh indicates this] is the first character of this date > stamp: > Sun Nov 9 22:05:50 GMT 2003 [a second mail] > After sending that last email I went back to the console. It had > been sitting there for maybe ten minutes. Suddenly it sprang to > life; the date stamp never finished printing (at least not that I > could see, but the console is only running at 1200 baud) but it > printed the 'B' that starts the "Building databases..." line. It > printed a few more lines after that and has now been hung again for > several minutes. I'm waiting to see if it starts up again. It printed a few more lines in full, or the first character of each? If the former, were they printed at full normal 1200 baud, or did each character take a long time to print? See below for the relevance. I can hardly claim any particular insight into the 11/780 in particular. But it does occur to me that everything before-and-including "root file system type: ffs" is printed from within the kernel, but that timestamp is printed by userland. That may not be the relevant thing, though. I don't know 1.6.1 in enough detail, but perhaps kernel output is polled but userland is interrupt-driven? Maybe something is wrong with TXCS-driven interrupts? I'm also wondering if there's something wrong with the hardware responsible for pushing bytes out to the console such that it takes a long time to start, or maybe a long time to finish, but once a character is started it prints at normal speed. I'm having trouble imagining a plausible failure mode that wouldn't affect kernel output before that point, but, well, I don't really know the 780. Another possibility is an interrupt storm bad enough that IPL 0 (whether kernel or userland) simply isn't getting cycles, though I have trouble reconciling that with actually _losing_ output (as opposed to it just being very slow). I'd also need to dig for more details to see whether that's consistent with getting the first character but nothing more of what is presumably a single write(). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B