[Prism54-devel] Re: device soft reset timed out on ixdp425

Luis R. Rodriguez mcgrof@ruslug.rutgers.edu
Mon, 9 Feb 2004 17:32:09 -0500


Lai,

can you try two things:

1. Try each the latest snapshot with each of the firmware versions we have up.
2. If all fails, try to bring up the device with the latest firmware and
VERBOSE set to 0xFF

	Luis

On Mon, Feb 02, 2004 at 11:54:57AM -0500, Luis R. Rodriguez wrote:
> 
> Lai,
> 
> On Mon, Feb 02, 2004 at 02:57:21PM +0800, ??(Lai Li) wrote:
> > 2.4.22 but i add firmware_class.c
> > because the driver will need it!!
> >   ----- Original Message ----- 
> >   From: Clint Adams 
> >   To: Lai Li 
> >   Cc: prism54-devel@prism54.org 
> >   Sent: Monday, February 02, 2004 1:04 PM
> >   Subject: Re: [Prism54-devel] Re: device soft reset timed out on ixdp425
> > 
> > 
> >   > i found that the function prism54_mib_init() in isl_ioctl.c was being
> >   > queued 
> >   > to kernel task_queue,and witch is not be executed.
> 
> 
> FYI, some of this information may be inaccurate since our experience
> with the card/driver is purely out of trial and error since
> Globespanvirata has not given us clearance to obtain the chipset's
> specs.
> 
> --
> 
> The error message you see pops out because we've told the card to
> complete a soft reset [isl38xx_interface_reset in
> isl_38xx.c] but the driver is determining the reset never completed.
> Since the driver detects this, it bails out of bringing the interface
> up and never runs prism54_mib_init.
> 
> Our driver detects if the soft reset completed by enabling the 
> ISL38XX_INT_IDENT_INIT interrupt [done at the end of
> isl38xx_interface_reset]. Enabling this interrupt on the card 
> will make the card pass a special IRQ when this task was completed. 
> When our driver detects this IRQ was passed, it then flags that 
> the operation was completed [islpci_interrupt in islpci_dev.c]. 
> 
> I'm not sure but I do leave open the chances that the IRQ is setting off
> before we are enabling the detection of the interrupt. If this is the 
> case then you can try to enable the ISL38XX_INT_IDENT_INIT at the
> beginning of the soft reset [isl38xx_interface_reset] instead of the
> end, where we currently have it. 
> 
> If you want to follow the chain of the events that take place just take
> note that prism54_probe occurs first, then islpci_open does once the
> user ifconfig ethx up's the device.
> 
> It *may* be that you really do have a fauly Cardbus socket or card. At
> least this was the case for me. I was able to determine this by
> increasing the schedule_timeout a bit (HZ*6) value and increasing the 
> count max value in the for loop at the end of islpci_reset. What I did
> was bring up the interface (ifconfig eth1 up) and I had another window
> with `tail -f /var/log/kern.log`. If I wobbled the card the interrupt 
> would go through. So my card works, but my socket is messed up.
> 
> Anyway, all this is just to have the driver act *appropriately*. Should
> you want to be aventerous you can just minimize islpci_reset_if so that
> it doesn't wait for the ISL38XX_INT_IDENT_INIT interrupt and just
> proceeds *assuming* the soft reset completed successfully.  You can do
> this by having a minimalistic islpci_reset_if like the one that follows:
> 
> --
> static int
> islpci_reset_if(islpci_private *priv, int init_interrupt)
> {
> 	if (init_interrupt)
>                 isl38xx_interface_reset(priv->device_base,
> 			priv->device_host_address); 
> 	islpci_set_state(priv, PRV_STATE_INIT);
> 	/* Wait a bit, just to assume the soft reset went through OK,
> 	 * decrease at your own will */
> 	udelay(ISL38XX_WRITEIO_DELAY*5);
> 	prism54_mib_init_work(priv);
> 	islpci_set_state(priv, PRV_STATE_READY);
> 	return 0;
> }			
> --
> 
> A side note is that we have similar wait paranoia behaviour for 
> islpci_mgt_transaction in islpci_dev.c so don't be stranged if you see 
> a next "ethx: timeout waiting for mgmt response xxxx, trigging device"
> message.
> 
> Feel free to try the above suggestions then (separately):
> 1. Move the ISL38XX_INT_IDENT_INIT interrupt interrupt at the
> beginning of isl38xx_interface_reset in isl_38xx.c 
> 2. Don't do the check for completion in islpci_reset_if, assume the 
> soft reset went through fine.
> 
> Let us know how it went.
> 
> 	Luis
> _______________________________________________
> Prism54-devel mailing list
> Prism54-devel@prism54.org
> http://prism54.org/mailman/listinfo/prism54-devel