apparent sn_console deadlock

apparent sn_console deadlock

[William Lee Irwin III]

[-- Attachment #1: Type: text/plain, Size: 933 bytes --]

I seem to be having trouble around the switchover from sal_console_early
to sal_console on an Altix with 2.6.8-rc2-mm2. As I've been out of the
ia64 loop for a while, I figured it might be good to check in and see
if this is a known issue or some easily-recognizable gaffe before going
through too much trouble to debug it.

The apparent failure mode is some kind of deadlock and/or loss of
console output. Userspace doesn't make progress to normal booting (as
it would if the console were merely misdirected), though it's not
directly observable. system logs and other indicators show no trace
of userspace having run on 2.6.8-rc2-mm2.

Bootlog (altix.log.7.gz) and .config attached. Also attached is a
bootlog from a small attempt not to switch out of sal_console_early
(altix.log.9.gz) i.e. bailing out of sn_sal_serial_console_init()
immediately without registering or unregistering consoles or doing
anything.

Thanks.


-- wli

[-- Attachment #2: config-altix.gz --]
[-- Type: application/octet-stream, Size: 11879 bytes --]

[-- Attachment #3: altix.log.7.gz --]
[-- Type: application/octet-stream, Size: 3556 bytes --]

[-- Attachment #4: altix.log.9.gz --]
[-- Type: application/octet-stream, Size: 6885 bytes --]

Re: apparent sn_console deadlock

[Jesse Barnes]

On Tuesday, August 3, 2004 3:59 am, William Lee Irwin III wrote:
> I seem to be having trouble around the switchover from sal_console_early
> to sal_console on an Altix with 2.6.8-rc2-mm2. As I've been out of the
> ia64 loop for a while, I figured it might be good to check in and see
> if this is a known issue or some easily-recognizable gaffe before going
> through too much trouble to debug it.
>
> The apparent failure mode is some kind of deadlock and/or loss of
> console output. Userspace doesn't make progress to normal booting (as
> it would if the console were merely misdirected), though it's not
> directly observable. system logs and other indicators show no trace
> of userspace having run on 2.6.8-rc2-mm2.
>
> Bootlog (altix.log.7.gz) and .config attached. Also attached is a
> bootlog from a small attempt not to switch out of sal_console_early
> (altix.log.9.gz) i.e. bailing out of sn_sal_serial_console_init()
> immediately without registering or unregistering consoles or doing
> anything.

Your first log indicates that you're passing 'console=ttyS0' to the kernel at 
boot time.  As of 2.6.8-rc2 (IIRC) you need to pass 'console=ttySG0' instead.  
You'll also want to create a new character device, /dev/ttySG0 with major 
204, minor 40.

I wasn't able to see the config file you attached, but I think you've 
correctly turned on the SGI L1 console support (in the serial drivers section 
of the character devices menu of Kconfig).

Jesse

Re: apparent sn_console deadlock

[William Lee Irwin III]

On Tuesday, August 3, 2004 3:59 am, William Lee Irwin III wrote:
>> Bootlog (altix.log.7.gz) and .config attached. Also attached is a
>> bootlog from a small attempt not to switch out of sal_console_early
>> (altix.log.9.gz) i.e. bailing out of sn_sal_serial_console_init()
>> immediately without registering or unregistering consoles or doing
>> anything.

On Tue, Aug 03, 2004 at 08:55:16AM -0700, Jesse Barnes wrote:
> Your first log indicates that you're passing 'console=ttyS0' to the kernel at 
> boot time.  As of 2.6.8-rc2 (IIRC) you need to pass 'console=ttySG0' instead.  
> You'll also want to create a new character device, /dev/ttySG0 with major 
> 204, minor 40.
> I wasn't able to see the config file you attached, but I think you've 
> correctly turned on the SGI L1 console support (in the serial drivers section 
> of the character devices menu of Kconfig).

After console=ttySG0, making the device node, and removing the debug
hack of keeping the early SAL console, everything works now.

Thanks.

-- wli