NS87415 on C3K broken

NS87415 on C3K broken

[Grant Grundler]

Hi,
Willy pointed out the 2.6.9-rc2 NS87415 driver for C3000 machine
(uses SuckyIO IDE) is causing HPMC (system crash). This was not
a problem with 2.6.8.1.
But while trying to fix MMIO resource management problems, I ran
into this when testing on C3000.

The HPMC stack trace looks like this:
	ide_inb
	ide_wait_not_busy
	wait_hwif_ready
	probe_hwif
	probe_hwif_init
	ide_setup_pci_device
	ns87415_init_one
	ide_scan_pcidev
	ide_scan_pcibus
	ide_init
	do_initcalls

Changes to ide-probe.c cause this HPMC.
wait_hwif_ready() is inside #ifdef CONFIG_PPC in 2.6.8.1 and the
ifdef/endif was removed in 2.6.9-rcX. The result is inb() is invoked
*BEFORE* ide_setup_pci_device() (indirectly) calls pci_enabled_device() or
pci_set_master(). This is broken because IDE controllers NOT enabled
by firmware will simply not respond to inb() (even if the system
doesn't crash like on parisc).

I'm a wimp. I don't dare to restructure IDE init sequence.
Anyone less of a wimp?
Or are IDE pci drivers required to call pci_enable_device()
in their (mostly non-extistent) init_chipset entry point?


Anyway, ns87415 driver has more problems. The patch below adds
"init_chipset" entry point and init_chipset_ns87415() calls
pci_enable_device() and pci_set_master() before the probe.
And my C3k still HPMCs. My guess is more of the code from
init_hwif_ns87415() needs to be moved to init_chipset_ns87415().
And possible call some special suckyio init routines.
I won't be able to touch this for a few days.
Anyone else on parisc-linux ml want to take a whack at this?

BTW, normally a PCI Master Abort to IO Port space to should NOT fail.
But on parisc is does because the chipset will go "fatal" on
any Master Abort - special hacks enable config space to work.
I strongly prefere not to add those hacks to IO Port space
accessor functions since it's normally not a problem.
And while inconvenient, this behavior does expose programming
problems like the one above.


thanks,
grant


Index: drivers/ide/pci/ns87415.c
===================================================================
RCS file: /var/cvs/linux-2.6/drivers/ide/pci/ns87415.c,v
retrieving revision 1.17
diff -u -p -r1.17 ns87415.c
--- drivers/ide/pci/ns87415.c	13 Sep 2004 15:23:04 -0000	1.17
+++ drivers/ide/pci/ns87415.c	16 Sep 2004 15:06:06 -0000
@@ -133,8 +133,29 @@ static int ns87415_ide_dma_check (ide_dr
 	return __ide_dma_check(drive);
 }
 
+static unsigned int __devinit init_chipset_ns87415(struct pci_dev *dev, const char *name)
+{
+	unsigned short w;
+printk("init_chipset_ns87415(%s,%s)\n", dev->slot_name, name);
+
+	pci_enable_device(dev);
+	pci_set_master(dev);
+
+(void) pci_read_config_word(dev, PCI_COMMAND, &w);
+printk("	cmd 0x%x\n", w);
+
+	if ((w & PCI_COMMAND_IO) == 0) {
+		w |= PCI_COMMAND_IO;
+		(void) pci_write_config_word(dev, PCI_COMMAND, w);
+printk("	enabling IO space\n");
+	}
+	return 0;
+}
+
+
 static void __init init_iops_ns87415(ide_hwif_t *hwif)
 {
+printk("init_iops_ns87415(%s)\n", hwif->pci_dev->slot_name);
 #ifdef CONFIG_SUPERIO
 	superio_ide_init_iops(hwif);
 #endif
@@ -150,12 +171,14 @@ static void __init init_hwif_ns87415 (id
 	u8 stat;
 #endif
 
+printk("init_hwif_ns87415(%s)\n", hwif->pci_dev->slot_name);
 	hwif->autodma = 0;
 	hwif->selectproc = &ns87415_selectproc;
 
+#if 0
 	/* Set a good latency timer and cache line size value. */
 	(void) pci_write_config_byte(dev, PCI_LATENCY_TIMER, 64);
-	/* FIXME: use pci_set_master() to ensure good latency timer value */
+#endif
 
 	/*
 	 * We cannot probe for IRQ: both ports share common IRQ on INTA.
@@ -227,6 +250,8 @@ static void __init init_hwif_ns87415 (id
 
 static ide_pci_device_t ns87415_chipset __devinitdata = {
 	.name		= "NS87415",
+	.init_chipset	= init_chipset_ns87415,
+	.init_iops	= init_iops_ns87415,
 	.init_hwif	= init_hwif_ns87415,
 	.channels	= 2,
 	.autodma	= AUTODMA,

Re: NS87415 on C3K broken

[Bartlomiej Zolnierkiewicz]

On Thursday 16 September 2004 18:17, Grant Grundler wrote:
> Hi,
> Willy pointed out the 2.6.9-rc2 NS87415 driver for C3000 machine
> (uses SuckyIO IDE) is causing HPMC (system crash). This was not
> a problem with 2.6.8.1.
> But while trying to fix MMIO resource management problems, I ran
> into this when testing on C3000.
> 
> The HPMC stack trace looks like this:
> 	ide_inb
> 	ide_wait_not_busy
> 	wait_hwif_ready
> 	probe_hwif
> 	probe_hwif_init
> 	ide_setup_pci_device
> 	ns87415_init_one
> 	ide_scan_pcidev
> 	ide_scan_pcibus
> 	ide_init
> 	do_initcalls
> 
> Changes to ide-probe.c cause this HPMC.
> wait_hwif_ready() is inside #ifdef CONFIG_PPC in 2.6.8.1 and the
> ifdef/endif was removed in 2.6.9-rcX. The result is inb() is invoked
> *BEFORE* ide_setup_pci_device() (indirectly) calls pci_enabled_device() or
> pci_set_master(). This is broken because IDE controllers NOT enabled
> by firmware will simply not respond to inb() (even if the system
> doesn't crash like on parisc).

I don't think ide-probe.c changes are the cause of HPMC.

probe_hwif_init() is only called after PCI device is fully setup,
see ide_setup_pci_device().

> I'm a wimp. I don't dare to restructure IDE init sequence.
> Anyone less of a wimp?
> Or are IDE pci drivers required to call pci_enable_device()
> in their (mostly non-extistent) init_chipset entry point?

ide_setup_pci_controller()
	-> ide_pci_enable()
		-> pci_enable_device()

and ide_setup_pci_controller() is called at the beginning
of ide_setup_pci_device() before ->init_chipset()

Ideally this should be done by host drivers
but moving this out of setup-pci.c is non-trivial.

> Anyway, ns87415 driver has more problems. The patch below adds
> "init_chipset" entry point and init_chipset_ns87415() calls
> pci_enable_device() and pci_set_master() before the probe.
> And my C3k still HPMCs. My guess is more of the code from
> init_hwif_ns87415() needs to be moved to init_chipset_ns87415().
> And possible call some special suckyio init routines.
> I won't be able to touch this for a few days.
> Anyone else on parisc-linux ml want to take a whack at this?
> 
> BTW, normally a PCI Master Abort to IO Port space to should NOT fail.
> But on parisc is does because the chipset will go "fatal" on
> any Master Abort - special hacks enable config space to work.
> I strongly prefere not to add those hacks to IO Port space
> accessor functions since it's normally not a problem.
> And while inconvenient, this behavior does expose programming
> problems like the one above.

Yep, also if they are to stay please move them to ns87415.c
because using <linux/ide.h> outside drivers/ide is WRONG.

> 
> thanks,
> grant
> 
> 
> Index: drivers/ide/pci/ns87415.c
> ===================================================================
> RCS file: /var/cvs/linux-2.6/drivers/ide/pci/ns87415.c,v
> retrieving revision 1.17
> diff -u -p -r1.17 ns87415.c
> --- drivers/ide/pci/ns87415.c	13 Sep 2004 15:23:04 -0000	1.17
> +++ drivers/ide/pci/ns87415.c	16 Sep 2004 15:06:06 -0000
> @@ -133,8 +133,29 @@ static int ns87415_ide_dma_check (ide_dr
>  	return __ide_dma_check(drive);
>  }
>  
> +static unsigned int __devinit init_chipset_ns87415(struct pci_dev *dev, const char *name)
> +{
> +	unsigned short w;
> +printk("init_chipset_ns87415(%s,%s)\n", dev->slot_name, name);
> +
> +	pci_enable_device(dev);
> +	pci_set_master(dev);
> +
> +(void) pci_read_config_word(dev, PCI_COMMAND, &w);
> +printk("	cmd 0x%x\n", w);
> +
> +	if ((w & PCI_COMMAND_IO) == 0) {
> +		w |= PCI_COMMAND_IO;
> +		(void) pci_write_config_word(dev, PCI_COMMAND, w);
> +printk("	enabling IO space\n");
> +	}
> +	return 0;
> +}
> +
> +
>  static void __init init_iops_ns87415(ide_hwif_t *hwif)
>  {
> +printk("init_iops_ns87415(%s)\n", hwif->pci_dev->slot_name);
>  #ifdef CONFIG_SUPERIO
>  	superio_ide_init_iops(hwif);
>  #endif
> @@ -150,12 +171,14 @@ static void __init init_hwif_ns87415 (id
>  	u8 stat;
>  #endif
>  
> +printk("init_hwif_ns87415(%s)\n", hwif->pci_dev->slot_name);
>  	hwif->autodma = 0;
>  	hwif->selectproc = &ns87415_selectproc;
>  
> +#if 0
>  	/* Set a good latency timer and cache line size value. */
>  	(void) pci_write_config_byte(dev, PCI_LATENCY_TIMER, 64);
> -	/* FIXME: use pci_set_master() to ensure good latency timer value */
> +#endif
>  
>  	/*
>  	 * We cannot probe for IRQ: both ports share common IRQ on INTA.
> @@ -227,6 +250,8 @@ static void __init init_hwif_ns87415 (id
>  
>  static ide_pci_device_t ns87415_chipset __devinitdata = {
>  	.name		= "NS87415",
> +	.init_chipset	= init_chipset_ns87415,
> +	.init_iops	= init_iops_ns87415,
>  	.init_hwif	= init_hwif_ns87415,
>  	.channels	= 2,
>  	.autodma	= AUTODMA,

[parisc-linux] Re: NS87415 on C3K broken

[Bartlomiej Zolnierkiewicz]

On Thursday 16 September 2004 18:17, Grant Grundler wrote:
> Hi,
> Willy pointed out the 2.6.9-rc2 NS87415 driver for C3000 machine
> (uses SuckyIO IDE) is causing HPMC (system crash). This was not
> a problem with 2.6.8.1.
> But while trying to fix MMIO resource management problems, I ran
> into this when testing on C3000.
> 
> The HPMC stack trace looks like this:
> 	ide_inb
> 	ide_wait_not_busy
> 	wait_hwif_ready
> 	probe_hwif
> 	probe_hwif_init
> 	ide_setup_pci_device
> 	ns87415_init_one
> 	ide_scan_pcidev
> 	ide_scan_pcibus
> 	ide_init
> 	do_initcalls
> 
> Changes to ide-probe.c cause this HPMC.
> wait_hwif_ready() is inside #ifdef CONFIG_PPC in 2.6.8.1 and the
> ifdef/endif was removed in 2.6.9-rcX. The result is inb() is invoked
> *BEFORE* ide_setup_pci_device() (indirectly) calls pci_enabled_device() or
> pci_set_master(). This is broken because IDE controllers NOT enabled
> by firmware will simply not respond to inb() (even if the system
> doesn't crash like on parisc).

I don't think ide-probe.c changes are the cause of HPMC.

probe_hwif_init() is only called after PCI device is fully setup,
see ide_setup_pci_device().

> I'm a wimp. I don't dare to restructure IDE init sequence.
> Anyone less of a wimp?
> Or are IDE pci drivers required to call pci_enable_device()
> in their (mostly non-extistent) init_chipset entry point?

ide_setup_pci_controller()
	-> ide_pci_enable()
		-> pci_enable_device()

and ide_setup_pci_controller() is called at the beginning
of ide_setup_pci_device() before ->init_chipset()

Ideally this should be done by host drivers
but moving this out of setup-pci.c is non-trivial.

> Anyway, ns87415 driver has more problems. The patch below adds
> "init_chipset" entry point and init_chipset_ns87415() calls
> pci_enable_device() and pci_set_master() before the probe.
> And my C3k still HPMCs. My guess is more of the code from
> init_hwif_ns87415() needs to be moved to init_chipset_ns87415().
> And possible call some special suckyio init routines.
> I won't be able to touch this for a few days.
> Anyone else on parisc-linux ml want to take a whack at this?
> 
> BTW, normally a PCI Master Abort to IO Port space to should NOT fail.
> But on parisc is does because the chipset will go "fatal" on
> any Master Abort - special hacks enable config space to work.
> I strongly prefere not to add those hacks to IO Port space
> accessor functions since it's normally not a problem.
> And while inconvenient, this behavior does expose programming
> problems like the one above.

Yep, also if they are to stay please move them to ns87415.c
because using <linux/ide.h> outside drivers/ide is WRONG.

> 
> thanks,
> grant
> 
> 
> Index: drivers/ide/pci/ns87415.c
> ===================================================================
> RCS file: /var/cvs/linux-2.6/drivers/ide/pci/ns87415.c,v
> retrieving revision 1.17
> diff -u -p -r1.17 ns87415.c
> --- drivers/ide/pci/ns87415.c	13 Sep 2004 15:23:04 -0000	1.17
> +++ drivers/ide/pci/ns87415.c	16 Sep 2004 15:06:06 -0000
> @@ -133,8 +133,29 @@ static int ns87415_ide_dma_check (ide_dr
>  	return __ide_dma_check(drive);
>  }
>  
> +static unsigned int __devinit init_chipset_ns87415(struct pci_dev *dev, const char *name)
> +{
> +	unsigned short w;
> +printk("init_chipset_ns87415(%s,%s)\n", dev->slot_name, name);
> +
> +	pci_enable_device(dev);
> +	pci_set_master(dev);
> +
> +(void) pci_read_config_word(dev, PCI_COMMAND, &w);
> +printk("	cmd 0x%x\n", w);
> +
> +	if ((w & PCI_COMMAND_IO) == 0) {
> +		w |= PCI_COMMAND_IO;
> +		(void) pci_write_config_word(dev, PCI_COMMAND, w);
> +printk("	enabling IO space\n");
> +	}
> +	return 0;
> +}
> +
> +
>  static void __init init_iops_ns87415(ide_hwif_t *hwif)
>  {
> +printk("init_iops_ns87415(%s)\n", hwif->pci_dev->slot_name);
>  #ifdef CONFIG_SUPERIO
>  	superio_ide_init_iops(hwif);
>  #endif
> @@ -150,12 +171,14 @@ static void __init init_hwif_ns87415 (id
>  	u8 stat;
>  #endif
>  
> +printk("init_hwif_ns87415(%s)\n", hwif->pci_dev->slot_name);
>  	hwif->autodma = 0;
>  	hwif->selectproc = &ns87415_selectproc;
>  
> +#if 0
>  	/* Set a good latency timer and cache line size value. */
>  	(void) pci_write_config_byte(dev, PCI_LATENCY_TIMER, 64);
> -	/* FIXME: use pci_set_master() to ensure good latency timer value */
> +#endif
>  
>  	/*
>  	 * We cannot probe for IRQ: both ports share common IRQ on INTA.
> @@ -227,6 +250,8 @@ static void __init init_hwif_ns87415 (id
>  
>  static ide_pci_device_t ns87415_chipset __devinitdata = {
>  	.name		= "NS87415",
> +	.init_chipset	= init_chipset_ns87415,
> +	.init_iops	= init_iops_ns87415,
>  	.init_hwif	= init_hwif_ns87415,
>  	.channels	= 2,
>  	.autodma	= AUTODMA,
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: NS87415 on C3K broken

[Grant Grundler]

On Fri, Sep 17, 2004 at 12:50:15AM +0200, Bartlomiej Zolnierkiewicz wrote:
> I don't think ide-probe.c changes are the cause of HPMC.
> 
> probe_hwif_init() is only called after PCI device is fully setup,
> see ide_setup_pci_device().

Sorry - you are right. I overlooked the first line of:
void ide_setup_pci_device (struct pci_dev *dev, ide_pci_device_t *d)
{
        ata_index_t index_list = do_ide_setup_pci_device(dev, d, 1);
...

and only saw the probe_hwif_init() calls that follow.
*sigh*.

> ide_setup_pci_controller()
> 	-> ide_pci_enable()
> 		-> pci_enable_device()
> 
> and ide_setup_pci_controller() is called at the beginning
> of ide_setup_pci_device() before ->init_chipset()

Yes - I tracked the pci_enabled_device back to ide_setup_pci_controller().
But I just realized I had another brainfart: ide_setup_pci_controller()
is not ide_setup_pci_device(). I should stop coding late at night...

> Ideally this should be done by host drivers
> but moving this out of setup-pci.c is non-trivial.

Yes - I reached the same conclusion.

> > Anyway, ns87415 driver has more problems. The patch below adds
> > "init_chipset" entry point and init_chipset_ns87415() calls
> > pci_enable_device() and pci_set_master() before the probe.
> > And my C3k still HPMCs. My guess is more of the code from
> > init_hwif_ns87415() needs to be moved to init_chipset_ns87415().
> > And possible call some special suckyio init routines.
> > I won't be able to touch this for a few days.
> > Anyone else on parisc-linux ml want to take a whack at this?
...
> Yep, also if they are to stay please move them to ns87415.c
> because using <linux/ide.h> outside drivers/ide is WRONG.

they? superio_ide_init_iops() or something else?
Willy mentioned that as a TODO item and it's on my list.
But I didn't plan on touching that before the HPMC is resolved
or the PCI resource mgt issues are resolved.

thanks for the correction,
grant

[parisc-linux] Re: NS87415 on C3K broken

[Grant Grundler]

On Fri, Sep 17, 2004 at 12:50:15AM +0200, Bartlomiej Zolnierkiewicz wrote:
> I don't think ide-probe.c changes are the cause of HPMC.
> 
> probe_hwif_init() is only called after PCI device is fully setup,
> see ide_setup_pci_device().

Sorry - you are right. I overlooked the first line of:
void ide_setup_pci_device (struct pci_dev *dev, ide_pci_device_t *d)
{
        ata_index_t index_list = do_ide_setup_pci_device(dev, d, 1);
...

and only saw the probe_hwif_init() calls that follow.
*sigh*.

> ide_setup_pci_controller()
> 	-> ide_pci_enable()
> 		-> pci_enable_device()
> 
> and ide_setup_pci_controller() is called at the beginning
> of ide_setup_pci_device() before ->init_chipset()

Yes - I tracked the pci_enabled_device back to ide_setup_pci_controller().
But I just realized I had another brainfart: ide_setup_pci_controller()
is not ide_setup_pci_device(). I should stop coding late at night...

> Ideally this should be done by host drivers
> but moving this out of setup-pci.c is non-trivial.

Yes - I reached the same conclusion.

> > Anyway, ns87415 driver has more problems. The patch below adds
> > "init_chipset" entry point and init_chipset_ns87415() calls
> > pci_enable_device() and pci_set_master() before the probe.
> > And my C3k still HPMCs. My guess is more of the code from
> > init_hwif_ns87415() needs to be moved to init_chipset_ns87415().
> > And possible call some special suckyio init routines.
> > I won't be able to touch this for a few days.
> > Anyone else on parisc-linux ml want to take a whack at this?
...
> Yep, also if they are to stay please move them to ns87415.c
> because using <linux/ide.h> outside drivers/ide is WRONG.

they? superio_ide_init_iops() or something else?
Willy mentioned that as a TODO item and it's on my list.
But I didn't plan on touching that before the HPMC is resolved
or the PCI resource mgt issues are resolved.

thanks for the correction,
grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: NS87415 on C3K broken

[Bartlomiej Zolnierkiewicz]

On Friday 17 September 2004 01:25, Grant Grundler wrote:
> > ide_setup_pci_controller()
> > 	-> ide_pci_enable()
> > 		-> pci_enable_device()
> > 
> > and ide_setup_pci_controller() is called at the beginning
> > of ide_setup_pci_device() before ->init_chipset()
> 
> Yes - I tracked the pci_enabled_device back to ide_setup_pci_controller().
> But I just realized I had another brainfart: ide_setup_pci_controller()
> is not ide_setup_pci_device(). I should stop coding late at night...

Heh.

> > > Anyway, ns87415 driver has more problems. The patch below adds
> > > "init_chipset" entry point and init_chipset_ns87415() calls
> > > pci_enable_device() and pci_set_master() before the probe.
> > > And my C3k still HPMCs. My guess is more of the code from
> > > init_hwif_ns87415() needs to be moved to init_chipset_ns87415().
> > > And possible call some special suckyio init routines.
> > > I won't be able to touch this for a few days.
> > > Anyone else on parisc-linux ml want to take a whack at this?
> ...
> > Yep, also if they are to stay please move them to ns87415.c
> > because using <linux/ide.h> outside drivers/ide is WRONG.
> 
> they? superio_ide_init_iops() or something else?

They.

> Willy mentioned that as a TODO item and it's on my list.
> But I didn't plan on touching that before the HPMC is resolved
> or the PCI resource mgt issues are resolved.

OK, thanks.

[parisc-linux] Re: NS87415 on C3K broken

[Bartlomiej Zolnierkiewicz]

On Friday 17 September 2004 01:25, Grant Grundler wrote:
> > ide_setup_pci_controller()
> > 	-> ide_pci_enable()
> > 		-> pci_enable_device()
> > 
> > and ide_setup_pci_controller() is called at the beginning
> > of ide_setup_pci_device() before ->init_chipset()
> 
> Yes - I tracked the pci_enabled_device back to ide_setup_pci_controller().
> But I just realized I had another brainfart: ide_setup_pci_controller()
> is not ide_setup_pci_device(). I should stop coding late at night...

Heh.

> > > Anyway, ns87415 driver has more problems. The patch below adds
> > > "init_chipset" entry point and init_chipset_ns87415() calls
> > > pci_enable_device() and pci_set_master() before the probe.
> > > And my C3k still HPMCs. My guess is more of the code from
> > > init_hwif_ns87415() needs to be moved to init_chipset_ns87415().
> > > And possible call some special suckyio init routines.
> > > I won't be able to touch this for a few days.
> > > Anyone else on parisc-linux ml want to take a whack at this?
> ...
> > Yep, also if they are to stay please move them to ns87415.c
> > because using <linux/ide.h> outside drivers/ide is WRONG.
> 
> they? superio_ide_init_iops() or something else?

They.

> Willy mentioned that as a TODO item and it's on my list.
> But I didn't plan on touching that before the HPMC is resolved
> or the PCI resource mgt issues are resolved.

OK, thanks.
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

a fix for NS87415 on C3K broken

[Joel Soete]

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

Hello Grant, Bartlomiej and *,

I test this patch:
--- arch/parisc/kernel/pci.c.Orig	2004-09-22 09:47:02.000000000 +0200
+++ arch/parisc/kernel/pci.c	2004-09-22 11:26:02.104187784 +0200
@@ -146,6 +146,9 @@
 	return str;
 }

+/* Used in drivers/pci/quirks.c */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NS, PCI_DEVICE_ID_NS_87415, superio_fixup_pci);
+
 /*
  * Called by pci_set_master() - a driver interface.
  *
--- drivers/parisc/superio.c.Orig	2004-09-22 11:17:53.759427472 +0200
+++ drivers/parisc/superio.c	2004-09-22 11:27:32.856391352 +0200
@@ -484,7 +484,6 @@
 	pci_read_config_byte(pdev, PCI_CLASS_PROG, &prog);
 	printk("PCI: Enabled native mode for NS87415 (pif=0x%x)\n", prog);
 }
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NS, PCI_DEVICE_ID_NS_87415, superio_fixup_pci);

 /* Because of a defect in Super I/O, all reads of the PCI DMA status
  * registers, IDE status register and the IDE select register need to be

=========><=========

That fix the NS87415 pb on my c2k model :)
Can somebody check it with some c3k model?

And if Ok for all, can somebody ci for me?

Tia,
    Joel

PS: here attached the diff in case of bad wrapping
> -- Original Message --
> From: Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>
> To: Grant Grundler <grundler@parisc-linux.org>
> Date: Fri, 17 Sep 2004 02:43:06 +0200
> Cc: linux-ide@vger.kernel.org, parisc-linux@lists.parisc-linux.org
> Subject: [parisc-linux] Re: NS87415 on C3K broken
>
>
> On Friday 17 September 2004 01:25, Grant Grundler wrote:
> > > ide_setup_pci_controller()
> > > 	-> ide_pci_enable()
> > > 		-> pci_enable_device()
> > >
> > > and ide_setup_pci_controller() is called at the beginning
> > > of ide_setup_pci_device() before ->init_chipset()
> >
> > Yes - I tracked the pci_enabled_device back to ide_setup_pci_controller().
> > But I just realized I had another brainfart: ide_setup_pci_controller()
> > is not ide_setup_pci_device(). I should stop coding late at night...
>
> Heh.
>
> > > > Anyway, ns87415 driver has more problems. The patch below adds
> > > > "init_chipset" entry point and init_chipset_ns87415() calls
> > > > pci_enable_device() and pci_set_master() before the probe.
> > > > And my C3k still HPMCs. My guess is more of the code from
> > > > init_hwif_ns87415() needs to be moved to init_chipset_ns87415().
> > > > And possible call some special suckyio init routines.
> > > > I won't be able to touch this for a few days.
> > > > Anyone else on parisc-linux ml want to take a whack at this?
> > ...
> > > Yep, also if they are to stay please move them to ns87415.c
> > > because using <linux/ide.h> outside drivers/ide is WRONG.
> >
> > they? superio_ide_init_iops() or something else?
>
> They.
>
> > Willy mentioned that as a TODO item and it's on my list.
> > But I didn't plan on touching that before the HPMC is resolved
> > or the PCI resource mgt issues are resolved.
>
> OK, thanks.
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux


---------------------------------------------------------------------------
Tiscali ADSL GO, 29,50 Euro/mois pendant toute une année, profitez-en...
http://reg.tiscali.be/adsl/welcome.asp?lg=FR





[-- Attachment #2: NS87415.diff --]
[-- Type: application/octet-stream, Size: 877 bytes --]

--- arch/parisc/kernel/pci.c.Orig	2004-09-22 09:47:02.000000000 +0200
+++ arch/parisc/kernel/pci.c	2004-09-22 11:26:02.104187784 +0200
@@ -146,6 +146,9 @@
 	return str;
 }
 
+/* Used in drivers/pci/quirks.c */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NS, PCI_DEVICE_ID_NS_87415, superio_fixup_pci);
+
 /*
  * Called by pci_set_master() - a driver interface.
  *
--- drivers/parisc/superio.c.Orig	2004-09-22 11:17:53.759427472 +0200
+++ drivers/parisc/superio.c	2004-09-22 11:27:32.856391352 +0200
@@ -484,7 +484,6 @@
 	pci_read_config_byte(pdev, PCI_CLASS_PROG, &prog);
 	printk("PCI: Enabled native mode for NS87415 (pif=0x%x)\n", prog);
 }
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NS, PCI_DEVICE_ID_NS_87415, superio_fixup_pci);
 
 /* Because of a defect in Super I/O, all reads of the PCI DMA status 
  * registers, IDE status register and the IDE select register need to be 

[parisc-linux] a fix for NS87415 on C3K broken

[Joel Soete]

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

Hello Grant, Bartlomiej and *,

I test this patch:
--- arch/parisc/kernel/pci.c.Orig	2004-09-22 09:47:02.000000000 +0200
+++ arch/parisc/kernel/pci.c	2004-09-22 11:26:02.104187784 +0200
@@ -146,6 +146,9 @@
 	return str;
 }

+/* Used in drivers/pci/quirks.c */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NS, PCI_DEVICE_ID_NS_87415, superio_fixup_pci);
+
 /*
  * Called by pci_set_master() - a driver interface.
  *
--- drivers/parisc/superio.c.Orig	2004-09-22 11:17:53.759427472 +0200
+++ drivers/parisc/superio.c	2004-09-22 11:27:32.856391352 +0200
@@ -484,7 +484,6 @@
 	pci_read_config_byte(pdev, PCI_CLASS_PROG, &prog);
 	printk("PCI: Enabled native mode for NS87415 (pif=0x%x)\n", prog);
 }
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NS, PCI_DEVICE_ID_NS_87415, superio_fixup_pci);

 /* Because of a defect in Super I/O, all reads of the PCI DMA status
  * registers, IDE status register and the IDE select register need to be

=========><=========

That fix the NS87415 pb on my c2k model :)
Can somebody check it with some c3k model?

And if Ok for all, can somebody ci for me?

Tia,
    Joel

PS: here attached the diff in case of bad wrapping
> -- Original Message --
> From: Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>
> To: Grant Grundler <grundler@parisc-linux.org>
> Date: Fri, 17 Sep 2004 02:43:06 +0200
> Cc: linux-ide@vger.kernel.org, parisc-linux@lists.parisc-linux.org
> Subject: [parisc-linux] Re: NS87415 on C3K broken
>
>
> On Friday 17 September 2004 01:25, Grant Grundler wrote:
> > > ide_setup_pci_controller()
> > > 	-> ide_pci_enable()
> > > 		-> pci_enable_device()
> > >
> > > and ide_setup_pci_controller() is called at the beginning
> > > of ide_setup_pci_device() before ->init_chipset()
> >
> > Yes - I tracked the pci_enabled_device back to ide_setup_pci_controller().
> > But I just realized I had another brainfart: ide_setup_pci_controller()
> > is not ide_setup_pci_device(). I should stop coding late at night...
>
> Heh.
>
> > > > Anyway, ns87415 driver has more problems. The patch below adds
> > > > "init_chipset" entry point and init_chipset_ns87415() calls
> > > > pci_enable_device() and pci_set_master() before the probe.
> > > > And my C3k still HPMCs. My guess is more of the code from
> > > > init_hwif_ns87415() needs to be moved to init_chipset_ns87415().
> > > > And possible call some special suckyio init routines.
> > > > I won't be able to touch this for a few days.
> > > > Anyone else on parisc-linux ml want to take a whack at this?
> > ...
> > > Yep, also if they are to stay please move them to ns87415.c
> > > because using <linux/ide.h> outside drivers/ide is WRONG.
> >
> > they? superio_ide_init_iops() or something else?
>
> They.
>
> > Willy mentioned that as a TODO item and it's on my list.
> > But I didn't plan on touching that before the HPMC is resolved
> > or the PCI resource mgt issues are resolved.
>
> OK, thanks.
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux


---------------------------------------------------------------------------
Tiscali ADSL GO, 29,50 Euro/mois pendant toute une année, profitez-en...
http://reg.tiscali.be/adsl/welcome.asp?lg=FR





[-- Attachment #2: NS87415.diff --]
[-- Type: application/octet-stream, Size: 877 bytes --]

--- arch/parisc/kernel/pci.c.Orig	2004-09-22 09:47:02.000000000 +0200
+++ arch/parisc/kernel/pci.c	2004-09-22 11:26:02.104187784 +0200
@@ -146,6 +146,9 @@
 	return str;
 }
 
+/* Used in drivers/pci/quirks.c */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NS, PCI_DEVICE_ID_NS_87415, superio_fixup_pci);
+
 /*
  * Called by pci_set_master() - a driver interface.
  *
--- drivers/parisc/superio.c.Orig	2004-09-22 11:17:53.759427472 +0200
+++ drivers/parisc/superio.c	2004-09-22 11:27:32.856391352 +0200
@@ -484,7 +484,6 @@
 	pci_read_config_byte(pdev, PCI_CLASS_PROG, &prog);
 	printk("PCI: Enabled native mode for NS87415 (pif=0x%x)\n", prog);
 }
-DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NS, PCI_DEVICE_ID_NS_87415, superio_fixup_pci);
 
 /* Because of a defect in Super I/O, all reads of the PCI DMA status 
  * registers, IDE status register and the IDE select register need to be 

[-- Attachment #3: Type: text/plain, Size: 169 bytes --]

_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: a fix for NS87415 on C3K broken

[Grant Grundler]

On Wed, Sep 22, 2004 at 12:41:21PM +0200, Joel Soete wrote:
> Hello Grant, Bartlomiej and *,
>
> I test this patch:
> --- arch/parisc/kernel/pci.c.Orig	2004-09-22 09:47:02.000000000 +0200
> +++ arch/parisc/kernel/pci.c	2004-09-22 11:26:02.104187784 +0200
> @@ -146,6 +146,9 @@
>  	return str;
>  }
> 
> +/* Used in drivers/pci/quirks.c */
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NS, PCI_DEVICE_ID_NS_87415, superio_fixup_pci);

Uhm...any clue why this works?
The same entry in drivers/parisc/superio.c should work too but it doesn't.
I'd rather fix that than just blindly moving it.

> That fix the NS87415 pb on my c2k model :)
> Can somebody check it with some c3k model?

I expect c3k also to work. I'm not going to test it.


BTW, I've prepared a patch which moves IDE knowledge
out of superio.c driver and into drivers/ide/pci/ns87415.c.
I've not submitted it yet because I haven't successfully tested it
and it still contains debug printk's.
It builds and anyone curious is welcome to look at it:
    ftp://ftp.parisc-linux.org/patches/diff-2.6.9-rc2-ns87415_suckyio_cleanup-01

Moving the DECLARE_PCI_FIXUP_HEADER() around is probably the clue
I needed to resolve this.

thanks,
grant

[parisc-linux] Re: a fix for NS87415 on C3K broken

[Grant Grundler]

On Wed, Sep 22, 2004 at 12:41:21PM +0200, Joel Soete wrote:
> Hello Grant, Bartlomiej and *,
>
> I test this patch:
> --- arch/parisc/kernel/pci.c.Orig	2004-09-22 09:47:02.000000000 +0200
> +++ arch/parisc/kernel/pci.c	2004-09-22 11:26:02.104187784 +0200
> @@ -146,6 +146,9 @@
>  	return str;
>  }
> 
> +/* Used in drivers/pci/quirks.c */
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NS, PCI_DEVICE_ID_NS_87415, superio_fixup_pci);

Uhm...any clue why this works?
The same entry in drivers/parisc/superio.c should work too but it doesn't.
I'd rather fix that than just blindly moving it.

> That fix the NS87415 pb on my c2k model :)
> Can somebody check it with some c3k model?

I expect c3k also to work. I'm not going to test it.


BTW, I've prepared a patch which moves IDE knowledge
out of superio.c driver and into drivers/ide/pci/ns87415.c.
I've not submitted it yet because I haven't successfully tested it
and it still contains debug printk's.
It builds and anyone curious is welcome to look at it:
    ftp://ftp.parisc-linux.org/patches/diff-2.6.9-rc2-ns87415_suckyio_cleanup-01

Moving the DECLARE_PCI_FIXUP_HEADER() around is probably the clue
I needed to resolve this.

thanks,
grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: a fix for NS87415 on C3K broken

[Matthew Wilcox]

On Wed, Sep 22, 2004 at 10:37:08AM -0600, Grant Grundler wrote:
> On Wed, Sep 22, 2004 at 12:41:21PM +0200, Joel Soete wrote:
> > --- arch/parisc/kernel/pci.c.Orig	2004-09-22 09:47:02.000000000 +0200
> > +++ arch/parisc/kernel/pci.c	2004-09-22 11:26:02.104187784 +0200
> > +/* Used in drivers/pci/quirks.c */
> > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NS, PCI_DEVICE_ID_NS_87415, superio_fixup_pci);
> 
> Uhm...any clue why this works?
> The same entry in drivers/parisc/superio.c should work too but it doesn't.
> I'd rather fix that than just blindly moving it.

I think I know.  The define is:

#define DECLARE_PCI_FIXUP_HEADER(vendor, device, hook) \
        static struct pci_fixup __pci_fixup_##vendor##device##hook __attribute_u
sed__   \
        __attribute__((__section__(".pci_fixup_header"))) = { \
                vendor, device, hook };

Now, that's dealt with by include/asm-generic/vmlinux.lds.h:

#define RODATA                                                          \
[...]
        /* PCI quirks */                                                \
        .pci_fixup        : AT(ADDR(.pci_fixup) - LOAD_OFFSET) {        \
                VMLINUX_SYMBOL(__start_pci_fixups_header) = .;          \
                *(.pci_fixup_header)                                    \
                VMLINUX_SYMBOL(__end_pci_fixups_header) = .;            \
                VMLINUX_SYMBOL(__start_pci_fixups_final) = .;           \
                *(.pci_fixup_final)                                     \
                VMLINUX_SYMBOL(__end_pci_fixups_final) = .;             \
        }                                                               \

which links them all together.  *However* ... maybe order is important.
There's a grotty-looking:
c03f347c d __pci_fixup_PCI_ANY_IDPCI_ANY_IDquirk_ide_bases

which may need to come after our superio quirk?  I'm just testing this theory now ...

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: [parisc-linux] Re: a fix for NS87415 on C3K broken

[Matthew Wilcox]

On Wed, Sep 22, 2004 at 10:37:08AM -0600, Grant Grundler wrote:
> On Wed, Sep 22, 2004 at 12:41:21PM +0200, Joel Soete wrote:
> > --- arch/parisc/kernel/pci.c.Orig	2004-09-22 09:47:02.000000000 +0200
> > +++ arch/parisc/kernel/pci.c	2004-09-22 11:26:02.104187784 +0200
> > +/* Used in drivers/pci/quirks.c */
> > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NS, PCI_DEVICE_ID_NS_87415, superio_fixup_pci);
> 
> Uhm...any clue why this works?
> The same entry in drivers/parisc/superio.c should work too but it doesn't.
> I'd rather fix that than just blindly moving it.

I think I know.  The define is:

#define DECLARE_PCI_FIXUP_HEADER(vendor, device, hook) \
        static struct pci_fixup __pci_fixup_##vendor##device##hook __attribute_u
sed__   \
        __attribute__((__section__(".pci_fixup_header"))) = { \
                vendor, device, hook };

Now, that's dealt with by include/asm-generic/vmlinux.lds.h:

#define RODATA                                                          \
[...]
        /* PCI quirks */                                                \
        .pci_fixup        : AT(ADDR(.pci_fixup) - LOAD_OFFSET) {        \
                VMLINUX_SYMBOL(__start_pci_fixups_header) = .;          \
                *(.pci_fixup_header)                                    \
                VMLINUX_SYMBOL(__end_pci_fixups_header) = .;            \
                VMLINUX_SYMBOL(__start_pci_fixups_final) = .;           \
                *(.pci_fixup_final)                                     \
                VMLINUX_SYMBOL(__end_pci_fixups_final) = .;             \
        }                                                               \

which links them all together.  *However* ... maybe order is important.
There's a grotty-looking:
c03f347c d __pci_fixup_PCI_ANY_IDPCI_ANY_IDquirk_ide_bases

which may need to come after our superio quirk?  I'm just testing this theory now ...

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: a fix for NS87415 on C3K broken

[Joel Soete]

Hello Grant,

> On Wed, Sep 22, 2004 at 12:41:21PM +0200, Joel Soete wrote:
> > Hello Grant, Bartlomiej and *,
> >
> > I test this patch:
> > --- arch/parisc/kernel/pci.c.Orig	2004-09-22 09:47:02.000000000 +0200
> > +++ arch/parisc/kernel/pci.c	2004-09-22 11:26:02.104187784 +0200
> > @@ -146,6 +146,9 @@
> >  	return str;
> >  }
> > 
> > +/* Used in drivers/pci/quirks.c */
> > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NS, PCI_DEVICE_ID_NS_87415,
superio_fixup_pci);
> 
> Uhm...any clue why this works?
No more clue sorry; I just notived that boot message of 2.6.8.1-pa7:
lba version TR4.0 (0x5) found at 0xfffffffffed30000
PCI: Enabled native mode for NS87415 (pif=0x8f)

became with 2.6.9-rc2:
lba version TR4.0 (0x5) found at 0xfffffffffed30000
PCI: Ignoring BAR0-3 of IDE controller 0000:00:0e.0
PCI: Enabled native mode for NS87415 (pif=0x8f)

(so PCI: Enabled native mode for NS87415 precede by a weird 'ignoring ...
IDE controler)

I so just try to move back the pcibios_fixups initialisation at its previous
place and the message ''ignoring ... IDE controler" disapear ?)
 
> The same entry in drivers/parisc/superio.c should work too but it doesn't.
> I'd rather fix that than just blindly moving it.
> 
no pb

> > That fix the NS87415 pb on my c2k model :)
> > Can somebody check it with some c3k model?
> 
> I expect c3k also to work. I'm not going to test it.
> 
> 
> BTW, I've prepared a patch which moves IDE knowledge
> out of superio.c driver and into drivers/ide/pci/ns87415.c.
> I've not submitted it yet because I haven't successfully tested it
> and it still contains debug printk's.
> It builds and anyone curious is welcome to look at it:
>     ftp://ftp.parisc-linux.org/patches/diff-2.6.9-rc2-ns87415_suckyio_cleanup-01
> 
I will also try it :)

> Moving the DECLARE_PCI_FIXUP_HEADER() around is probably the clue
> I needed to resolve this.
> 
I am curious to find an expalnation too.

Thanks,
    Joel

---------------------------------------------------------------------------
Tiscali ADSL GO, 29,50 Euro/mois pendant toute une année, profitez-en...
http://reg.tiscali.be/adsl/welcome.asp?lg=FR

[parisc-linux] Re: a fix for NS87415 on C3K broken

[Joel Soete]

Hello Grant,

> On Wed, Sep 22, 2004 at 12:41:21PM +0200, Joel Soete wrote:
> > Hello Grant, Bartlomiej and *,
> >
> > I test this patch:
> > --- arch/parisc/kernel/pci.c.Orig	2004-09-22 09:47:02.000000000 +0200=

> > +++ arch/parisc/kernel/pci.c	2004-09-22 11:26:02.104187784 +0200
> > @@ -146,6 +146,9 @@
> >  	return str;
> >  }
> > 
> > +/* Used in drivers/pci/quirks.c */
> > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NS, PCI_DEVICE_ID_NS_87415,
superio_fixup_pci);
> 
> Uhm...any clue why this works?
No more clue sorry; I just notived that boot message of 2.6.8.1-pa7:
lba version TR4.0 (0x5) found at 0xfffffffffed30000
PCI: Enabled native mode for NS87415 (pif=3D0x8f)

became with 2.6.9-rc2:
lba version TR4.0 (0x5) found at 0xfffffffffed30000
PCI: Ignoring BAR0-3 of IDE controller 0000:00:0e.0
PCI: Enabled native mode for NS87415 (pif=3D0x8f)

(so PCI: Enabled native mode for NS87415 precede by a weird 'ignoring ...=

IDE controler)

I so just try to move back the pcibios_fixups initialisation at its previ=
ous
place and the message ''ignoring ... IDE controler" disapear ?)
 
> The same entry in drivers/parisc/superio.c should work too but it doesn=
't.
> I'd rather fix that than just blindly moving it.
> 
no pb

> > That fix the NS87415 pb on my c2k model :)
> > Can somebody check it with some c3k model?
> 
> I expect c3k also to work. I'm not going to test it.
> 
> 
> BTW, I've prepared a patch which moves IDE knowledge
> out of superio.c driver and into drivers/ide/pci/ns87415.c.
> I've not submitted it yet because I haven't successfully tested it
> and it still contains debug printk's.
> It builds and anyone curious is welcome to look at it:
>     ftp://ftp.parisc-linux.org/patches/diff-2.6.9-rc2-ns87415_suckyio_c=
leanup-01
> 
I will also try it :)

> Moving the DECLARE_PCI_FIXUP_HEADER() around is probably the clue
> I needed to resolve this.
> 
I am curious to find an expalnation too.

Thanks,
    Joel

-------------------------------------------------------------------------=
--
Tiscali ADSL GO, 29,50 Euro/mois pendant toute une ann=E9e, profitez-en..=
.
http://reg.tiscali.be/adsl/welcome.asp?lg=3DFR




_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: a fix for NS87415 on C3K broken

[Matthew Wilcox]

On Wed, Sep 22, 2004 at 07:21:08PM +0200, Joel Soete wrote:
> > Moving the DECLARE_PCI_FIXUP_HEADER() around is probably the clue
> > I needed to resolve this.
> >
> I am curious to find an expalnation too.

Yep, that's it.  That moves it to be the first entry on the list, and
it handles the suckyio IDE cotroller before the quirk_ide_bases does.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: [parisc-linux] Re: a fix for NS87415 on C3K broken

[Matthew Wilcox]

On Wed, Sep 22, 2004 at 07:21:08PM +0200, Joel Soete wrote:
> > Moving the DECLARE_PCI_FIXUP_HEADER() around is probably the clue
> > I needed to resolve this.
> >
> I am curious to find an expalnation too.

Yep, that's it.  That moves it to be the first entry on the list, and
it handles the suckyio IDE cotroller before the quirk_ide_bases does.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

RE: [parisc-linux] Re: a fix for NS87415 on C3K broken

[Joel Soete]

Hello Grant,

Sorry for auto-reply but an update:

[...]]
> > BTW, I've prepared a patch which moves IDE knowledge
> > out of superio.c driver and into drivers/ide/pci/ns87415.c.
> > I've not submitted it yet because I haven't successfully tested it
> > and it still contains debug printk's.
> > It builds and anyone curious is welcome to look at it:
> >     ftp://ftp.parisc-linux.org/patches/diff-2.6.9-rc2-ns87415_suckyio_cleanup-01
> >
> I will also try it :)
> 
I apply Matthew's patch and it boot fine :)

I also launch a loop to build the kernel and seems to works fine (5 or 6
build already :) ; but could not be significant :( ).

But when I try to use the ide-cdrom the system carsh with such oops:
Backtrace:
 [<000000001017e0d8>] drain_array_locked+0x98/0x148
 [<000000001017e2c4>] cache_reap+0x13c/0x2b0
 [<000000001015e574>] worker_thread+0x284/0x330
 [<0000000010164714>] kthread+0x12c/0x138
 [<000000001010647c>] ret_from_kernel_thread+0x24/0x38


Kernel Fault: Code=15 regs=0000000010b4c600 (Addr=0000000390cc9ce4)

     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00001000000001000000000000001110 Not tainted
r00-03  0000000000000000 0000000010433c80 000000001017d3f0 00000000104e9830
r04-07  00000000106c2680 00000000106c2690 0000000000000011 000000001061c420
r08-11  0000000000000018 00000000106c26b0 0000000010aea010 0000000000200000
r12-15  0000000000100000 000000003b9ac800 0000000000000000 00000000f0400004
r16-19  00000000f00008c4 00000000f000017c 00000000f0000174 0000000390cc9cbc
r20-23  ffffffffe01f8123 0000000010975628 0000000000000000 000000003f6ec800
r24-27  0000000000001fe0 000000001fe07edd 00000000000000cc 000000001061c420
r28-31  00000000e01f8123 0000000000007edd 0000000010b4c600 0000000000008000
sr0-3   0000000000309800 0000000000000000 0000000000000000 0000000000309800
sr4-7   0000000000000000 0000000000000000 0000000000000000 0000000000000000

IASQ: 0000000000000000 0000000000000000 IAOQ: 000000001017d420 000000001017d424
 IIR: 6a750050    ISR: 0000000000000000  IOR: 0000000390cc9ce4
 CPU:        0   CR30: 0000000010b4c000 CR31: 00000000105dc000
 ORIG_R28: 0000000010175f54
 IAOQ[0]: free_block+0xf8/0x1b8
 IAOQ[1]: free_block+0xfc/0x1b8
 RP(r2): free_block+0xc8/0x1b8
Kernel panic - not syncing: Kernel Fault

Sometime just after the mount of cdrom; sometime when I launch some ls -l
/cdrom or a find /cdrom ?

I tried to revert your patch and the crash seems to hapen at another place:
Backtrace:
 [<0000000010399934>] alloc_skb+0x6c/0x130
 [<00000000103986a0>] sock_alloc_send_pskb+0x180/0x300
 [<0000000010398848>] sock_alloc_send_skb+0x28/0x40
 [<00000000103c4168>] ip_append_data+0x6b8/0xa70
 [<00000000103eb138>] udp_sendmsg+0x188/0x758
 [<00000000103f5b5c>] inet_sendmsg+0x6c/0xb0
 [<0000000010394288>] sock_sendmsg+0xc8/0x108
 [<000000001041ff2c>] svc_sendto+0x2c4/0x2d8
 [<00000000104206f4>] svc_udp_sendto+0x2c/0x70
 [<0000000010422300>] svc_send+0x198/0x210
 [<000000001041ee54>] svc_process+0x2e4/0x8f8
 [<0000000010238be8>] nfsd+0x268/0x4e8
 [<000000001010647c>] ret_from_kernel_thread+0x24/0x38


Kernel Fault: Code=15 regs=000000001e204f00 (Addr=0000000191b09118)

     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00001000000001001111111100001110 Not tainted
r00-03  0000000000000000 0000000010433b38 0000000010399934 000000001061c400
r04-07  000000000800000f 0000000000000600 000000001061c400 000000001f142a68
r08-11  0000000000000000 00000000000005fb 000000001e204b08 000000001f142b78
r12-15  0000000000000008 000000001ec10680 0000000000000000 0000000000000014
r16-19  00000000000005dc 000000001061c400 0000000000000008 0000000191b09108
r20-23  0000000030203009 0000000010af10c0 0000000000000000 0000000000000001
r24-27  0000000000000000 00000000000000d0 00000000106c2b00 000000001061c400
r28-31  000000001eb166c0 000000001e204e70 000000001e204f00 0000000000000001
sr0-3   000000000031c000 0000000000000000 0000000000000000 000000000031c000
sr4-7   0000000000000000 0000000000000000 0000000000000000 0000000000000000

IASQ: 0000000000000000 0000000000000000 IAOQ: 000000001017da18 000000001017da1c
 IIR: 527c0020    ISR: 0000000000000000  IOR: 0000000191b09118
 CPU:        0   CR30: 000000001e204000 CR31: 00000000105dc000
 ORIG_R28: 00000000103b12f0
 IAOQ[0]: __kmalloc+0xb0/0xd8
 IAOQ[1]: __kmalloc+0xb4/0xd8
 RP(r2): alloc_skb+0x6c/0x130
Kernel panic - not syncing: Kernel Fault

I do the same test with 2.6.8.1-pa7 and all seems ok.

I just noticed this following warning at the compile time:
hppa64-linux-gcc -Wp,-MD,drivers/ide/.ide-iops.o.d -nostdinc -iwithprefix
include -D__KERNEL__ -Iinclude  -Wall -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -O2 -fomit-frame-pointer  -pipe -mno-space-regs
-mfast-indirect-calls -ffunction-sections -march=2.0 -mschedule=8000 -Idrivers/ide
  -DKBUILD_BASENAME=ide_iops -DKBUILD_MODNAME=ide_core -c -o drivers/ide/ide-iops.o
drivers/ide/ide-iops.c
drivers/ide/ide-iops.c: In function `ide_mm_insw':
drivers/ide/ide-iops.c:125: warning: passing arg 1 of `__ide_mm_insw' makes
integer from pointer without a cast
drivers/ide/ide-iops.c: In function `ide_mm_insl':
drivers/ide/ide-iops.c:135: warning: passing arg 1 of `__ide_mm_insl' makes
integer from pointer without a cast
drivers/ide/ide-iops.c: In function `ide_mm_outsw':
drivers/ide/ide-iops.c:155: warning: passing arg 1 of `__ide_mm_outsw' makes
integer from pointer without a cast
drivers/ide/ide-iops.c: In function `ide_mm_outsl':
drivers/ide/ide-iops.c:165: warning: passing arg 1 of `__ide_mm_outsl' makes
integer from pointer without a cast

but don't think it had any matter related to the crash.

Sorry not enough time to investigate more right now but if somebody can
drive me to the right way, all idea are wellcome ;)

TIA,
    Joel


---------------------------------------------------------------------------
Tiscali ADSL GO, 29,50 Euro/mois pendant toute une année, profitez-en...
http://reg.tiscali.be/adsl/welcome.asp?lg=FR

Re: [parisc-linux] Re: a fix for NS87415 on C3K broken

[Randolph Chung]

> But when I try to use the ide-cdrom the system carsh with such oops:
> Backtrace:
>  [<000000001017e0d8>] drain_array_locked+0x98/0x148
>  [<000000001017e2c4>] cache_reap+0x13c/0x2b0
>  [<000000001015e574>] worker_thread+0x284/0x330
>  [<0000000010164714>] kthread+0x12c/0x138
>  [<000000001010647c>] ret_from_kernel_thread+0x24/0x38

maybe this will help:
http://marc.theaimsgroup.com/?l=linux-kernel&m=109529103522064&w=2

but we are seeing some of these slab errors with this build that are not
cdrom related too... :(

can you try compiling with slab debug (under kernel debugging)?

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] Re: a fix for NS87415 on C3K broken

[Randolph Chung]

> But when I try to use the ide-cdrom the system carsh with such oops:
> Backtrace:
>  [<000000001017e0d8>] drain_array_locked+0x98/0x148
>  [<000000001017e2c4>] cache_reap+0x13c/0x2b0
>  [<000000001015e574>] worker_thread+0x284/0x330
>  [<0000000010164714>] kthread+0x12c/0x138
>  [<000000001010647c>] ret_from_kernel_thread+0x24/0x38

maybe this will help:
http://marc.theaimsgroup.com/?l=linux-kernel&m=109529103522064&w=2

but we are seeing some of these slab errors with this build that are not
cdrom related too... :(

can you try compiling with slab debug (under kernel debugging)?

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: a fix for NS87415 on C3K broken

[Joel Soete]

Hello Randolph,

> 
> > But when I try to use the ide-cdrom the system carsh with such oops:
> > Backtrace:
> >  [<000000001017e0d8>] drain_array_locked+0x98/0x148
> >  [<000000001017e2c4>] cache_reap+0x13c/0x2b0
> >  [<000000001015e574>] worker_thread+0x284/0x330
> >  [<0000000010164714>] kthread+0x12c/0x138
> >  [<000000001010647c>] ret_from_kernel_thread+0x24/0x38
> 
> maybe this will help:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=109529103522064&w=2
>
Thanks for advise, it does the trick  :)

> but we are seeing some of these slab errors with this build that are not
> cdrom related too... :(
>
mmm On the N4k with some 2.6.9-rc2-pa6 release, I lso noticed a crash with
IAOQ refering to free_block () (eventhought that this system loop all the
night to make -j4 vmlinux without any pb; I just stop the loop and restart
it later and ... panic() ?)
 
> can you try compiling with slab debug (under kernel debugging)?
> 
Of course and btw I will rebuild a 2.6.9-rc2-pa_7_ for the N4k too and a
32b for a b180 and a chroot disk to test the new Carlos glibc build ;)

Thansk again for all advise,
    Joel

---------------------------------------------------------------------------
Tiscali ADSL GO, 29,50 Euro/mois pendant toute une année, profitez-en...
http://reg.tiscali.be/adsl/welcome.asp?lg=FR

Re: [parisc-linux] Re: a fix for NS87415 on C3K broken

[Joel Soete]

Hello Randolph,

> 
> > But when I try to use the ide-cdrom the system carsh with such oops:
> > Backtrace:
> >  [<000000001017e0d8>] drain_array_locked+0x98/0x148
> >  [<000000001017e2c4>] cache_reap+0x13c/0x2b0
> >  [<000000001015e574>] worker_thread+0x284/0x330
> >  [<0000000010164714>] kthread+0x12c/0x138
> >  [<000000001010647c>] ret_from_kernel_thread+0x24/0x38
> 
> maybe this will help:
> http://marc.theaimsgroup.com/?l=3Dlinux-kernel&m=3D109529103522064&w=3D=
2
>
Thanks for advise, it does the trick  :)

> but we are seeing some of these slab errors with this build that are no=
t
> cdrom related too... :(
>
mmm On the N4k with some 2.6.9-rc2-pa6 release, I lso noticed a crash wit=
h
IAOQ refering to free_block () (eventhought that this system loop all the=

night to make -j4 vmlinux without any pb; I just stop the loop and restar=
t
it later and ... panic() ?)
 
> can you try compiling with slab debug (under kernel debugging)?
> 
Of course and btw I will rebuild a 2.6.9-rc2-pa_7_ for the N4k too and a
32b for a b180 and a chroot disk to test the new Carlos glibc build ;)

Thansk again for all advise,
    Joel

-------------------------------------------------------------------------=
--
Tiscali ADSL GO, 29,50 Euro/mois pendant toute une ann=E9e, profitez-en..=
.
http://reg.tiscali.be/adsl/welcome.asp?lg=3DFR




_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] Re: a fix for NS87415 on C3K broken

[Joel Soete]

Hello Grant,

> It builds and anyone curious is welcome to look at it:
>     ftp://ftp.parisc-linux.org/patches/diff-2.6.9-rc2-ns87415_suckyio_c=
leanup-01
> 
I test it with Matthew's patches about DECLARE_FIXUP_... and upstream roc=
k
iso fs and seems to works fine on b2k:)

hth,
    Joel

PS: Don't think it's patch related but I observe a weird behaviour: when
I boot with a cd into the drive and try to mount it I got message: "cdrom=
:
open failed.". I just have to "eject /cdrom; eject -t /cdrom" to mount an=
d
use the same cd without pb?



-------------------------------------------------------------------------=
--
Tiscali ADSL GO, 29,50 Euro/mois pendant toute une ann=E9e, profitez-en..=
.
http://reg.tiscali.be/adsl/welcome.asp?lg=3DFR




_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: a fix for NS87415 on C3K broken

[Joel Soete]

Hello Randolph,

Auto-reply for an update (sorry)
> 
> >
> > > But when I try to use the ide-cdrom the system carsh with such oops:
> > > Backtrace:
> > >  [<000000001017e0d8>] drain_array_locked+0x98/0x148
> > >  [<000000001017e2c4>] cache_reap+0x13c/0x2b0
> > >  [<000000001015e574>] worker_thread+0x284/0x330
> > >  [<0000000010164714>] kthread+0x12c/0x138
> > >  [<000000001010647c>] ret_from_kernel_thread+0x24/0x38
> >
> > maybe this will help:
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=109529103522064&w=2
> >
> Thanks for advise, it does the trick  :)
> 
> > but we are seeing some of these slab errors with this build that are
not
> > cdrom related too... :(
> >
> mmm On the N4k with some 2.6.9-rc2-pa6 release, I lso noticed a crash
with
> IAOQ refering to free_block () (eventhought that this system loop all
the
> night to make -j4 vmlinux without any pb; I just stop the loop and restart
> it later and ... panic() ?)
> 
> > can you try compiling with slab debug (under kernel debugging)?
> >
> Of course and btw I will rebuild a 2.6.9-rc2-pa_7_ for the N4k too and
a
> 32b for a b180 and a chroot disk to test the new Carlos glibc build ;)
> 
Well, I test the 2.6.9-rc2-pa7 with slab debug (before Matthew added sys
call) and build this kernel in a loop (now about 30 loop) without pb just
numerous:
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68

any clue?

Thanks again,
    Joel

---------------------------------------------------------------------------
Tiscali ADSL GO, 29,50 Euro/mois pendant toute une année, profitez-en...
http://reg.tiscali.be/adsl/welcome.asp?lg=FR

Re: [parisc-linux] Re: a fix for NS87415 on C3K broken

[Joel Soete]

Hello Randolph,

Auto-reply for an update (sorry)
> 
> >
> > > But when I try to use the ide-cdrom the system carsh with such oops=
:
> > > Backtrace:
> > >  [<000000001017e0d8>] drain_array_locked+0x98/0x148
> > >  [<000000001017e2c4>] cache_reap+0x13c/0x2b0
> > >  [<000000001015e574>] worker_thread+0x284/0x330
> > >  [<0000000010164714>] kthread+0x12c/0x138
> > >  [<000000001010647c>] ret_from_kernel_thread+0x24/0x38
> >
> > maybe this will help:
> > http://marc.theaimsgroup.com/?l=3Dlinux-kernel&m=3D109529103522064&w=3D=
2
> >
> Thanks for advise, it does the trick  :)
> 
> > but we are seeing some of these slab errors with this build that are
not
> > cdrom related too... :(
> >
> mmm On the N4k with some 2.6.9-rc2-pa6 release, I lso noticed a crash
with
> IAOQ refering to free_block () (eventhought that this system loop all
the
> night to make -j4 vmlinux without any pb; I just stop the loop and rest=
art
> it later and ... panic() ?)
> 
> > can you try compiling with slab debug (under kernel debugging)?
> >
> Of course and btw I will rebuild a 2.6.9-rc2-pa_7_ for the N4k too and
a
> 32b for a b180 and a chroot disk to test the new Carlos glibc build ;)
> 
Well, I test the 2.6.9-rc2-pa7 with slab debug (before Matthew added sys
call) and build this kernel in a loop (now about 30 loop) without pb just=

numerous:
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68
applying fixup for 0x10124d08, fixup at 0x10469a68

any clue?

Thanks again,
    Joel

-------------------------------------------------------------------------=
--
Tiscali ADSL GO, 29,50 Euro/mois pendant toute une ann=E9e, profitez-en..=
.
http://reg.tiscali.be/adsl/welcome.asp?lg=3DFR




_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: a fix for NS87415 on C3K broken

[Randolph Chung]

> Well, I test the 2.6.9-rc2-pa7 with slab debug (before Matthew added sys
> call) and build this kernel in a loop (now about 30 loop) without pb just
> numerous:
> applying fixup for 0x10124d08, fixup at 0x10469a68
> applying fixup for 0x10124d08, fixup at 0x10469a68

this is just a debug message. i've removed it from the latest codebase.

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux