Bug 119491 - (NET ACENIC)acenic oops - ethtool/copy_user ??
(NET ACENIC)acenic oops - ethtool/copy_user ??
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Arjan van de Ven
:
: 118102 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-03-30 16:54 EST by Matt Richard
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version: 2.6.6-1.435
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-06-19 08:24:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matt Richard 2004-03-30 16:54:03 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.7b) Gecko/20040316

Description of problem:
With an Acenic nic installed (Asante Friendlynet flavor), kudzu causes
a kernel oops when it runs.

If I bypass (only) kudzu on boot, the system boots normally.  I booted
the system this way and then ran kudzu from the command line to get
this oops log.

If I remove the card the system boots normally.

I tried two identical cards, one used slightly and one fresh from
shrinkrwap.

Hardware is otherwise a stock Compaq Evo.
CPU: Intel(R) Pentium(R) 4 CPU 1.80GHz stepping 02
PCI: PCI BIOS revision 2.10 entry at 0xebb57, last bus=2


Version-Release number of selected component (if applicable):
kudzu-1.1.53, kernel-2.6.3-2.1.253.2.1

How reproducible:
Always

Steps to Reproduce:
1. find an Asante Friendlynet acenic card
2. install it in a PCI slot
3. boot Fedora Core 
    

Actual Results:  kernel oopsed

Expected Results:  kernel shouldn't oops...

Additional info:

Mar 30 15:59:19 mls-dhcp-30 kernel: acenic.c: v0.92 08/05/2002  Jes
Sorensen, linux-acenic@SunSITE.dk
Mar 30 15:59:19 mls-dhcp-30 kernel:                            
http://home.cern.ch/~jes/gige/acenic.html
Mar 30 15:59:19 mls-dhcp-30 kernel: eth%%d: Alteon AceNIC Gigabit
Ethernet at 0xf8400000, irq 10
Mar 30 15:59:19 mls-dhcp-30 kernel:   Tigon II (Rev. 6), Firmware:
12.4.11, MAC: 00:00:94:c5:9f:c1
Mar 30 15:59:19 mls-dhcp-30 kernel:   PCI cache line size set
incorrectly (32 bytes) by BIOS/FW, correcting to 128
Mar 30 15:59:19 mls-dhcp-30 kernel:   PCI bus width: 32 bits, speed:
33MHz, latency: 64 clks
Mar 30 15:59:19 mls-dhcp-30 kernel: eth%%d: Firmware up and running
Mar 30 15:59:19 mls-dhcp-30 kernel: Unable to handle kernel paging
request at virtual address 22b813c0
Mar 30 15:59:19 mls-dhcp-30 kernel:  printing eip:
Mar 30 15:59:19 mls-dhcp-30 kernel: 22a8edd5
Mar 30 15:59:19 mls-dhcp-30 kernel: *pde = 01562067
Mar 30 15:59:19 mls-dhcp-30 kernel: Oops: 0000 [#1]
Mar 30 15:59:19 mls-dhcp-30 kernel: CPU:    0
Mar 30 15:59:19 mls-dhcp-30 kernel: EIP:    0060:[<22a8edd5>]    Not
tainted
Mar 30 15:59:19 mls-dhcp-30 kernel: EFLAGS: 00010206  
(2.6.3-2.1.253.2.1) 
Mar 30 15:59:19 mls-dhcp-30 kernel: EIP is at ace_ioctl+0x261/0x2be
[acenic]
Mar 30 15:59:19 mls-dhcp-30 kernel: eax: 00000007   ebx: 0000001f  
ecx: 0000001e   edx: 22a8fc90
Mar 30 15:59:19 mls-dhcp-30 kernel: esi: 22b813c0   edi: 10a3ae28  
ebp: 1a1ef840   esp: 10a3adfc
Mar 30 15:59:19 mls-dhcp-30 kernel: ds: 007b   es: 007b   ss: 0068
Mar 30 15:59:19 mls-dhcp-30 kernel: Process kudzu (pid: 3100,
threadinfo=10a3a000 task=1288d980)
Mar 30 15:59:19 mls-dhcp-30 kernel: Stack: 10a3af30 10a3aef8 00000003
6e656361 00006369 00000000 00000000 00000000 
Mar 30 15:59:19 mls-dhcp-30 kernel:        00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 
Mar 30 15:59:19 mls-dhcp-30 kernel:        00000000 00000000 00000000
342e3231 0031312e 00000000 00000000 00000000 
Mar 30 15:59:19 mls-dhcp-30 kernel: Call Trace:
Mar 30 15:59:19 mls-dhcp-30 kernel:  [<021c16fa>]
task_has_capability+0x4c/0x54
Mar 30 15:59:19 mls-dhcp-30 kernel:  [<22a8eb74>] ace_ioctl+0x0/0x2be
[acenic]
Mar 30 15:59:19 mls-dhcp-30 kernel:  [<02274ac0>] dev_ethtool+0x21b/0x227
Mar 30 15:59:19 mls-dhcp-30 kernel:  [<02272f11>] dev_ioctl+0x117/0x283
Mar 30 15:59:19 mls-dhcp-30 kernel:  [<022aceb2>] inet_ioctl+0x92/0x9b
Mar 30 15:59:19 mls-dhcp-30 kernel:  [<0226b07c>] sock_ioctl+0x2d7/0x38d
Mar 30 15:59:19 mls-dhcp-30 kernel:  [<0226b4c7>] sys_socket+0x2a/0x3d
Mar 30 15:59:19 mls-dhcp-30 kernel:  [<0217c1cb>] sys_ioctl+0x2a0/0x341
Mar 30 15:59:19 mls-dhcp-30 kernel: 
Mar 30 15:59:19 mls-dhcp-30 kernel: Code: ac aa 84 c0 75 f7 f3 aa 85
ed 74 1a 8b 85 04 01 00 00 85 c0
Comment 1 Alan Cox 2004-05-03 13:56:01 EDT
*** Bug 118102 has been marked as a duplicate of this bug. ***
Comment 2 Lars Damerow 2004-05-07 12:32:33 EDT
I'm seeing the same oops with FC2 test3, kernel 2.6.5-1.351smp. It
doesn't happen when bring the interface up manually or running ethtool
afterware--both work fine. The oops only occurs when running /sbin/ifup.

cheers,
lars
Comment 3 Mark McCallister 2004-05-18 21:47:45 EDT
I'm seeing this with fedora core 2 final. It will crash on install after
verifying the dvd media. I'm using a netgear GA620T. I had to actually
remove the card from the system to get it to install. 

Is this getting any traction? I was hoping to migrate about half of my
~100 clients to fedora core 2 for testing. Of those, about 20 of them
have these netgear cards.
Comment 4 Alexander Viro 2004-05-29 07:03:59 EDT
static char version[] __initdata = ...
and
                strncpy(info.version, version, sizeof(info.version) - 1);
in the ioctl().

*DUH*
Comment 5 Chris Walters 2004-06-11 01:08:10 EDT
I'm using FC2 Release on ABIT NF7 Series Motherboard. I was originally
using the on-board ethernet but it kept stalling after downloading the
linux-2.6.5.tar.bz. I'm now using AceNIC Gigabit... kudzu crashed (and
caused my /etc/fstab to be trashed on xfs!). I disabled kudzu but the
bloody system still managed to use ethtool and got the same crash. In
the end I renamed ethtool and the system now works.
Comment 6 Arjan van de Ven 2004-06-19 08:24:11 EDT
this is supposed to be fixed in the current update kernel (435).

Note You need to log in before you can comment on or make changes to this bug.