Re: Very strange Marvell/Yukon Gigabit NIC networking problems

Forwarding on, please reply-to-all in future.

Steve Kieu wrote:

Hi all,

I have "fixed" the problem in a very wierd way.Reading
your post I thought maybe when removing the driver
itself it set some bit incorrectly. Then I decided to
do:

Boot with init=/bin/bash  so bypass all other things.
modprobe skge

run ifconfig eth0 ip_num  up


ping  a host

then while pinging hit Ctrl+Alt+Del key to hot reboot
the system.

I still see the light at the hub lits. Now I boot to
winXP and as I expected , it worked!

No I boot 2.6.11 and it worked, so the problem resolve
but I am tooooo scared to run 2613 now :-)

Hope this information helps debuging the driver.

Thanks.

S.KIEU

on 2.6.11/12 when it isn't working maybe you should send us the output
of lspci -vvv

just a hint, I'm guessing its power management related, and / or
something to do with the pci bus code.

On 8/30/05, Daniel Drake [off-list ref] wrote:

Forwarding on, please reply-to-all in future.

Steve Kieu wrote:

quoted

Hi all,

I have "fixed" the problem in a very wierd way.Reading
your post I thought maybe when removing the driver
itself it set some bit incorrectly. Then I decided to
do:

Boot with init=/bin/bash  so bypass all other things.
modprobe skge

run ifconfig eth0 ip_num  up


ping  a host

then while pinging hit Ctrl+Alt+Del key to hot reboot
the system.

I still see the light at the hub lits. Now I boot to
winXP and as I expected , it worked!

No I boot 2.6.11 and it worked, so the problem resolve
but I am tooooo scared to run 2613 now :-)

Hope this information helps debuging the driver.

Thanks.

S.KIEU

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Tue, 30 Aug 2005 13:18:57 -0700
Jesse Brandeburg [off-list ref] wrote:

on 2.6.11/12 when it isn't working maybe you should send us the output
of lspci -vvv

just a hint, I'm guessing its power management related, and / or
something to do with the pci bus code.

Also, the dmesg output with skge driver will show chip version and revision.
The problem is obviously some of the chip initialization that is complex
with the Marvell chips. Something is probably missing.  There was a fix
in the latest 2.6.13 that is probably related:

	http://www.mail-archive.com/netdev@vger.kernel.org/msg00438.html

Ok, I reproduce the problem and attached several lspci
log here

--- Stephen Hemminger <shemminger@osdl.org> wrote:

On Tue, 30 Aug 2005 13:18:57 -0700
Jesse Brandeburg [off-list ref] wrote:

quoted

on 2.6.11/12 when it isn't working maybe you

should send us the output

quoted

of lspci -vvv

just a hint, I'm guessing its power management

related, and / or

quoted

something to do with the pci bus code.

Also, the dmesg output with skge driver will show
chip version and revision.
The problem is obviously some of the chip
initialization that is complex
with the Marvell chips. Something is probably
missing.  There was a fix
in the latest 2.6.13 that is probably related:

http://www.mail-archive.com/netdev@vger.kernel.org/msg00438.html

S.KIEU


	

	
		
____________________________________________________ 
Do you Yahoo!? 
The New Yahoo! Movies: Check out the Latest Trailers, Premiere Photos and full Actor Database. 
http://au.movies.yahoo.com

You have a version of the Marvell Yukon that was affected
by a fix in 2.6.13.
	skge addr 0xfeaf8000 irq 19 chip Yukon-Lite rev 9

Both the skge and sk98lin driver were fixed to check for this.
Without the fix, the chip will be in the wrong power mode.

The version of sk98lin driver from SysKonnect already had the
fix, so if your distro used that one, it would have the reset
the power mode as needed.

--- Stephen Hemminger <shemminger@osdl.org> wrote:

You have a version of the Marvell Yukon that was
affected
by a fix in 2.6.13.
	skge addr 0xfeaf8000 irq 19 chip Yukon-Lite rev 9

Both the skge and sk98lin driver were fixed to check
for this.
Without the fix, the chip will be in the wrong power
mode.

The version of sk98lin driver from SysKonnect
already had the
fix, so if your distro used that one, it would have
the reset
the power mode as needed.

I am afraid not. The last time, I reproduced the
problem using the latest sk98lin driver from
SysKonnect  (run create patch and patch the kernel
2.6.13). Problem still there. The file I got from
sysconnect is:

install-8_23.tar.bz2

S.KIEU


	

	
		
____________________________________________________ 
Do you Yahoo!? 
The New Yahoo! Movies: Check out the Latest Trailers, Premiere Photos and full Actor Database. 
http://au.movies.yahoo.com

On Wed, 31 Aug 2005 07:49:37 +1000 (EST)
Steve Kieu [off-list ref] wrote:

Just look for references to CHIP_REV_YU_LITE_A3 in the driver
	sk98lin/skgeinit.c and sk98lin/skxmac2.c
The comparison should always be:
	pAC->GIni.GIChipRev >= CHIP_REV_YU_LITE_A3
otherwise it will not correctly take chip out of powerdown (coma) mode.

--- Stephen Hemminger <shemminger@osdl.org> wrote:

On Wed, 31 Aug 2005 07:49:37 +1000 (EST)

quoted

install-8_23.tar.bz2

Just look for references to CHIP_REV_YU_LITE_A3 in
the driver
	sk98lin/skgeinit.c and sk98lin/skxmac2.c
The comparison should always be:

Have a look but no clue to patch it, there are one
instance of comparing

	pAC->GIni.GIChipRev >= CHIP_REV_YU_LITE_A3
otherwise it will not correctly take chip out of
powerdown (coma) mode.

please send me a patch to the install-8_23.tar.bz2
then I can test. Or intruct more details, which line
and what should change then I can do manually.

I have nerver done device driver programming in my
life!

S.KIEU

Send instant messages to your online friends http://au.messenger.yahoo.com 

Stephen Hemminger wrote:

You have a version of the Marvell Yukon that was affected
by a fix in 2.6.13.
	skge addr 0xfeaf8000 irq 19 chip Yukon-Lite rev 9

Both the skge and sk98lin driver were fixed to check for this.
Without the fix, the chip will be in the wrong power mode.

The version of sk98lin driver from SysKonnect already had the
fix, so if your distro used that one, it would have the reset
the power mode as needed.

So, am I right in saying we can't do anything in skge to work around this to 
allow those older buggy drivers to work on the next reboot? More reports are 
cropping up, e.g.:

	http://forums.gentoo.org/viewtopic-t-375828.html

Given that it seems to be affecting the Windows drivers too, it would be great 
if something could be done.

Thanks,
Daniel

On Wed, 31 Aug 2005 10:09:48 +1000 (EST)
Steve Kieu [off-list ref] wrote:

I don't fix the out of tree vendor driver. sorry.