On Sun, Apr 17, 2005 at 10:26:43PM +0200, Daniel Ritz wrote:
> from your dmesg:
> PCI: 0000:00:0b.0 pmc: 7601, current_state, pmcsr: 000000040, new: 0000
> ACPI: PCI Interrupt 0000:00:0b.0[A] -> GSI 19 (level, low) -> IRQ 19
> 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
> 0000:00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0xac00. Vers LK1.1.19
> PCI: 0000:00:0b.0 pmc: 7601, current_state, pmcsr: 000000000000, new: 0003
>
> so the device is sent to D3 right after it is up. nice.
>
> and second boot:
> PCI: 0000:00:0b.0 pmc: 7601, current_state, pmcsr: 000000040, new: 0000
> PCI: Enabling device 0000:00:0b.0 (0000 -> 0003)
> ACPI: PCI Interrupt 0000:00:0b.0[A] -> GSI 19 (level, low) -> IRQ 19
> 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
> 0000:00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1000. Vers LK1.1.19
> PCI: Setting latency timer of device 0000:00:0b.0 to 64
> *** EEPROM MAC address is invalid.
> 3c59x: vortex_probe1 fails. Returns -22
> 3c59x: probe of 0000:00:0b.0 failed with error -22
>
> to me it looks like during the second boot the device is in D3 and has
> troubles coming out of it. unfortunatley that is not made visible by the
> debugging patch. a hexdump of the device in a second boot without
> loading the 3c59x driver would tell us...
>
> the diff in the hexdumps of the config space proves that the device
> is programmed wrong:
> --- hexdump-2.6.12-rc2-mm3-withdebugpatch_1.txt 2005-04-17 21:27:28.000000000 +0200
> +++ hexdump-2.6.12-rc2-mm3-withdebugpatch_2.txt 2005-04-17 21:27:32.000000000 +0200
> @@ -1,7 +1,7 @@
> -0000000 10b7 9055 0007 0210 0024 0200 2008 0000
> -0000010 ac01 0000 2000 e800 0000 0000 0000 0000
> +0000000 10b7 9055 0003 0210 0024 0200 4000 0000
> +0000010 0001 0000 0000 0000 0000 0000 0000 0000
>
> so the I/O ports and the iomem are not set!
>
> 0000020 0000 0000 0000 0000 0000 0000 10b7 9055
> -0000030 0000 0000 00dc 0000 0000 0000 010a 0a0a
> +0000030 0000 0000 00dc 0000 0000 0000 0100 0a0a
> 0000040 0000 0000 0000 0000 0000 0000 0000 0000
> 0000050 0000 0000 0040 0000 0000 0000 0000 0000
> 0000060 0000 0000 0000 0000 0000 0000 0000 0000
>
> but to make it short: i think it's a driver bug. the device doesn't seem to be
> correctly reprogrammed when it is in D3 initially. and then it shouldn't be
> put into D3 during the first boot. so please try with the attached patch.
>
> rgds
> -daniel
>
> PS: does somebody have a datasheet of a 3com chip around? i could need one.
>
> -----
>
> [PATCH] 3c59x: only put the device into D3 when we're actually using WOL
>
> Signed-off-by: Daniel Ritz <[email protected]>
>
> --- 1.77/drivers/net/3c59x.c 2005-03-03 06:00:42 +01:00
> +++ edited/drivers/net/3c59x.c 2005-04-17 22:17:19 +02:00
> @@ -1581,7 +1581,8 @@
>
> if (VORTEX_PCI(vp)) {
> pci_set_power_state(VORTEX_PCI(vp), PCI_D0); /* Go active */
> - pci_restore_state(VORTEX_PCI(vp));
> + if (vp->pm_state_valid)
> + pci_restore_state(VORTEX_PCI(vp));
> pci_enable_device(VORTEX_PCI(vp));
> }
>
> @@ -2741,6 +2742,7 @@
> outl(0, ioaddr + DownListPtr);
>
> if (final_down && VORTEX_PCI(vp)) {
> + vp->pm_state_valid = 1;
> pci_save_state(VORTEX_PCI(vp));
> acpi_set_WOL(dev);
> }
> @@ -3243,9 +3245,10 @@
> outw(RxEnable, ioaddr + EL3_CMD);
>
> pci_enable_wake(VORTEX_PCI(vp), 0, 1);
> +
> + /* Change the power state to D3; RxEnable doesn't take effect. */
> + pci_set_power_state(VORTEX_PCI(vp), PCI_D3hot);
> }
> - /* Change the power state to D3; RxEnable doesn't take effect. */
> - pci_set_power_state(VORTEX_PCI(vp), PCI_D3hot);
> }
>
The patch solved it. Thank you for your help.
-Peter Baumann
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
