Ettore,
Some instructions about how to bring out the motherboard's serial
line on the Ultra-20. See in-line below.
Best,
-db
--
; David J. Brown Ph.D. (cantab.)
; Solaris Engineering
; Sun Microsystems Inc.
; --
; Postal Address: Telephone: (650) 786-5558
; 4150 Network Circle, UMPK17-307 FAX: (650) 786-5734
; Santa Clara, CA 95054 e-mail: djb at sun.com
Randy Fishel wrote:
> On Wed, 17 Dec 2008, Ettore Aldrovandi wrote:
>
>
>> On Wed, 2008-12-17 at 12:22, J?rgen Keil wrote:
>>
>>
>>>>> device pci108e,534d at 8 ica_ddi_setwake: could not
>>>>>
>>>> evaluate _PRWg dev
>>>>
>>>>> suspending device display at 0
>>>>>
>>> Problem is that the nvidia module stops sending debug output to
>>> the VGA console as soon as the nvidia module gets suspended.
>>> With a test suspend on my AMD box with mainboard integrated
>>> nvidia graphics I get no more debug output after suspending of the
>>> "display" / "nvidia" module, until "display" / "nvidia" resumes.
>>>
>>> That is, the bug could be in the nvidia module, but it could also be
>>> in any module that gets suspend after nvidia has suspend.
>>>
>>>
>> pci108e,534d at 8 is nge0, though, as far as I can tell. You don?t think
>> it's that the problem, am I correct? (I'm totally new at this, so I'm
>> completely out of my water.)
>>
>
> The acpica_ddi_setwake (possibly on nge0) message is benign. If it
> is associated with nge, then it means that wake on lan won't work for
> that interface.
>
> Mostly what we are saying is that sometime after the nvidia driver
> is suspended, something else goes wrong, but as the display is
> suspended, you won't see the message.
>
>
>>> I think Ettore has to repeat this test with the console redirected
>>> to a serial port, e.g. boot with " -B console=ttyb ", and run the
>>> suspend / test suspend on the COM2 serial console.
>>>
>> There are no serial ports on the Ultra 20. Would a USB-to-serial work?
>>
>>
>
> There is, but you have to open the box and plug in a serial port
> connector to a 10pin header.
If you take the side cover off the Ultra-20 and look at the motherboard,
look
near the board's lower right-hand corner to find the flat round silver
battery (used to
maintain the motherboard's CMOS memory settings I believe).
Just slightly up and to the left of that there's a little 10 pin DIP header
with a white plastic surround on it. You'll know you have the right thing
because one of the pins (the upper right one) is clipped out - in order
that
the keyed DIP connector that you'll plug into it can only be plugged in
in the correct way.
Now, you need to get out to a parts store where you can buy the little
cable in question. This thing is a short (12 inch - or ~30cm) ribbon cable
with the DIP header on one end and a 9 pin male 'D' connector (also known as
a DB-9P I think) on the other end. The pin mapping between the DIP header
on the motherboard connector and the DB-9 is one to one - i.e. direct.
Once you get that plugged in to the motherboard you should be able to plug
a serial line connector into the DB-9 (which is usually mounted in a blank
on one of the system's back panel slots.)
The pin-out for the use of these things with a serial line is somewhat
standard
too. The pins of primary interest are pins 2,3 and 7 - for TxData,
RxData and Ground
respectively. The port is wired at DTE (data terminal equipment) as
described
by the RS-232 spec.
If you intend to connect the port to another system's serial-line, you
will most likely
need a cross-over cable to make it work properly, as most all computers'
serial ports
are wired as DTE.
A bit of quick history: the serial interface specified by RS-232 was
used early on
to connect terminals (data terminal equipment) to modems (data
communication equipment):
or, DTE to DCE. Such connections would be done with a straight-over cable.
When connecting DTE to DTE however (as when connected two computers' ports
togetether), the data transmit and data receive lines (pins 2 and 3)
must be crossed-over
so that transmit on the one box is connected to receive on the other,
and vice-versa.
Apologies if you already know all this, but I include it here for other
readers who may not
and attempted completeness of explanation.
BTW, don't forget about making sure the baud rates of the machines on
both ends are the same.
The default is 9600 baud for most boxes, as set in their BIOS at
power-on reset.
But if things don't work, this is one thing you'll need to check.
The final thing is to enable Solaris to talk to the serial port.
On the Ultra-20, this port is the primary UART (sometimes known as COM A
in MS-DOS terms) located
at 0x3f8 in ISA i/o address space. As a result it maps to ttya in
Solaris - the one that we *do* squirt
debugging output to [when that's enabled) in the Suspend/Resume code.
If you're going to get to this using 'tip' from another box running
Solaris over a serial port that's 'ttya', you'll
also need to edit /etc/remote on that system to add a line for ttya
(analogous to what's in that file for 'hardwire' on ttyb
at present). Then you'll be able to say
'tip ttya'
to watch what's going on.
You may also wish to direct the Solaris system console to the serial
line (ttya) on the box whose Suspend/Resume
you're watching/debugging. You can do that by:
1. giving the -B console=ttya option to GRUB while you're booting
the syste
2. editing /boot/solaris/bootenv.rc to change the line:
setprop console 'text'
to
setprop console 'ttya'
I hope this is a sufficiently complete explanation to get this going for
you. Please let us know if
it is not, or if you get stuck along the way.
Indeed, once you're able to get the system console running on the serial
line, and able to tip to it from
another system's serial line, we can help you further with detailed
debugging options for the Suspend/Resume
code itself.
> In theory, a USB port could also be
> used, but it's output will stop once the USB driver is suspended.
> The serial port (i.e. ttya, com1, etc.) is setup to display messages
> nearly to the _S3 call, and early on in wakeup. I am trying to see if
> I can dig up how to do this on a U20 (don't have one handy).
>
> ---- Randy
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> pm-discuss mailing list
> pm-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/pm-discuss
>
