[parisc-linux] SuckyIO support

[parisc-linux] SuckyIO support

[Matthew Wilcox]

Wow, this is a really sucky chip :-)

OK, here's a first stab at some support for it.  Could someone with a
B/C/J `thousand' class machine please give it a try, and let me see the
relevant portions of their bootlog?

Obviously, this code only tries to set up the IRQ for the IDE driver
and doesn't attempt to address any of the other broken things this chip
requires, but it's architecturally in the right place.

It'd be really handy if I could get access to one of that class of machine
with remote console & remote rebooting facilities, but i should be near
a machine of that type in a couple of months anyway...

diff -u linux-cvs/drivers/pci/quirks.c linux-mine/drivers/pci/quirks.c
--- linux-cvs/drivers/pci/quirks.c	Fri Nov 10 21:43:18 2000
+++ linux-mine/drivers/pci/quirks.c	Tue Dec 19 09:27:28 2000
@@ -234,6 +234,25 @@
 	pci_read_config_word(dev, PCI_DEVICE_ID, &dev->device);
 }
 
+static void __init quirk_ns_87560(struct pci_dev *dev)
+{
+	switch (dev->device)
+	{
+		case PCI_DEVICE_ID_NS_87415:
+			break;
+		case PCI_DEVICE_ID_NS_87560_LIO:
+			{
+				struct pci_dev *ide_dev;
+				char irq;
+				ide_dev = pci_dev_b(dev->bus_list.prev);
+				pci_read_config_byte(dev, 0x6B, &irq);
+				ide_dev->irq = irq & 0xf;
+				printk("Assigned IRQ %d to IDE\n", ide_dev->irq);
+			}
+			break;
+	}
+}
+
 /*
  *  The main table of quirks.
  */
@@ -269,6 +288,7 @@
 	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_AL,	PCI_DEVICE_ID_AL_M7101,		quirk_ali7101_acpi },
  	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_82371SB_2,	quirk_piix3_usb },
 	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_82371AB_2,	quirk_piix3_usb },
+	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_NS,	PCI_ANY_ID,	quirk_ns_87560 },
 	{ 0 }
 };
 

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] SuckyIO support

[Alex deVries]

Matthew Wilcox wrote:
> 
> Wow, this is a really sucky chip :-)
> 
> OK, here's a first stab at some support for it.  Could someone with a
> B/C/J `thousand' class machine please give it a try, and let me see the
> relevant portions of their bootlog?

I've taken mkp's initial work on superio.c and added some stuff, but in
the end am confused by where we actually get the interrupt number from
the card.  There's no such register in function 1 (where the interrupts
ultimately end up) and both registers on function 0 and 2 return 0,
which I don't think is right.  I'd thought that PDC would have set this
up.  There's not much I can do at this point until we can have some of
Grant's attention.

In the meantime, I'll try booting with all of this on the C3k.

- Alex

-- 
Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare
613.562.2759 tel
alex@linuxcare.com, http://www.linuxcare.com/
Linuxcare, Support for the revolution.

Re: [parisc-linux] SuckyIO support

[Grant Grundler]

Alex deVries wrote:
...
> I've taken mkp's initial work on superio.c and added some stuff, but in
> the end am confused by where we actually get the interrupt number from
> the card.  There's no such register in function 1 (where the interrupts
> ultimately end up) and both registers on function 0 and 2 return 0,
> which I don't think is right.

Why are you reading this out of a register? Which register?

IIRC, function 0 and 2 *should* return 0 in INTERRUPT_PIN configuration
register and thus the INTERRUPT_LINE configuration as well.
But since IOSAPIC driver (when invoked by LBA PCI code) munges the
INTERRUPT_LINE contents and puts the virtualized IRQ number in 
dev->irq for the drivers consumption, superio driver should
not be reading these configuration registers.

> I'd thought that PDC would have set this up.

PDC should only sets up the PCI INTERRUPT_LINE config register values
to indicate which IOSAPIC input *line* they are using. parisc-linux has
to map this value to an IRQ region and virtualize the dev->irq value.

> There's not much I can do at this point until we can have some of
> Grant's attention.

If what I wrote above doesn't make any sense, tell me where to
to find the code you are talking about and I can look at it.

grant

Grant Grundler
Unix Systems Enablement Lab
+1.408.447.7253

Re: [parisc-linux] SuckyIO support

[Alex deVries]

Grant Grundler wrote:
> Alex deVries wrote:
> > I've taken mkp's initial work on superio.c and added some stuff, but in
> > the end am confused by where we actually get the interrupt number from
> > the card.  There's no such register in function 1 (where the interrupts
> > ultimately end up) and both registers on function 0 and 2 return 0,
> > which I don't think is right.
> 
> Why are you reading this out of a register? Which register?

I'm reading it out of the INTERRUPT_LINE register because that's how
'normal' PCI devices set their dev->irq value.  If you say that's the
right approach, I believe you.

> IIRC, function 0 and 2 *should* return 0 in INTERRUPT_PIN configuration
> register and thus the INTERRUPT_LINE configuration as well.

Ah, good.

> But since IOSAPIC driver (when invoked by LBA PCI code) munges the
> INTERRUPT_LINE contents and puts the virtualized IRQ number in
> dev->irq for the drivers consumption, superio driver should
> not be reading these configuration registers.

Okay... but I get zero in dev->irq already, so I'm not sure the IOSAPIC
driver is virtualizing them properly.

Grant, I'll email the driver to you, Grant, to have a look at.

Thanks for your help!

- Alex

-- 
Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare
613.562.2759 tel
alex@linuxcare.com, http://www.linuxcare.com/
Linuxcare, Support for the revolution.

Re: [parisc-linux] SuckyIO support

[Alan Cox]

> > Why are you reading this out of a register? Which register?
> 
> I'm reading it out of the INTERRUPT_LINE register because that's how
> 'normal' PCI devices set their dev->irq value.  If you say that's the
> right approach, I believe you.

INTERRUPT_PIN is pre-PCI plumbing view of the interrupt
INTERRUPT_LINE is sort of the PCI view of the interrupt at best
pci_dev->irq is the Linux view post all the plumbing and host goo

Re: [parisc-linux] SuckyIO support

[Grant Grundler]

Let me elaborate a bit on Alan's terse explanation.

Alan Cox wrote:
> INTERRUPT_PIN is pre-PCI plumbing view of the interrupt

PIN is the *output* signal used by the PCI device. Each PCI device
is defined to use none, or one of four available INT signals (A-D).
PIN is hardwired value to indicate which it is.

> INTERRUPT_LINE is sort of the PCI view of the interrupt at best

LINE is initialized by BIOS or platform knowledgable code.
LINE is the *input* signal to an interrupt controller.
The routing of Interrupt Lines is *platform dependent* and is
generally different for each PCI device.
ie INT-A for one device != INT-A for another

> pci_dev->irq is the Linux view post all the plumbing and host goo

In our case, it's the IRQ region plus IRQ offset right now.
I've proposed another IRQ scheme which would replace the math with
a lookup table. But we haven't done anything with it yet since
the region+offset is "good enough" for now.

grant

Grant Grundler
Unix Systems Enablement Lab
+1.408.447.7253

Re: [parisc-linux] SuckyIO support

[Alan Cox]

> In our case, it's the IRQ region plus IRQ offset right now.
> I've proposed another IRQ scheme which would replace the math with
> a lookup table. But we haven't done anything with it yet since
> the region+offset is "good enough" for now.

Providing dev->irq is a suitable size putting a pointer into it is also 
perfectly acceptable although it makes the error reports look odd. Which
reminds me that someday we need canonicalise_irq(irq) for reporting stuff
nicely cross arch

Re: [parisc-linux] SuckyIO support

[Grant Grundler]

Alan Cox wrote:
> > In our case, it's the IRQ region plus IRQ offset right now.
> > I've proposed another IRQ scheme which would replace the math with
> > a lookup table. But we haven't done anything with it yet since
> > the region+offset is "good enough" for now.
> 
> Providing dev->irq is a suitable size putting a pointer into

only for 32-bit ILP. 64-bit LP (hppa) can't do that.
"int" is only 32-bits for both. Good idea though.

HP-UX has used "intr_obj" (iirc, void *) since 10.x and probably before.
The idea of a lookup table (I mentioned it above) would be obsoleted by
dev->irq defined as void *.
Maybe 2.5 kernel could use void * for dev->irq?

grant

Grant Grundler
Unix Systems Enablement Lab
+1.408.447.7253

Re: [parisc-linux] SuckyIO support

[Matthew Wilcox]

On Tue, Dec 19, 2000 at 06:56:32PM -0800, Grant Grundler wrote:
> Why are you reading this out of a register? Which register?

The chip is so b0rken that it doesn't put its irq number in the standard
register -- reads return 0.  So the quirk code I wrote pulls the irq
number from a different register on the chip -- which i now believe to
be incorrect.

> IIRC, function 0 and 2 *should* return 0 in INTERRUPT_PIN configuration
> register and thus the INTERRUPT_LINE configuration as well.
> But since IOSAPIC driver (when invoked by LBA PCI code) munges the
> INTERRUPT_LINE contents and puts the virtualized IRQ number in 
> dev->irq for the drivers consumption, superio driver should
> not be reading these configuration registers.

That's OK, at least for the code I wrote, the quirk code is called in the
right place (ie before the iosapic code gets its hands on it) that if it can
find the right value and poke it back into dev->irq, the iosapic virtualising
code will deal with it correctly.

> If what I wrote above doesn't make any sense, tell me where to
> to find the code you are talking about and I can look at it.

i'd like to see this code too.  why not commit it to the tree?  it's not
like it works at the moment and things would get broken.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] SuckyIO support

[Alex deVries]

Matthew Wilcox wrote:
> The chip is so b0rken that it doesn't put its irq number in the standard
> register -- reads return 0.  So the quirk code I wrote pulls the irq
> number from a different register on the chip -- which i now believe to
> be incorrect.

I don't think that's right either...  register 6B is an IDE interrupt
routing register, not the interrupt itself.

If the iosapic system is supposed to remap the register, I don't think
it is and I don't know where this is supposed to happen.  I hope we can
do all of this using just a PCI quirk.

> i'd like to see this code too.  why not commit it to the tree?  it's not
> like it works at the moment and things would get broken.

I've committed it, and it definitely does not work, but I don't think
it'll break anything either.  This is mostly mkp's code.

- Alex

-- 
Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare
613.562.2759 tel
alex@linuxcare.com, http://www.linuxcare.com/
Linuxcare, Support for the revolution.

Re: [parisc-linux] SuckyIO support

[Grant Grundler]

Matthew Wilcox wrote:
> That's OK, at least for the code I wrote, the quirk code is called in the
> right place (ie before the iosapic code gets its hands on it) that if it can
> find the right value and poke it back into dev->irq, the iosapic virtualising
> code will deal with it correctly.

It won't. I just checked. :^(

lba_fixup_bus() invokes iosapic_fixup_irq() for each PCI device.
iosapic_fixup_irq() invokes iosapic_xlate_pin() to locate both the
INTERRUPT_LINE and parent IOSAPIC. xlate_pin reads the INTERRUPT_PIN
and *ignores* the INTERRUPT_LINE. This behavior has to remain in order
to support PAT PDC platforms (which do not initialize the PCI device).

I doubt we can use pci_quirks to fixup the dev->irq.
I've proposed to Alex to use a "bus devices" scheme (a' la LASI).
So some "central" code will manage IRQ routing for devices below suckyio.
I.e. suckyio will have it's own IRQ region and collectively manage
all three PCI functions as "one device".

This would be the first case in parisc-linux where we "stack" three
IRQ regions on top of each other: driver->suckyio->iosapic->CPU

glad I could help,
grant

Grant Grundler
Unix Systems Enablement Lab
+1.408.447.7253

Re: [parisc-linux] SuckyIO support

[Matthew Wilcox]

On Wed, Dec 20, 2000 at 10:24:36AM -0800, Grant Grundler wrote:
> Matthew Wilcox wrote:
> > That's OK, at least for the code I wrote, the quirk code is called in the
> > right place (ie before the iosapic code gets its hands on it) that if it can
> > find the right value and poke it back into dev->irq, the iosapic virtualising
> > code will deal with it correctly.
> 
> It won't. I just checked. :^(
> 
> lba_fixup_bus() invokes iosapic_fixup_irq() for each PCI device.
> iosapic_fixup_irq() invokes iosapic_xlate_pin() to locate both the
> INTERRUPT_LINE and parent IOSAPIC. xlate_pin reads the INTERRUPT_PIN
> and *ignores* the INTERRUPT_LINE. This behavior has to remain in order
> to support PAT PDC platforms (which do not initialize the PCI device).

To my mind, we're doing this backwards.  What the current code tries to do
is recover from a situation where the generic PCI code has been run over
a bus which hasn't been configured by the POST -- and in the process we
lose any work done by the quirk code.  What I _think_ we should be doing
instead is doing our own run over the PCI bus first before the generic
code gets a look at it, and sorting out the interrupt routing there.
Then we can write the appropriate values into INTERRUPT_LINE, which the
generic PCI bus scan code will pick up and the quirk code will propogate
it into the other functions.

> I doubt we can use pci_quirks to fixup the dev->irq.
> I've proposed to Alex to use a "bus devices" scheme (a' la LASI).
> So some "central" code will manage IRQ routing for devices below suckyio.
> I.e. suckyio will have it's own IRQ region and collectively manage
> all three PCI functions as "one device".

We can do that.  But we don't _need_ to, all these devices are capable of
sharing one IRQ without further interrupt decoding being done.  I'm not
sure we want to do it -- extra latency and more code versus more interrupt
handers being called.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] SuckyIO support

[Grant Grundler]

Matthew Wilcox wrote:
> On Wed, Dec 20, 2000 at 10:24:36AM -0800, Grant Grundler wrote:
...
> > xlate_pin reads the INTERRUPT_PIN and *ignores* the INTERRUPT_LINE.
...
> To my mind, we're doing this backwards.  What the current code tries to do
> is recover from a situation where the generic PCI code has been run over
> a bus which hasn't been configured by the POST -- and in the process we
> lose any work done by the quirk code.

INTERRUPT_PIN is zero for function 0 and 1. And according to PCI spec,
suckyio function 0 and 1 can't won't generate interrupts regardless
of what's in INTERRUPT_LINE.
I don't want to write/modify/support code that implies otherwise.

> What I _think_ we should be doing
> instead is doing our own run over the PCI bus first before the generic
> code gets a look at it, and sorting out the interrupt routing there.

We'll end duplicating much of what's in the generic PCI code basically.
You can understand why I might be less than enthusiastic about this idea.

> Then we can write the appropriate values into INTERRUPT_LINE, which the
> generic PCI bus scan code will pick up and the quirk code will propogate
> it into the other functions.

For function 2, the proper value (0) *is* already in INTERRUPT_LINE.
And because of the INTERRUPT_PIN behavior, I'd like to discourage
propagating config values from function 2 into other suckyio functions.

> > So some "central" code will manage IRQ routing for devices below suckyio.
...
> We can do that.  But we don't _need_ to, all these devices are capable of
> sharing one IRQ without further interrupt decoding being done.

Yeah - you might be right : Sub-devices will share one IRQ line.
Using an IRQ region only makes sense if we can read some register and
uniquely determine which device(s) generated the interrupt(s). But this
is more an implementation detail than design corner stone.

Regardless, I'd still like to see a central code determine which IRQ line
is used and advertise devices so other drivers can claim them. ie this
suckyio code would propogate the virtualized func2 dev->irq to sub-devices
and manage all three suckyio functions as one device like LASI.

thanks,
grant

Re: [parisc-linux] SuckyIO support

[Matthew Wilcox]

On Mon, Dec 25, 2000 at 11:16:24PM -0800, Grant Grundler wrote:
> INTERRUPT_PIN is zero for function 0 and 1. And according to PCI spec,
> suckyio function 0 and 1 can't won't generate interrupts regardless
> of what's in INTERRUPT_LINE.
> I don't want to write/modify/support code that implies otherwise.

I thought it was understood that this device was not PCI-conforming?
That it did generate interrupts for functions 0 and 1.  Could we nail
down exactly _how_ this device generates interrupts for the serial & ide
ports?  I can see a few possibilities:

(1) They are only generated on the CPUINT pin.
(2) They're generated on INTD# just like USB is
(3) They're routable to other PCI pins within the device (i doubt it,
    i can't see any hint of this in the spec).
(4) The interrupts are generated but they're not routed to anywhere the
    cpu will ever get notified about, so we have to use a polling driver.
    This would seriously suck.

if it's (1), what is CPUINT tied to?  does it have its own connection to
the IOSAPIC?  Is it connected to the PCI bus somehow?

> We'll end duplicating much of what's in the generic PCI code basically.
> You can understand why I might be less than enthusiastic about this idea.

Yes.  OK, better idea: we can do the quirk fixup in the PCI_FIXUP_FINAL
pass instead of the PCI_FIXUP_HEADER pass.  This is called after the bus
fixup code has set ->irq.  Of course, this might be completely the wrong
thing to do... I really need to know the answer to the above question.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] SuckyIO support

[Grant Grundler]

Matthew Wilcox wrote:
> On Mon, Dec 25, 2000 at 11:16:24PM -0800, Grant Grundler wrote:
> > INTERRUPT_PIN is zero for function 0 and 1. And according to PCI spec,
> > suckyio function 0 and 1 can't won't generate interrupts regardless
> > of what's in INTERRUPT_LINE.
> > I don't want to write/modify/support code that implies otherwise.
> 
> I thought it was understood that this device was not PCI-conforming?

Absolutely correct.

> That it did generate interrupts for functions 0 and 1.

Not directly. AFAICT, subdevices can only generate interrupts via 8259
which lives on function 1. And it looks like *none* of the functions
under suckyio implement INTERRUPT_PIN register. *sigh*

The INTERRUPT_LINE cfg register just happens to live under function 2
but could live in any of the three functions. Suckyio provides this
register merely as a convience to the BIOS/OS programmers.

> Could we nail
> down exactly _how_ this device generates interrupts for the serial & ide
> ports?
...

IRQs for all devices we care about are routed through the on-chip 8259's.
Master 8259 output is routed to INTERRUPT_LINE 0 of the parent IOSAPIC.
I can't tell if that's through CPUINT or INT[A-D] or what.

BTW, I suggest suckyio get it's own IRQ region to manage the 8259's.
Here are more notes:

 *      Most interrupt sources can be routed (or mapped) to interrupt pins on
 *      the 8259.  The available pins are (15-14, 12-9, 7-3, 1).  The following
 *      pins are dedicated.
 *
 *              Timer Out0        Channel 0
 *              8259 cascade      Channel 2
 *              Real-Time Clock   Channel 8
 *              Coprocessor Error Channel 13
 *
 *
 *      There are only 6 interrupt sources supported at this time.  These
 *      take up all the available interrupt sources on the master 8259.  The
 *      slave mode code has not been tested completely because we do not use
 *      it.  Note that the interrupt sources are given fixed interrupt routing.


FYI - The 8259 "fixed" routing used by HPUX is below.
Though I have the impression PNP code could be used to assign
IRQ lines if one doesn't want another LASI-like IRQ scheme.

   switch (obj->suio_device_id) {
      case SUPERIO_ID_UART1:
        obj->suio_irq = 3;
        break;

      case SUPERIO_ID_UART2:
        obj->suio_irq = 4;
        break;

      case SUPERIO_ID_FDC:
        obj->suio_irq = 6;
        break;

      case SUPERIO_ID_PARALLEL:
        obj->suio_irq = 5;
        break;

      case SUPERIO_ID_USB:
        obj->suio_irq = 1;
        break;

      case SUPERIO_ID_IDE:
        obj->suio_irq = 7;       /* XXX IDE has two channels? */
        break;

      default:
        VASSERT(0 == 1);
    }


> > We'll end duplicating much of what's in the generic PCI code basically.
> > You can understand why I might be less than enthusiastic about this idea.
> 
> Yes.  OK, better idea: we can do the quirk fixup in the PCI_FIXUP_FINAL
> pass instead of the PCI_FIXUP_HEADER pass.  This is called after the bus
> fixup code has set ->irq.  Of course, this might be completely the wrong
> thing to do... I really need to know the answer to the above question.

This does sound better given suckyio doesn't support INTERRUPT_PIN.

The fixup code could use Function 2 INTERRUPT_LINE to determine which
iosapic input line is being used (instead of assuming line 0). I'm thinking
we need to add another iosapic_fixup()-like interface so PCI quirks code
will correctly register suckyio's INTERRUPT_LINE. I'm trying to keep the
method iosapic virtualizes IRQs with private to iosapic.c.

thanks,
grant

Re: [parisc-linux] SuckyIO support

[Matthew Wilcox]

On Tue, Dec 19, 2000 at 09:42:51AM +0000, Matthew Wilcox wrote:
> 
> Wow, this is a really sucky chip :-)
> 
> OK, here's a first stab at some support for it.  Could someone with a
> B/C/J `thousand' class machine please give it a try, and let me see the
> relevant portions of their bootlog?

See if this is a better quirk.

Index: drivers/pci/quirks.c
===================================================================
RCS file: /home/cvs/parisc/linux/drivers/pci/quirks.c,v
retrieving revision 1.6
diff -u -p -r1.6 quirks.c
--- quirks.c	2000/11/10 21:43:18	1.6
+++ quirks.c	2000/12/23 09:10:55
@@ -234,6 +234,32 @@ static void __init quirk_vt82c598_id(str
 	pci_read_config_word(dev, PCI_DEVICE_ID, &dev->device);
 }
 
+static void __init quirk_ns_87560(struct pci_dev *dev)
+{
+	static int count = 0; /* So we don't lose if they reuse their IDs. */
+	switch (dev->device)
+	{
+		case PCI_DEVICE_ID_NS_87415:
+		case PCI_DEVICE_ID_NS_87560_LIO:
+			count++;
+			break;
+		case PCI_DEVICE_ID_NS_87560_USB:
+			if (count != 2) {
+				count = 0;
+				break;
+			}
+			{
+				struct pci_dev *old_dev;
+				old_dev = pci_dev_b(dev->bus_list.prev);
+				old_dev->irq = dev->irq;
+				old_dev = pci_dev_b(old_dev->bus_list.prev);
+				old_dev->irq = dev->irq;
+				printk("Assigned IRQ %d to SuckyIO\n", dev->irq);
+			}
+			break;
+	}
+}
+
 /*
  *  The main table of quirks.
  */
@@ -269,6 +295,7 @@ static struct pci_fixup pci_fixups[] __i
 	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_AL,	PCI_DEVICE_ID_AL_M7101,		quirk_ali7101_acpi },
  	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_82371SB_2,	quirk_piix3_usb },
 	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_INTEL,	PCI_DEVICE_ID_INTEL_82371AB_2,	quirk_piix3_usb },
+	{ PCI_FIXUP_HEADER,	PCI_VENDOR_ID_NS,	PCI_ANY_ID,	quirk_ns_87560 },
 	{ 0 }
 };
 

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] SuckyIO support

[Alex deVries]

Matthew Wilcox wrote:
> 
> On Tue, Dec 19, 2000 at 09:42:51AM +0000, Matthew Wilcox wrote:
> >
> > Wow, this is a really sucky chip :-)
> >
> > OK, here's a first stab at some support for it.  Could someone with a
> > B/C/J `thousand' class machine please give it a try, and let me see the
> > relevant portions of their bootlog?

I'm still determined to give this to you, but I've had several hurdles
that are making this difficult:

- our C3k seems to be taking the Christmas break as holiday, as she
doesn't power up anymore.  Martin Petersen and I have seen this before,
and a bit of shaking and rattling got it to work last time.  

- got a workout by moving the J5k over to my cube, and it now HPMCs
before I see any relevant boot output.  Not sure why.

- I'm travelling until January 2.

- Alex

-- 
Alex deVries, Principal Solutions Architect, The Puffins at Linuxcare
613.562.2759 tel
alex@linuxcare.com, http://www.linuxcare.com/
Linuxcare, Support for the revolution.