[parisc-linux] LONG pause on boot

[parisc-linux] LONG pause on boot

[Tom]

Having brought the C180 back to life... Kernel 2.4.18-pa59 looks, boots
and works normally. I downloaded and compiled 2.4.19-pa24, which froze at
"branching to kernel entry point...". Rechecked config, recompiled, same
result. I left it hung for a few minutes, as I've seen delays here before,
then while searching the web and the list archives for solutions it
started again. Delay was over 10 minutes, pushing 20 perhaps. After it
came up, I ssh'd in and restarted it. Same delay, same place...

Does anyone have an idea as to why such a long delay would occur there?
PDC has console to serial_1, which had a terminal on it. There was no
errors or complaints anywhere in the boot process, and none visible during
the kernel compile. I can provide System.map, config file, etc. if
desired...

Re: [parisc-linux] LONG pause on boot

[Matthew Wilcox]

On Wed, Nov 13, 2002 at 10:26:43AM -0900, Tom wrote:
> Does anyone have an idea as to why such a long delay would occur there?
> PDC has console to serial_1, which had a terminal on it. There was no
> errors or complaints anywhere in the boot process, and none visible during
> the kernel compile. I can provide System.map, config file, etc. if
> desired...

Yes, it's during device walk.  The support for E class that rbrad wrote
means that every machine with a CCIO suffers.  I suspect this'll get
fixed fairly soon.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] LONG pause on boot

[Tom]

> On Wed, Nov 13, 2002 at 10:26:43AM -0900, Tom wrote:
> > Does anyone have an idea as to why such a long delay would occur there?
> > PDC has console to serial_1, which had a terminal on it. There was no
> > errors or complaints anywhere in the boot process, and none visible during
> > the kernel compile. I can provide System.map, config file, etc. if
> > desired...

> On Wed, 13 Nov 2002, Matthew Wilcox wrote:
> Yes, it's during device walk.  The support for E class that rbrad wrote
> means that every machine with a CCIO suffers.  I suspect this'll get
> fixed fairly soon.

Then I'll assume it's a "feature", at least until sometime in the 2.4.20
range :-)

Thanks!

Re: [parisc-linux] LONG pause on boot

[Ryan Bradetich]

On Wed, Nov 13, 2002 at 07:30:18PM +0000, Matthew Wilcox wrote:
> On Wed, Nov 13, 2002 at 10:26:43AM -0900, Tom wrote:
> > Does anyone have an idea as to why such a long delay would occur there?
> > PDC has console to serial_1, which had a terminal on it. There was no
> > errors or complaints anywhere in the boot process, and none visible during
> > the kernel compile. I can provide System.map, config file, etc. if
> > desired...
> 
> Yes, it's during device walk.  The support for E class that rbrad wrote
> means that every machine with a CCIO suffers.  I suspect this'll get
> fixed fairly soon.

Willy, I have an idea on how to fix this, but it is ugly ... but I will probably
consider committing it soon unless you have a cleaner idea (hint, hint :))

The problem is with E-Class ... the devices are at the end of the bus range.  We
need to walk the entire bus until we find the range the drivers exist in.  On
systems where the devices are at the end (or no devices in that range) the entire
bus needs to be walked.... this is the delay you are seeing.

I have a proposal to speed up systems where the devices are at the end of the
bus ... we can simply walk the first bus range, then the last bus range, if
nothing found yet ... walk the middle.

I do not have a solution for a bus with no devices present yet ...

Thanks,

- Ryan





> 
> -- 
> Revolutions do not require corporate support.
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
> 

-- 

Re: [parisc-linux] LONG pause on boot

[Matthew Wilcox]

On Wed, Nov 13, 2002 at 02:46:13PM -0700, Ryan Bradetich wrote:
> Willy, I have an idea on how to fix this, but it is ugly ... but I will probably
> consider committing it soon unless you have a cleaner idea (hint, hint :))

Well.  I have an idea, but it's even uglier than yours ;-)  It doesn't suffer
from the same problem, so I'll describe it...

> I have a proposal to speed up systems where the devices are at the end of the
> bus ... we can simply walk the first bus range, then the last bus range, if
> nothing found yet ... walk the middle.

here's the current code:

#define READ_IO_IO_LOW(dev) \
        (dev->id.hw_type == HPHW_IOA ? \
                __raw_readl((unsigned long)&((struct bc_module *)dev->hpa)->io_i
o_low) << 16 : \
                __raw_readl((unsigned long)&((struct bc_module *)dev->hpa)->io_i
o_low))

#define READ_IO_IO_HIGH(dev) \
        (dev->id.hw_type == HPHW_IOA ? \
                __raw_readl((unsigned long)&((struct bc_module *)dev->hpa)->io_i
o_high) << 16 : \
                __raw_readl((unsigned long)&((struct bc_module *)dev->hpa)->io_i
o_high))


static void walk_native_bus(unsigned long io_io_low, unsigned long io_io_high, 
                            struct parisc_device *parent);

#define FLEX_MASK (unsigned long)0xfffffffffffc0000

void walk_lower_bus(struct parisc_device *dev)
{
        unsigned long io_io_low, io_io_high;

        if(!BUS_CONVERTER(dev) || IS_LOWER_PORT(dev))
                return;

        io_io_low = ((unsigned long)(signed int)READ_IO_IO_LOW(dev) + ~FLEX_MASK
) & FLEX_MASK;
        io_io_high = ((unsigned long)(signed int)READ_IO_IO_HIGH(dev) + ~FLEX_MA
SK) & FLEX_MASK;

        walk_native_bus(io_io_low, io_io_high, dev);
}

My proposal...

#define IO_IO_LOW	offsetof(struct bc_module, io_io_low)
#define IO_IO_HIGH	offsetof(struct bc_module, io_io_high)
#define READ_IO_IO_LOW(dev) __raw_readl(dev->hpa + IO_IO_LOW)
#define READ_IO_IO_HIGH(dev) __raw_readl(dev->hpa + IO_IO_HIGH)

void walk_lower_bus(struct parisc_device *dev)
{
	unsigned long io_io_low, io_io_high;

	if (!BUS_CONVERTER(dev) || IS_LOWER_PORT(dev))
		return;

	if (dev->id.hw_type == HPHW_IOA) {
		io_io_low = (unsigned long)(signed int)(READ_IO_IO_LOW(dev) << 16);
		io_io_high = io_io_low + MAX_NATIVE_DEVICES * NATIVE_DEVICE_OFFSET;
	} else {
		io_io_low = (READ_IO_IO_LOW(dev) + ~FLEX_MASK) & FLEX_MASK;
		io_io_high = (READ_IO_IO_HIGH(dev)+ ~FLEX_MASK) & FLEX_MASK;
	}
	walk_native_bus(io_io_low, io_io_high, dev);
}

-- 
Revolutions do not require corporate support.