Hi there,
With the earlier discussion about the eepro100 vs the e100, and with
hotplug PCI going into the -ac series kernel, I think it's topical I
discuss an APM related quirk.
If you buy a Dell Inspiron with the inbuilt ethernet option, you get a PCI
eepro100. If you suspend and resume, however, the card seems to be in a
funny state that an rmmod/modprobe won't fix.
I worked around the problem, by adding to the APM config this pre-suspend
action:
ifdown eth0
rmmod eepro100
And to the resume action:
setpci -s8:4 4=17 5=1 c=8 d=20 11=f0 12=ff 13=fb \
14=c1 15=dc 1a=e0 1b=fb 33=fc 3c=b
ifup eth0
The setpci command was derived by comparing the contents of the PCI
configuration area for that device before and after a suspend, and
updating only the areas that changed.
Is this a job for `PCI hotplug', a eepro100 driver bug, or something else?
Sam.
Sam Vilain wrote:
>
> Hi there,
>
> With the earlier discussion about the eepro100 vs the e100, and with
> hotplug PCI going into the -ac series kernel, I think it's topical I
> discuss an APM related quirk.
>
> If you buy a Dell Inspiron with the inbuilt ethernet option, you get a PCI
> eepro100. If you suspend and resume, however, the card seems to be in a
> funny state that an rmmod/modprobe won't fix.
>
> I worked around the problem, by adding to the APM config this pre-suspend
> action:
>
> ifdown eth0
> rmmod eepro100
>
> And to the resume action:
>
> setpci -s8:4 4=17 5=1 c=8 d=20 11=f0 12=ff 13=fb \
> 14=c1 15=dc 1a=e0 1b=fb 33=fc 3c=b
Heh. That's inventive.
Does the following (untested) patch fix it?
--- linux-2.4.14-pre5/drivers/net/eepro100.c Tue Oct 9 21:31:38 2001
+++ linux-akpm/drivers/net/eepro100.c Mon Oct 29 21:15:52 2001
@@ -497,6 +497,9 @@ struct speedo_private {
unsigned short phy[2]; /* PHY media interfaces available. */
unsigned short advertising; /* Current PHY advertised caps. */
unsigned short partner; /* Link partner caps. */
+#ifdef CONFIG_PM
+ u32 pm_state[16];
+#endif
};
/* The parameters for a CmdConfigure operation.
@@ -2160,8 +2163,11 @@ static void set_rx_mode(struct net_devic
static int eepro100_suspend(struct pci_dev *pdev, u32 state)
{
struct net_device *dev = pci_get_drvdata (pdev);
+ struct speedo_private *sp = (struct speedo_private *)dev->priv;
long ioaddr = dev->base_addr;
+ pci_save_state(pdev, sp->pm_state);
+
if (!netif_running(dev))
return 0;
@@ -2177,6 +2183,8 @@ static int eepro100_resume(struct pci_de
struct net_device *dev = pci_get_drvdata (pdev);
struct speedo_private *sp = (struct speedo_private *)dev->priv;
long ioaddr = dev->base_addr;
+
+ pci_restore_state(pdev, sp->pm_state);
if (!netif_running(dev))
return 0;
In article <[email protected]> you wrote:
> Hi there,
> And to the resume action:
> setpci -s8:4 4=17 5=1 c=8 d=20 11=f0 12=ff 13=fb \
> 14=c1 15=dc 1a=e0 1b=fb 33=fc 3c=b
> ifup eth0
> Is this a job for `PCI hotplug', a eepro100 driver bug, or something else?
For the Red Hat Linux kernel we added a quirk for this machine that restores
PCI config space on restore, so that this is no longer needed. It's kind of
a hack so I haven't sent it to Linus for merging yet....
Arjan,
> For the Red Hat Linux kernel we added a quirk for this machine that
> restores PCI config space on restore, so that this is no longer needed.
> It's kind of a hack so I haven't sent it to Linus for merging yet....
Is this the 'resume=force' stuff, by any chance? (driver/pci/bridge.c
et al.)?
I am trying to port this (only) to 2.4.12-ac5 or later, as I think
the lack of this may be why resume dies on the T23. If you have
a ready-made diff containing this, I would be very grateful
& will try here, & report back.
--
Alex Bligh