Re: [Bug] invalid mac address after rebooting (2.6.12-rc2-mm2)

[Daniel Ritz]

On Tuesday 19 April 2005 00:19, Peter Baumann wrote:
> 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 <daniel.ritz@xxxxxx>
> > 
> > --- 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.

ok, nice to see it working. 
andrew, could you add it to -mm please?
[ adding jeff to cc: because it's a network driver :) ]

thanks, rgds
-daniel

 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/