Bug 137960

Summary: marvell giga eth. unusable on Pegasos
Product: [openSUSE] SUSE Linux 10.1 Reporter: peter czanik <peter>
Component: KernelAssignee: Olaf Hering <ohering>
Status: RESOLVED FIXED QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None    
Version: unspecified   
Target Milestone: ---   
Hardware: PowerPC   
OS: Other   
Whiteboard:
Found By: Other Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: mv643xx-request_irq-lock.patch

Description peter czanik 2005-12-10 08:57:14 UTC
The on-board marvell giga ethernet on Pegasos seems to be unusable.  I wanted to use it now for installation, but it's extremly slow (7% of the root image was downloaded in about 20 minutes, so I stop now).
I also have a long message on F4, starting with:
"Debug: sleeping function called from invalid context at mm/slab.c:2459"
and has a line mentioning the marvell driver:
"[d2178014] mv643xx_eth_open+0x40/0xb0 [mv643xx_eth]"
It's on factory, as of dec. 8.
Comment 1 Karsten Keil 2005-12-12 12:53:26 UTC
Please give us some more infos about this HW.
At least 'lspci -v'  and 'lspci -vn' output for the marvell device.
Which driver is used (lsmod output).
Please also try to boot with failsafe settings.
Comment 2 Karsten Keil 2005-12-14 11:37:25 UTC
Sorry I was not aware that this is PPC specific stuff.
Comment 3 Olaf Hering 2005-12-19 13:32:48 UTC
still there with rc6:

MV-643xx 10/100/1000 Ethernet Driver
eth1: port 1 with MAC address 00:2b:2f:de:ad:01
eth1: Scatter Gather Enabled
eth1: TX TCP/IP Checksumming Supported
eth1: RX TCP/UDP Checksum Offload ON 
eth1: RX NAPI Enabled 
eth1: Using SRAM
Debug: sleeping function called from invalid context at mm/slab.c:2472
in_atomic():0, irqs_disabled():1
Call Trace:
[CB32DCF0] [C000AFCC] show_stack+0x54/0x180 (unreliable)
[CB32DD10] [C0027CD4] __might_sleep+0xbc/0xd0
[CB32DD20] [C005E50C] kmem_cache_alloc+0x34/0x108
[CB32DD40] [C01C5F40] rand_initialize_irq+0x40/0x6c
[CB32DD60] [C0054104] setup_irq+0x5c/0x154
[CB32DD90] [C0054284] request_irq+0x88/0xb8
[CB32DDC0] [D22820A0] mv643xx_eth_open+0x44/0xb4 [mv643xx_eth]
[CB32DDE0] [C0257394] dev_open+0x70/0xd8
[CB32DE00] [C02554F0] dev_change_flags+0x6c/0x13c
[CB32DE20] [C02A2818] devinet_ioctl+0x280/0x708
[CB32DE80] [C02A319C] inet_ioctl+0xb4/0x100
[CB32DE90] [C02C0078] packet_ioctl+0x15c/0x188
[CB32DEB0] [C024B998] sock_ioctl+0x30c/0x334
[CB32DED0] [C00922F4] do_ioctl+0x3c/0x88
[CB32DEE0] [C0092728] vfs_ioctl+0x3e8/0x424
[CB32DF10] [C00927CC] sys_ioctl+0x68/0x98
[CB32DF40] [C000FAEC] ret_from_syscall+0x0/0x4c
--- Exception: c01 at 0x7f6be80
    LR = 0x7fec9d0
eth1: no IPv6 routers present
Comment 4 Olaf Hering 2005-12-19 14:06:56 UTC
I tried the 10.0 kernel, and it doesnt appear to work reliable. it gets a dhcp ip, but login is not possible.
Comment 5 Olaf Hering 2006-01-02 17:24:58 UTC
Created attachment 61863 [details]
mv643xx-request_irq-lock.patch

this patch will likely fix it.
Comment 6 Olaf Hering 2006-01-03 13:54:52 UTC
it still calls kmalloc inside the spinlock. the link appears to work with the spinlock removed.
but the transfer is very slow.
Comment 7 Olaf Hering 2006-02-06 19:07:47 UTC
transfer between 2 hosts works ok in 2.6.16-rc2. I guess the limiting factor is not disk IO:

 rsync -avP SLES-10-ppc-Beta3.iso 1.1.1.2:/media/gentoo_cantaloup/tmp

SLES-10-ppc-Beta3.iso
  4689186816 100%    8.74MB/s    0:08:31  (1, 100.0% of 1)
Comment 8 peter czanik 2006-02-11 11:20:15 UTC
Tested on SLES10 beta3, it worked fine during installation. I'll open a seperate bugreport for YaST.