Randy Fishel wrote: > > So this is really a new one to me. For the most part, I have been > using the serial line (especially ttya) as a reliable debugging > mechanism for s/r. So let's determine if this is a problem with tip, > networking, or the serial line. > > I have traditionally used tip as a hardwire mechanism, so I have > typically changed /etc/remote to have a line similar to: > > tiphost:dv=/dev/cua/a:br#9600 > > and the tip command would be: > > tip tiphost > > This at least removed nsswitch from the equasion. > it's not mandatory, doing "tip -9600 /dev/term/a" has always worked for me on sparc and x86 machines
> So, a couple of questions here (may require several runs)... > > If you made a simiar entry in /etc/remote, does this work after s/r? > Independant of the above, is it any different if '/dev/cua/a' is > replaced with '/dev/term/a'? the message: henry at delljm:~$ tip -9600 /dev/cua/a tip: unknown host /dev/cua/a isn't related to /etc/remote's content, but only to: Nov 29 06:32:10 delljm asy: [ID 267298 kern.notice] asy0: UART @ 3f8 scratch register: expected 0x5a, got 0xff Nov 29 06:32:10 delljm asy: [ID 702181 kern.notice] Cannot identify UART chip at 3f8 > If this still is a problem, has this changed with any particular > release, and what release are you currently running? i noticed the problem with snv_101rc1a and now snv_101b_rc2 > Does the 'Cannot identify UART' message appear after every s/r > cycle, and if not, does the problem exist if the message isn't > displauyed? > unfortunately, not. After reboot, it works. And sometimes, after s/r it also works. But since s/r is available, i'm not rebooting very often the laptop :) imho, the pertinent message is: "scratch register: expected 0x5a, got 0xff" thanks for your reply, gerard
