Bug 9311
| Summary: | sundance -> 4port D-Link System Inc DFE-580TX -> Log errors | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Pieter E Smit (kernelbugzilla) |
| Component: | Network | Assignee: | Francois Romieu (romieu) |
| Status: | CLOSED UNREPRODUCIBLE | ||
| Severity: | low | CC: | alan, andre, dbn.lists, jel, protasnb, romieu |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.22.9 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
|
Description
Pieter E Smit
2007-11-05 14:20:54 UTC
Pieter, what is the log level on your system? (cat /proc/sys/kernel/printk) thanks. $ cat /proc/sys/kernel/printk 7 4 1 7 This will make everything with KERN_DEBUG go out in syslog. Can you try "echo 1>/proc/sys/kernel/prink" or "dmesg -n 1" and see if the messages disappear? If they do it's probably debug left in the driver. # dmesg -n 1
# cat /proc/sys/kernel/printk
1 4 1 7
>>did not work
# echo 1>/proc/sys/kernel/printk
bash: echo: write error: Invalid argument
# echo "1 1 1 1" >/proc/sys/kernel/printk
# cat /proc/sys/kernel/printk
1 1 1 1
And my syslog is clean !!
Thanks for the help.
ps. Why would the default logging be set so high ?
Spoke to quick, still dumps in syslog, while # cat /proc/sys/kernel/printk 1 1 1 1 Nov 13 00:41:54 fw1-abbot kernel: 00 1994a000 1994a010 00018001(00) 00000000 00000000 Nov 13 00:41:54 fw1-abbot kernel: 01 1994a010 1994a020 00018005(01) 00000000 00000000 Nov 13 00:41:54 fw1-abbot kernel: 02 1994a020 1994a030 00018009(02) 00000000 00000000 Nov 13 00:41:54 fw1-abbot kernel: 03 1994a030 1994a040 0001800d(03) 00000000 00000000 Nov 13 00:41:54 fw1-abbot kernel: 04 1994a040 1994a050 00018011(04) 00000000 00000000 Nov 13 00:41:54 fw1-abbot kernel: 05 1994a050 1994a060 00018015(05) 00000000 00000000 Nov 13 00:41:54 fw1-abbot kernel: 06 1994a060 1994a070 00018019(06) 00000000 00000000 Nov 13 00:41:54 fw1-abbot kernel: 07 1994a070 1994a080 0001801d(07) 00000000 00000000 Nov 13 00:41:54 fw1-abbot kernel: 08 1994a080 1994a090 00018021(08) 00000000 00000000 Nov 13 00:41:54 fw1-abbot kernel: 09 1994a090 1994a0a0 00018025(09) 00000000 00000000 Nov 13 00:41:54 fw1-abbot kernel: 0a 1994a0a0 1994a0b0 00018029(0a) 00000000 00000000 Nov 13 00:41:54 fw1-abbot kernel: 0b 1994a0b0 1994a0c0 0001802d(0b) 00000000 00000000 Nov 13 00:41:54 fw1-abbot kernel: 0c 1994a0c0 1994a0d0 00018031(0c) 00000000 00000000 Nov 13 00:41:54 fw1-abbot kernel: 0d 1994a0d0 1994a0e0 00018035(0d) 00000000 00000000 Nov 13 00:41:54 fw1-abbot kernel: 0e 1994a0e0 1994a0f0 00018039(0e) 00000000 00000000 Nov 13 00:41:54 fw1-abbot kernel: 0f 1994a0f0 1994a100 0001803d(0f) 00000000 00000000 Nov 13 00:41:54 fw1-abbot kernel: 10 1994a100 1994a110 00018041(10) 00000000 00000000 Nov 13 00:41:54 fw1-abbot kernel: 11 1994a110 1994a120 00018045(11) 00000000 00000000 Nov 13 00:41:54 fw1-abbot kernel: 12 1994a120 1994a130 00018049(12) 00000000 00000000 Nov 13 00:41:54 fw1-abbot kernel: 13 1994a130 1994a140 0001804d(13) 00000000 00000000 Nov 13 00:41:54 fw1-abbot kernel: 14 1994a140 1994a150 00018051(14) 00000000 00000000 Nov 13 00:41:54 fw1-abbot kernel: 15 1994a150 1994a160 00018055(15) 00000000 00000000 Nov 13 00:41:54 fw1-abbot kernel: 16 1994a160 1994a170 00018059(16) 00000000 00000000 Nov 13 00:41:54 fw1-abbot kernel: 17 1994a170 00000000 0001805d(17) 00000000 00000000 Nov 13 00:41:54 fw1-abbot kernel: 18 1994a180 1994a190 00018061(18) 00000000 00000000 Nov 13 00:41:54 fw1-abbot kernel: 19 1994a190 1994a1a0 00018065(19) 00000000 00000000 Nov 13 00:41:54 fw1-abbot kernel: 1a 1994a1a0 1994a1b0 00018069(1a) 00000000 00000000 Nov 13 00:41:54 fw1-abbot kernel: 1b 1994a1b0 1994a1c0 0001806d(1b) 00000000 00000000 Nov 13 00:41:54 fw1-abbot kernel: 1c 1994a1c0 1994a1d0 00018071(1c) 00000000 00000000 Nov 13 00:41:54 fw1-abbot kernel: 1d 1994a1d0 1994a1e0 00018075(1d) 00000000 00000000 Nov 13 00:41:54 fw1-abbot kernel: 1e 1994a1e0 1994a1f0 00018079(1e) 00000000 00000000 Nov 13 00:41:54 fw1-abbot kernel: 1f 1994a1f0 1994a000 0001807d(1f) 00000000 00000000 Nov 13 00:41:54 fw1-abbot kernel: TxListPtr=1994a170 netif_queue_stopped=0 Nov 13 00:41:54 fw1-abbot kernel: cur_tx=216(18) dirty_tx=216(18) Nov 13 00:41:54 fw1-abbot kernel: cur_rx=31 dirty_rx=31 Nov 13 00:41:54 fw1-abbot kernel: cur_task=216 Nov 13 00:41:54 fw1-abbot kernel: TxStatus=1700 Is CONFIG_SUNDANCE_MMIO set ? -- Ueimor Peter, can you issue a 'grep CONFIG_SUNDANCE_MMIO .config' ? Thanks in advance. -- Ueimor :/usr/src/linux# grep CONFIG_SUNDANCE_MMIO .config CONFIG_SUNDANCE_MMIO=y Re-compile 2.6.23.9-pesfw2d #1 SMP Tue Nov 27 20:19:53 SAST 2007 i686 GNU/Linux # grep CONFIG_SUNDANCE_MMIO .config # CONFIG_SUNDANCE_MMIO is not set Still in syslog. Nov 27 20:55:45 fw1-abbot kernel: 00 1fdb5000 1fdb5010 00018001(00) 00000000 00000000 Nov 27 20:55:45 fw1-abbot kernel: 01 1fdb5010 1fdb5020 00018005(01) 00000000 00000000 Nov 27 20:55:45 fw1-abbot kernel: 02 1fdb5020 1fdb5030 00018009(02) 00000000 00000000 Nov 27 20:55:45 fw1-abbot kernel: 03 1fdb5030 1fdb5040 0001800d(03) 00000000 00000000 Nov 27 20:55:45 fw1-abbot kernel: 04 1fdb5040 1fdb5050 00018011(04) 00000000 00000000 Nov 27 20:55:45 fw1-abbot kernel: 05 1fdb5050 1fdb5060 00018015(05) 00000000 00000000 Nov 27 20:55:45 fw1-abbot kernel: 06 1fdb5060 1fdb5070 00018019(06) 00000000 00000000 Nov 27 20:55:45 fw1-abbot kernel: 07 1fdb5070 1fdb5080 0001801d(07) 00000000 00000000 Nov 27 20:55:45 fw1-abbot kernel: 08 1fdb5080 1fdb5090 00018021(08) 00000000 00000000 Nov 27 20:55:45 fw1-abbot kernel: 09 1fdb5090 1fdb50a0 00018025(09) 00000000 00000000 Nov 27 20:55:45 fw1-abbot kernel: 0a 1fdb50a0 1fdb50b0 00018029(0a) 00000000 00000000 Nov 27 20:55:45 fw1-abbot kernel: 0b 1fdb50b0 1fdb50c0 0001802d(0b) 00000000 00000000 Nov 27 20:55:45 fw1-abbot kernel: 0c 1fdb50c0 1fdb50d0 00018031(0c) 00000000 00000000 Nov 27 20:55:45 fw1-abbot kernel: 0d 1fdb50d0 1fdb50e0 00018035(0d) 00000000 00000000 Nov 27 20:55:45 fw1-abbot kernel: 0e 1fdb50e0 1fdb50f0 00018039(0e) 00000000 00000000 Nov 27 20:55:45 fw1-abbot kernel: 0f 1fdb50f0 1fdb5100 0001803d(0f) 00000000 00000000 Nov 27 20:55:45 fw1-abbot kernel: 10 1fdb5100 1fdb5110 00018041(10) 00000000 00000000 Nov 27 20:55:45 fw1-abbot kernel: 11 1fdb5110 00000000 00018045(11) 00000000 00000000 Nov 27 20:55:45 fw1-abbot kernel: 12 1fdb5120 00000000 00000000(00) 00000000 00000000 Nov 27 20:55:45 fw1-abbot kernel: 13 1fdb5130 00000000 00000000(00) 00000000 00000000 Nov 27 20:55:45 fw1-abbot kernel: 14 1fdb5140 00000000 00000000(00) 00000000 00000000 Nov 27 20:55:45 fw1-abbot kernel: 15 1fdb5150 00000000 00000000(00) 00000000 00000000 Nov 27 20:55:45 fw1-abbot kernel: 16 1fdb5160 00000000 00000000(00) 00000000 00000000 Nov 27 20:55:45 fw1-abbot kernel: 17 1fdb5170 00000000 00000000(00) 00000000 00000000 Nov 27 20:55:45 fw1-abbot kernel: 18 1fdb5180 00000000 00000000(00) 00000000 00000000 Nov 27 20:55:45 fw1-abbot kernel: 19 1fdb5190 00000000 00000000(00) 00000000 00000000 Nov 27 20:55:45 fw1-abbot kernel: 1a 1fdb51a0 00000000 00000000(00) 00000000 00000000 Nov 27 20:55:45 fw1-abbot kernel: 1b 1fdb51b0 00000000 00000000(00) 00000000 00000000 Nov 27 20:55:45 fw1-abbot kernel: 1c 1fdb51c0 00000000 00000000(00) 00000000 00000000 Nov 27 20:55:45 fw1-abbot kernel: 1d 1fdb51d0 00000000 00000000(00) 00000000 00000000 Nov 27 20:55:45 fw1-abbot kernel: 1e 1fdb51e0 00000000 00000000(00) 00000000 00000000 Nov 27 20:55:45 fw1-abbot kernel: 1f 1fdb51f0 00000000 00000000(00) 00000000 00000000 Nov 27 20:55:45 fw1-abbot kernel: TxListPtr=1fdb5110 netif_queue_stopped=0 Nov 27 20:55:45 fw1-abbot kernel: cur_tx=18(12) dirty_tx=18(12) Nov 27 20:55:45 fw1-abbot kernel: cur_rx=23 dirty_rx=23 Nov 27 20:55:45 fw1-abbot kernel: cur_task=18 Nov 27 20:55:45 fw1-abbot kernel: TxStatus=1100 I've got the same problem. I also have a 4-port D-Link Ethernet NIC and the same error messages in syslog. When I stop SNMP this messages doesn't occur. But I need SNMP. Are ther any resolutions to this problem? Thanks Daniel The drivers/net/sundance.c file has this function:
static int netdev_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
{
struct netdev_private *np = netdev_priv(dev);
void __iomem *ioaddr = np->base;
int rc;
int i;
if (!netif_running(dev))
return -EINVAL;
spin_lock_irq(&np->lock);
rc = generic_mii_ioctl(&np->mii_if, if_mii(rq), cmd, NULL);
spin_unlock_irq(&np->lock);
switch (cmd) {
case SIOCDEVPRIVATE:
for (i=0; i<TX_RING_SIZE; i++) {
printk(KERN_DEBUG "%02x %08llx %08x %08x(%02x) %08x %08x\n", i,
(unsigned long long)(np->tx_ring_dma + i*sizeof(*np->tx_ring)),
le32_to_cpu(np->tx_ring[i].next_desc),
le32_to_cpu(np->tx_ring[i].status),
(le32_to_cpu(np->tx_ring[i].status) >> 2)
& 0xff,
le32_to_cpu(np->tx_ring[i].frag[0].addr),
le32_to_cpu(np->tx_ring[i].frag[0].length));
}
printk(KERN_DEBUG "TxListPtr=%08x netif_queue_stopped=%d\n",
ioread32(np->base + TxListPtr),
netif_queue_stopped(dev));
printk(KERN_DEBUG "cur_tx=%d(%02x) dirty_tx=%d(%02x)\n",
np->cur_tx, np->cur_tx % TX_RING_SIZE,
np->dirty_tx, np->dirty_tx % TX_RING_SIZE);
printk(KERN_DEBUG "cur_rx=%d dirty_rx=%d\n", np->cur_rx, np->dirty_rx);
printk(KERN_DEBUG "cur_task=%d\n", np->cur_task);
printk(KERN_DEBUG "TxStatus=%04x\n", ioread16(ioaddr + TxStatus));
return 0;
}
return rc;
}
------------------------
I.e. if cmd == SIOCDEVPRIVATE, it prints out the debug information and returns 0.
This may be because of the SIOCDEVPRIVATE being deprecated. The file include/linux/sockios.h says:
/* Device private ioctl calls */
/*
* These 16 ioctls are available to devices via the do_ioctl() device
* vector. Each device should include this file and redefine these names
* as their own. Because these are device dependent it is a good idea
* _NOT_ to issue them to random objects and hope.
*
* THESE IOCTLS ARE _DEPRECATED_ AND WILL DISAPPEAR IN 2.5.X -DaveM
*/
#define SIOCDEVPRIVATE 0x89F0 /* to 89FF */
--------------------------
Yet, the snmp package uses SIOCDEVPRIVATE. In the source for net-snmp (in file agent/mibgroup/if-mib/data_access/interface_linux.c), it uses SIOCDEVPRIVATE if it cant get a result using 0x8947 (SIOCGMIIPHY).
I conclude that the fault lies both with the net-snmp package and the sundance driver.
The sundance driver should probably implement the SIOCGMIIPHY ioctl (if it makes any sense). I don't know how to do that.
On the other hand, the net-snmp package should definately not default to using SIOCDEVPRIVATE if SIOCGMIIPHY does not yíeld a result, at least not on kernels after 2.4.
Pieter, you might want to inform the developers of net-snmp about this.
-------------
My investigations was made on a Debian etch, kernel version 2.6.18-6-amd64, and net-snmp from the net-snmp Debian package version 5.2.3-7etch2
Jorgen:
[...]
> My investigations was made on a Debian etch, kernel version 2.6.18-6-amd64,
> and
> net-snmp from the net-snmp Debian package version 5.2.3-7etch2
It took some time but the suspect code has been changed
between 2.6.24 and 2.6.25.
Could someone check if there is any remaining problem ?
--
Ueimor
I am still seeing similar issues in 2.6.25 (DFE-580TX). Bandwidth chokes up for a few seconds everytime an error pops up in syslog. I did not notice this error in 2.6.19. NETDEV WATCHDOG: eth0: transmit timed out eth0: Transmit timed out, TxStatus 00 TxFrameId 32, resetting... 00 bf81a000 bf81a010 00008001(00) 0b2c8000 8000002a 01 bf81a010 bf81a020 00008005(01) 0b2c8800 80000068 02 bf81a020 bf81a030 00008009(02) 0b2c9800 8000002a 03 bf81a030 bf81a040 0000800d(03) 0b2cc000 8000002a 04 bf81a040 bf81a050 00008011(04) 0b2ce800 8000002a 05 bf81a050 bf81a060 00008015(05) 0b2cf000 8000002a 06 bf81a060 bf81a070 00008019(06) 0b2cf800 8000002a 07 bf81a070 bf81a080 0000801d(07) 3799a8d6 800005ea 08 bf81a080 bf81a090 00008021(08) 0b2d4000 8000002a 09 bf81a090 bf81a0a0 00008025(09) 0b2d6800 8000002a 0a bf81a0a0 bf81a0b0 00008029(0a) 0b2d7000 8000002a 0b bf81a0b0 bf81a0c0 0000802d(0b) 0b2d7800 8000002a 0c bf81a0c0 bf81a0d0 00008031(0c) 0b2d8000 8000002a 0d bf81a0d0 bf81a0e0 00008035(0d) 0b2f7000 8000002a 0e bf81a0e0 bf81a0f0 00008039(0e) 0b2f7800 8000002a 0f bf81a0f0 bf81a100 0000803d(0f) 0b2f8800 8000002a 10 bf81a100 00000000 00008041(10) 0b2f9000 8000002a 11 bf81a110 bf81a120 00008045(11) 00000000 00000000 12 bf81a120 bf81a130 00008049(12) 00000000 00000000 13 bf81a130 bf81a140 0000804d(13) 0b21a000 8000002a 14 bf81a140 bf81a150 00008051(14) 0b21a800 8000002a 15 bf81a150 bf81a160 00008055(15) 68aa90d6 800005ea 16 bf81a160 bf81a170 00008059(16) 0b21b000 8000002a 17 bf81a170 bf81a180 0000805d(17) 0b2ae000 8000002a 18 bf81a180 bf81a190 00008061(18) 0b2ae800 80000068 19 bf81a190 bf81a1a0 00008065(19) 0b2af000 8000002a 1a bf81a1a0 bf81a1b0 00008069(1a) 0b2b0000 80000068 1b bf81a1b0 bf81a1c0 0000806d(1b) 0b2b0800 80000068 1c bf81a1c0 bf81a1d0 00008071(1c) b3a678d6 800005ea 1d bf81a1d0 bf81a1e0 00008075(1d) b3aed8d6 8000049e 1e bf81a1e0 bf81a1f0 00008079(1e) 0b2c7000 80000068 1f bf81a1f0 bf81a000 0000807d(1f) 0b2c7800 80000068 TxListPtr=f091ab18 netif_queue_stopped=1 cur_tx=17745(11) dirty_tx=17715(13) cur_rx=22 dirty_rx=22 cur_task=17745 (In reply to comment #14) > I am still seeing similar issues in 2.6.25 (DFE-580TX). Bandwidth chokes up > for a few seconds everytime an error pops up in syslog. Perhaps it's the other way around: The error pops up everytime the bandwith chokes up? :-) Anyway, the problem originally described here (sundance vs. snmp) has gone here after upgrading to 2.6.26 (I haven't tried on 2.6.25). |