[PATCH] Fix E250 console with RSC

[PATCH] Fix E250 console with RSC

[Marc Zyngier]

Folks,

This patch fixes the RSC console oops Daniel discovered. The
problem is that, when the console is redirected to the RSC, it uses
the second sunsab chip, which is perfectly detected. Unfortunately,
the console framework calls the sunsab_console_setup each time a port
is registered. This has some adverse effect, as the third port has not
been discovered yet...

This patch, tested on my own E250 through an RSC console, hides the
problem by defering the console setup until the port has been properly
initialized.

Dave, please consider applying.

	M.

This patch fixes yet another sunsab problem, when console is set to
anything but the first port. The console framework calls
sunsab_console_setup for each port, and we end up setting up a console
on a not yet discovered port, which leads to an Oops. Instead, defer
console setup until the requested port is properly initialized. Tested
on an E250 through an RSC console.

Reported by Daniel Smolik <marvin@mydatex.cz>

Signed-off-by: Marc Zyngier <maz@misterjones.org>

diff --git a/drivers/serial/sunsab.c b/drivers/serial/sunsab.c
index dc673e1..077c201 100644
--- a/drivers/serial/sunsab.c
+++ b/drivers/serial/sunsab.c
@@ -886,6 +886,15 @@ static int sunsab_console_setup(struct c
 	unsigned long flags;
 	unsigned int baud, quot;
 
+	/*
+	 * The console framework calls us for each and every port
+	 * registered. Defer the console setup until the requested
+	 * port has been properly discovered. A bit of a hack,
+	 * though...
+	 */
+	if (up->port.type != PORT_SUNSAB)
+		return -1;
+	
 	printk("Console: ttyS%d (SAB82532)\n",
 	       (sunsab_reg.minor - 64) + con->index);
 

-- 
And if you don't know where you're going, any road will take you there...

Re: [PATCH] Fix E250 console with RSC

[Daniel Smolik]

Marc Zyngier napsal(a):
> Folks,
> 
> This patch fixes the RSC console oops Daniel discovered. The
> problem is that, when the console is redirected to the RSC, it uses
> the second sunsab chip, which is perfectly detected. Unfortunately,
> the console framework calls the sunsab_console_setup each time a port
> is registered. This has some adverse effect, as the third port has not
> been discovered yet...
> 
> This patch, tested on my own E250 through an RSC console, hides the
> problem by defering the console setup until the port has been properly
> initialized.
> 
> Dave, please consider applying.
> 
> 	M.
> 
> This patch fixes yet another sunsab problem, when console is set to
> anything but the first port. The console framework calls
> sunsab_console_setup for each port, and we end up setting up a console
> on a not yet discovered port, which leads to an Oops. Instead, defer
> console setup until the requested port is properly initialized. Tested
> on an E250 through an RSC console.
> 
> Reported by Daniel Smolik <marvin@mydatex.cz>
> 
> Signed-off-by: Marc Zyngier <maz@misterjones.org>
> 
> diff --git a/drivers/serial/sunsab.c b/drivers/serial/sunsab.c
> index dc673e1..077c201 100644
> --- a/drivers/serial/sunsab.c
> +++ b/drivers/serial/sunsab.c
> @@ -886,6 +886,15 @@ static int sunsab_console_setup(struct c
>  	unsigned long flags;
>  	unsigned int baud, quot;
>  
> +	/*
> +	 * The console framework calls us for each and every port
> +	 * registered. Defer the console setup until the requested
> +	 * port has been properly discovered. A bit of a hack,
> +	 * though...
> +	 */
> +	if (up->port.type != PORT_SUNSAB)
> +		return -1;
> +	
>  	printk("Console: ttyS%d (SAB82532)\n",
>  	       (sunsab_reg.minor - 64) + con->index);
>  
> 

Thanks Marc for patch. It works great for me. No crash  and my E250 now boots.
But in dmesg i found this:
  se@14,200000: ttyS3 at MMIO 0x1fff1200040 (irq = 8) is a SAB82532 V3.2
I mean that my E250 have only 2 ports + RSC console. Am I right ?

			Dan

Re: [PATCH] Fix E250 console with RSC

[Marc Zyngier]

>>>>> "Daniel" = Daniel Smolik <marvin@mydatex.cz> writes:

Daniel> Thanks Marc for patch. It works great for me. No crash and my
Daniel> E250 now boots.

Thanks for testing.

Daniel> But in dmesg i found this:
Daniel>  se@14,200000: ttyS3 at MMIO 0x1fff1200040 (irq = 8) is a SAB82532 V3.2
Daniel> I mean that my E250 have only 2 ports + RSC console. Am I right ?

That's expected.

The E250 contains two SAB82532. One is wired to ttya and ttyb
(resp. ttyS0 and ttyS1), and the other has its first port wired to the
RSC (ttyS2). The last port, detected as ttyS3 is probably used to
manage the RSC itself (creating users and such, using the Solaris
tools):

maz@positive:/proc/openprom/aliases$ cat tty[cd]
/pci@1f,4000/ebus@1/se@14,200000:ssp
/pci@1f,4000/ebus@1/se@14,200000:sspctl

Would be nice to understand the protocol between the E250 and the RSC
(so we could have proper Linux tools to manage it), but I'm not sure
Sun ever made it public...

	M.
-- 
And if you don't know where you're going, any road will take you there...

Re: [PATCH] Fix E250 console with RSC

[Eric Brower]

On 8/5/06, Marc Zyngier <maz@misterjones.org> wrote:

> Would be nice to understand the protocol between the E250 and the RSC
> (so we could have proper Linux tools to manage it), but I'm not sure
> Sun ever made it public...

I don't believe it was ever made public.  Eddie Dost did a bit of
poking at it a short while back, and I've considered taking a look as
part of the "other end" of SUNW,envctrltwo but have not yet done so.
The envctrltwo driver can dump the static configuration of the RSC,
which is a bit of a help for "lockouts" but not sufficient for
management.

-- 
E

Re: [PATCH] Fix E250 console with RSC

[Daniel Smolik]

Eric Brower napsal(a):
> On 8/5/06, Marc Zyngier <maz@misterjones.org> wrote:
> 
>> Would be nice to understand the protocol between the E250 and the RSC
>> (so we could have proper Linux tools to manage it), but I'm not sure
>> Sun ever made it public...
> 
> 
> I don't believe it was ever made public.  Eddie Dost did a bit of
> poking at it a short while back, and I've considered taking a look as
> part of the "other end" of SUNW,envctrltwo but have not yet done so.
> The envctrltwo driver can dump the static configuration of the RSC,
> which is a bit of a help for "lockouts" but not sufficient for
> management.
> 

But you say me  that is possible craate or delete user account for RSC via 
envctrltwo and piece of software. Only one thing that I use Solaris was creating 
RSC user account because I get E250 without RSC user account. All other thing I 
can do under linux.

			Dan

Re: [PATCH] Fix E250 console with RSC

[Eric Brower]

On 8/6/06, Daniel Smolik <marvin@mydatex.cz> wrote:
> Eric Brower napsal(a):
> > On 8/5/06, Marc Zyngier <maz@misterjones.org> wrote:
> >
> >> Would be nice to understand the protocol between the E250 and the RSC
> >> (so we could have proper Linux tools to manage it), but I'm not sure
> >> Sun ever made it public...
> >
> >
> > I don't believe it was ever made public.  Eddie Dost did a bit of
> > poking at it a short while back, and I've considered taking a look as
> > part of the "other end" of SUNW,envctrltwo but have not yet done so.
> > The envctrltwo driver can dump the static configuration of the RSC,
> > which is a bit of a help for "lockouts" but not sufficient for
> > management.
> >
>
> But you say me  that is possible craate or delete user account for RSC via
> envctrltwo and piece of software. Only one thing that I use Solaris was creating
> RSC user account because I get E250 without RSC user account. All other thing I
> can do under linux.

With the envctrltwo driver and the rscinfo utility you can view the
static configuration of the RSC, but you cannot modify it.  Currently,
you can only modify the configuration via the RSC shell or Solaris
rscadm so far as I am aware.

-- 
E

Re: [PATCH] Fix E250 console with RSC

[Daniel Smolik]

Eric Brower napsal(a):
> On 8/6/06, Daniel Smolik <marvin@mydatex.cz> wrote:
> 
>> Eric Brower napsal(a):
>> > On 8/5/06, Marc Zyngier <maz@misterjones.org> wrote:
>> >
>> >> Would be nice to understand the protocol between the E250 and the RSC
>> >> (so we could have proper Linux tools to manage it), but I'm not sure
>> >> Sun ever made it public...
>> >
>> >
>> > I don't believe it was ever made public.  Eddie Dost did a bit of
>> > poking at it a short while back, and I've considered taking a look as
>> > part of the "other end" of SUNW,envctrltwo but have not yet done so.
>> > The envctrltwo driver can dump the static configuration of the RSC,
>> > which is a bit of a help for "lockouts" but not sufficient for
>> > management.
>> >
>>
>> But you say me  that is possible craate or delete user account for RSC 
>> via
>> envctrltwo and piece of software. Only one thing that I use Solaris 
>> was creating
>> RSC user account because I get E250 without RSC user account. All 
>> other thing I
>> can do under linux.
> 
> 
> With the envctrltwo driver and the rscinfo utility you can view the
> static configuration of the RSC, but you cannot modify it.  Currently,
> you can only modify the configuration via the RSC shell or Solaris
> rscadm so far as I am aware.
> 
I uderstatd, I mean that is possible write software that can do this.
I mean that whith envctrl driver is possible write some data back to RSC memory 
area. Am I right ?

			Dan

Re: [PATCH] Fix E250 console with RSC

[Eric Brower]

On 8/8/06, Daniel Smolik <marvin@mydatex.cz> wrote:
> Eric Brower napsal(a):
> > On 8/6/06, Daniel Smolik <marvin@mydatex.cz> wrote:
> >
> >> Eric Brower napsal(a):
> >> > On 8/5/06, Marc Zyngier <maz@misterjones.org> wrote:
> >> >
> >> >> Would be nice to understand the protocol between the E250 and the RSC
> >> >> (so we could have proper Linux tools to manage it), but I'm not sure
> >> >> Sun ever made it public...
> >> >
> >> >
> >> > I don't believe it was ever made public.  Eddie Dost did a bit of
> >> > poking at it a short while back, and I've considered taking a look as
> >> > part of the "other end" of SUNW,envctrltwo but have not yet done so.
> >> > The envctrltwo driver can dump the static configuration of the RSC,
> >> > which is a bit of a help for "lockouts" but not sufficient for
> >> > management.
> >> >
> >>
> >> But you say me  that is possible craate or delete user account for RSC
> >> via
> >> envctrltwo and piece of software. Only one thing that I use Solaris
> >> was creating
> >> RSC user account because I get E250 without RSC user account. All
> >> other thing I
> >> can do under linux.
> >
> >
> > With the envctrltwo driver and the rscinfo utility you can view the
> > static configuration of the RSC, but you cannot modify it.  Currently,
> > you can only modify the configuration via the RSC shell or Solaris
> > rscadm so far as I am aware.
> >
> I uderstatd, I mean that is possible write software that can do this.
> I mean that whith envctrl driver is possible write some data back to RSC memory
> area. Am I right ?

I am not sure-- overwriting the static configuration data may not take
effect until the RSC is reset (I cannot confirm this; I've not tried).
 It would be preferable to determine the interface used by rscadm and
make use of it.

Thanks,
E

>
>                         Dan
>
>


-- 
E

Re: [PATCH] Fix E250 console with RSC

[David Miller]

From: Marc Zyngier <maz@misterjones.org>
Date: Sat, 05 Aug 2006 10:59:12 +0200

> Dave, please consider applying.
> 
> 	M.
> 
> This patch fixes yet another sunsab problem, when console is set to
> anything but the first port. The console framework calls
> sunsab_console_setup for each port, and we end up setting up a console
> on a not yet discovered port, which leads to an Oops. Instead, defer
> console setup until the requested port is properly initialized. Tested
> on an E250 through an RSC console.
> 
> Reported by Daniel Smolik <marvin@mydatex.cz>
> 
> Signed-off-by: Marc Zyngier <maz@misterjones.org>

Thanks for figuring this out Marc.  I'll apply your patch,
and write a similar one for sunzilog which has the same
problem potentially.

This all comes from the fact that the UART layer assosciates
consoles with the driver instead of the individual ports.
In fact, the first thing serial_core.c does when you register
a port is go:

	port->cons = drv->cons;

which just makes this assosciation even more obviously illogical.

If, instead, the driver could set port->cons itself before the
uart_add_one_port() call, we could deal with this cleanly.

You will note that the 8250.c driver and others do similar
checks in their console setup method to work around this:

	if (!port->iobase && !port->membase)
		return -ENODEV;

Anyways, thanks again Marc.