|Summary:||dl2k (D-Link DGE-550T) "badness" at startup|
|Product:||Red Hat Enterprise Linux 4||Reporter:||Barry K. Nathan <barryn>|
|Component:||kernel||Assignee:||Barry K. Nathan <barryn>|
|Status:||CLOSED WONTFIX||QA Contact:||Brian Brock <bbrock>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-06-20 16:08:53 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Barry K. Nathan 2005-05-13 10:53:35 UTC
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050421 Red Hat/1.0.3-1.4.1.centos4 Firefox/1.0.3 Description of problem: At boot, the dl2k driver causes a "badness" stack trace to appear in the kernel logs. This *always* happens. This has been happening since kernel-2.6.9-6.40.EL. I don't know if it happened in earlier kernels; I ran the earlier kernels with one of this system's two onboard Marvell NICs, until I discovered that RHEL 3 (which this system dual-boots) ships the sk98lin driver in kernel-unsupported, and an ancient broken version at that. (To be honest, this system is booting a CentOS 4 userspace. However, the kernel is downloaded directly from http://people.redhat.com/davej/kernels/RHEL4/ so I figure I should report the bug here. If you need me to reproduce the bug with genuine RHEL 4, I'll reinstall and do that.) Version-Release number of selected component (if applicable): kernel-2.6.9-10.EL How reproducible: Always Steps to Reproduce: 1. Boot system. 2. Run "dmesg". 3. Read the portion of the output that didn't scroll off the screen. Actual Results: [snip...] ip_conntrack version 2.1 (7927 buckets, 63416 max) - 356 bytes per conntrack Badness in mii_wait_link at drivers/net/dl2k.c:1500 [<f88297ae>] mii_wait_link+0x65/0x7b [dl2k] [<f8828b5c>] rio_error+0x21/0x193 [dl2k] [<f88281fe>] rio_interrupt+0x7f/0xac [dl2k] [<c0107df7>] handle_IRQ_event+0x25/0x4f [<c0108731>] do_IRQ+0x11c/0x242 [<c0303838>] common_interrupt+0x18/0x20 [<f8827b11>] rio_open+0x20e/0x216 [dl2k] [<c02a7d2b>] dev_open+0x2d/0x6b [<c02a912b>] dev_change_flags+0x48/0xed [<c02e4d03>] devinet_ioctl+0x2b2/0x61d [<c02e687e>] inet_ioctl+0x79/0xa5 [<c029f6ab>] sock_ioctl+0x2dd/0x38b [<c01770c5>] sys_ioctl+0x297/0x336 [<c03036f3>] syscall_call+0x7/0xb eth0: Link up [snip...] Expected Results: nothing out of the ordinary Additional info:
Comment 1 Barry K. Nathan 2005-05-13 10:54:33 UTC
Oops, sorry about the bug being so wide. I keep forgetting that the new Bugzilla doesn't automatically word-wrap the way the old one did.
Comment 2 John W. Linville 2005-05-18 19:19:40 UTC
That message is only a warning, intended for driver authors to avoid calling mdelay. It was intentionally added by RH, and there doesn't seem to be any appetite for changing it back... I'm sorry it irritates you. At least now you know that it can be (reasonably) safely ignored... :-)
Comment 3 Barry K. Nathan 2005-05-19 08:49:24 UTC
Oh, ok. I had no idea how serious it really was; I guess it's less serious than I could have possibly imagined. ;) (If I think I can fix this without too much difficulty, I'll reopen this bug. If I get swamped with stuff then I may not do that for a month or two, though.)
Comment 4 Barry K. Nathan 2005-05-19 09:01:56 UTC
[/me Googles and reads code...] Never mind, I take back my "less serious than I could have possibly imagined" comment. (I'll continue looking into this.)
Comment 5 Barry K. Nathan 2005-05-19 09:53:55 UTC
Reopening bug and reassigning to myself so that I can try to fix it (hopefully soon).
Comment 6 Red Hat Bugzilla 2007-02-05 19:07:56 UTC
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
Comment 7 Jiri Pallich 2012-06-20 16:08:53 UTC
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. Please See https://access.redhat.com/support/policy/updates/errata/ If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.