Hi,
i am seeing irregular crashes on boot in the sky2_mac_intr. This is an
Fujitsu Siemens Lifebook E8110 with a Core Duo. Currently i suspect some
strange BIOS issues as the issues i see with the sky2 aka parity errors
etc i also see sometimes with the integrated ipw3945 which complains
about firmware errors. It seems the BIOS randomly fails to initialize
all the hardware. To reproduce this crash and catch it on the serial
console it took me around 12 boots. The machine is stable once correctly
booted and i work most of the day on it.
[ 46.479939] ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 19
[ 46.568569] sky2 0000:02:00.0: v1.16 addr 0xf0000000 irq 19 Yukon-EC Ultra (0xb4) rev 2
[ 46.664555] sky2 eth0: addr 00:17:42:13:45:8c
[ 61.958741] sky2 eth1: enabling interface
[ 62.010834] sky2 eth1: phy write timeout
The problem is related to power management. The PHY has a number of PCI configuration
registers for power control, and the function of these changes based on the version and
revision of the chip. The driver does work on older versions of the EC-U, in
Fujitsu laptop's, it is just the new rev that is broken.
The driver should probably fail smarter (by not loading) if the PHY isn't powered
up correctly, but that doesn't help your problem.
The vendor has provided me with documentation on many versions
of the chip, but I don't have doc's on the lastest revision differences of the EC Ultra,
so a proper solution is not easily available. The best method for resolving this would
be to first try the vendor driver version of sk98lin and see if that fixes it. If so,
then it is easy to change sky2, to match the phy setup in the vendor driver.
Another possibility is to look for places in sky2 driver where there are places
that compare version/revision.
The most likely bits that need to change are in PCI registers: 0x80, 0x84 and 0x88
You could also load the windows driver and dump PCI config space (with lspci from
cygwin), and see what the settings are there.
I am away from my office for a month, and therefore away from any sky2
hardware for testing.
On Tue, Jul 24, 2007 at 09:50:08AM +0100, Stephen Hemminger wrote:
The problem is related to power management. The PHY has a number of PCI configuration
registers for power control, and the function of these changes based on the version and
revision of the chip. The driver does work on older versions of the EC-U, in
Fujitsu laptop's, it is just the new rev that is broken.
The driver should probably fail smarter (by not loading) if the PHY isn't powered
up correctly, but that doesn't help your problem.
The vendor has provided me with documentation on many versions
of the chip, but I don't have doc's on the lastest revision differences of the EC Ultra,
so a proper solution is not easily available. The best method for resolving this would
be to first try the vendor driver version of sk98lin and see if that fixes it. If so,
then it is easy to change sky2, to match the phy setup in the vendor driver.
Another possibility is to look for places in sky2 driver where there are places
that compare version/revision.
The most likely bits that need to change are in PCI registers: 0x80, 0x84 and 0x88
You could also load the windows driver and dump PCI config space (with lspci from
cygwin), and see what the settings are there.
I am away from my office for a month, and therefore away from any sky2
hardware for testing.
I'll try the above and keep you posted. The crash itself seems to be a
2.6.23-rc1 regression though. I never experienced this with 2.6.22-rc5
which i was running before.
Flo
--
Florian Lohoff flo@rfc822.org +49-171-2280134
Those who would give up a little freedom to get a little
security shall soon have neither - Benjamin Franklin
From: Michal Piotrowski <hidden> Date: 2007-07-24 23:30:43
Hi Florian,
On 24/07/07, Florian Lohoff [off-list ref] wrote:
On Tue, Jul 24, 2007 at 09:50:08AM +0100, Stephen Hemminger wrote:
quoted
The problem is related to power management. The PHY has a number of PCI configuration
registers for power control, and the function of these changes based on the version and
revision of the chip. The driver does work on older versions of the EC-U, in
Fujitsu laptop's, it is just the new rev that is broken.
The driver should probably fail smarter (by not loading) if the PHY isn't powered
up correctly, but that doesn't help your problem.
The vendor has provided me with documentation on many versions
of the chip, but I don't have doc's on the lastest revision differences of the EC Ultra,
so a proper solution is not easily available. The best method for resolving this would
be to first try the vendor driver version of sk98lin and see if that fixes it. If so,
then it is easy to change sky2, to match the phy setup in the vendor driver.
Another possibility is to look for places in sky2 driver where there are places
that compare version/revision.
The most likely bits that need to change are in PCI registers: 0x80, 0x84 and 0x88
You could also load the windows driver and dump PCI config space (with lspci from
cygwin), and see what the settings are there.
I am away from my office for a month, and therefore away from any sky2
hardware for testing.
I'll try the above and keep you posted. The crash itself seems to be a
2.6.23-rc1 regression though. I never experienced this with 2.6.22-rc5
which i was running before.
On Wed, Jul 25, 2007 at 01:30:31AM +0200, Michal Piotrowski wrote:
quoted
I'll try the above and keep you posted. The crash itself seems to be a
2.6.23-rc1 regression though. I never experienced this with 2.6.22-rc5
which i was running before.
Can you try to figure out what is causing this crash and then use
git-bisect?
Are there so many changes between 2.6.22-rc5 and 2.6.23-rc1 for the sky2?
As the crash is not that reproducible, just occasionally on boot i guess
bisecting is more or less waste of time.
Flo
--
Florian Lohoff flo@rfc822.org +49-171-2280134
Those who would give up a little freedom to get a little
security shall soon have neither - Benjamin Franklin
On Wed, Jul 25, 2007 at 01:30:31AM +0200, Michal Piotrowski wrote:
quoted
quoted
I'll try the above and keep you posted. The crash itself seems to be a
2.6.23-rc1 regression though. I never experienced this with 2.6.22-rc5
which i was running before.
Can you try to figure out what is causing this crash and then use
git-bisect?
Are there so many changes between 2.6.22-rc5 and 2.6.23-rc1 for the sky2?
As the crash is not that reproducible, just occasionally on boot i guess
bisecting is more or less waste of time.
Flo
--
Florian Lohoff flo@rfc822.org +49-171-2280134
Those who would give up a little freedom to get a little
security shall soon have neither - Benjamin Franklin
I would suspect these as possible causes of the regression was one of these
patches.
commit 8f70920f2f2a699b4ad35e625071cd92f4ba6ca3
Author: Stephen Hemminger [off-list ref]
Date: Mon Jun 4 17:23:25 2007 -0700
sky2: GPIO register
The General Purpose I/O register is yet another hardware workaround
catchall. Enable workaround that vendor driver does to stay
but for bug compatiable.
Signed-off-by: Stephen Hemminger [off-list ref]
Signed-off-by: Jeff Garzik [off-list ref]
commit 451af33552286b426940a32126bd3ece243223a3
Author: Stephen Hemminger [off-list ref]
Date: Mon Jun 4 17:23:24 2007 -0700
sky2: enable clocks before probe
Catch-22: On Yukon EX (88E8071) need to have internal clocks enabled
before reading chip id. It is harmless on other chips.
Signed-off-by: Stephen Hemminger [off-list ref]
Signed-off-by: Jeff Garzik [off-list ref]
commit fc99fe0618f355b708ce88fedaca9783072ac3d5
Author: Stephen Hemminger [off-list ref]
Date: Mon Jun 4 17:23:22 2007 -0700
sky2: Add PCI device specfic register 4 & 5
Need to setup more PCI control control registers are on Yukon EX.
Some of these also exist on Yukon EC-U as well.
Signed-off-by: Stephen Hemminger [off-list ref]
Signed-off-by: Jeff Garzik [off-list ref]
@@ -222,6 +222,8 @@ static void sky2_power_on(struct sky2_hwif(hw->chip_id==CHIP_ID_YUKON_EC_U||hw->chip_id==CHIP_ID_YUKON_EX){u32reg;+sky2_pci_write32(hw,PCI_DEV_REG3,0);+reg=sky2_pci_read32(hw,PCI_DEV_REG4);/* set all bits to 0 except bits 15..12 and 8 */reg&=P_ASPM_CONTROL_MSK;