Re: PROBLEM: 2.6.23-rc "NETDEV WATCHDOG: eth0: transmit timed out"
Hi, after reading about issues with the nics on kontron boards I did a bios upgrade, but this did not change anything. However, yesterday the nic (onboard) I used died. No link at all, after switching to the next onboard nic I got a NETDEV transmit timeout with that one on kernel 2.6.22-r2. It seems the whole thing is a hardware issue. I will try to figure out with kontron. Sorry :( Karl 2007/9/12, Francois Romieu <[EMAIL PROTECTED]>: > Karl Meyer <[EMAIL PROTECTED]> : > [...] > > am am looking for this issue for some time now, but there where no > > errors in 2.6.22-r2 (gentoo speak, I guess this is 2.6.22.2 > > officially), I also ran git-bisect (for more information see the older > > messages in this thread). > > 2.6.22-r2 in gentoo is based on 2.6.22.1. It is way before > 0e4851502f846b13b29b7f88f1250c980d57e944 that you reported to work. > Thus it is not surprizing that it works. > > Any update regarding the patchkit that I sent on 2007/08/16 ? > > It would help to narrow the culprit. > > -- > Ueimor > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.23-rc NETDEV WATCHDOG: eth0: transmit timed out
Hi, after reading about issues with the nics on kontron boards I did a bios upgrade, but this did not change anything. However, yesterday the nic (onboard) I used died. No link at all, after switching to the next onboard nic I got a NETDEV transmit timeout with that one on kernel 2.6.22-r2. It seems the whole thing is a hardware issue. I will try to figure out with kontron. Sorry :( Karl 2007/9/12, Francois Romieu [EMAIL PROTECTED]: Karl Meyer [EMAIL PROTECTED] : [...] am am looking for this issue for some time now, but there where no errors in 2.6.22-r2 (gentoo speak, I guess this is 2.6.22.2 officially), I also ran git-bisect (for more information see the older messages in this thread). 2.6.22-r2 in gentoo is based on 2.6.22.1. It is way before 0e4851502f846b13b29b7f88f1250c980d57e944 that you reported to work. Thus it is not surprizing that it works. Any update regarding the patchkit that I sent on 2007/08/16 ? It would help to narrow the culprit. -- Ueimor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.23-rc "NETDEV WATCHDOG: eth0: transmit timed out"
Hi Francois, this is what I found and sent: The error exists from patch 2 on. I did some network testing with patch 1 and currently use it and have no errors so far. >From my experiences up to now patch 1 should be error free. Do you need additional info? 2007/9/12, Francois Romieu <[EMAIL PROTECTED]>: > Karl Meyer <[EMAIL PROTECTED]> : > [...] > > am am looking for this issue for some time now, but there where no > > errors in 2.6.22-r2 (gentoo speak, I guess this is 2.6.22.2 > > officially), I also ran git-bisect (for more information see the older > > messages in this thread). > > 2.6.22-r2 in gentoo is based on 2.6.22.1. It is way before > 0e4851502f846b13b29b7f88f1250c980d57e944 that you reported to work. > Thus it is not surprizing that it works. > > Any update regarding the patchkit that I sent on 2007/08/16 ? > > It would help to narrow the culprit. > > -- > Ueimor > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.23-rc NETDEV WATCHDOG: eth0: transmit timed out
Hi Francois, this is what I found and sent: The error exists from patch 2 on. I did some network testing with patch 1 and currently use it and have no errors so far. From my experiences up to now patch 1 should be error free. Do you need additional info? 2007/9/12, Francois Romieu [EMAIL PROTECTED]: Karl Meyer [EMAIL PROTECTED] : [...] am am looking for this issue for some time now, but there where no errors in 2.6.22-r2 (gentoo speak, I guess this is 2.6.22.2 officially), I also ran git-bisect (for more information see the older messages in this thread). 2.6.22-r2 in gentoo is based on 2.6.22.1. It is way before 0e4851502f846b13b29b7f88f1250c980d57e944 that you reported to work. Thus it is not surprizing that it works. Any update regarding the patchkit that I sent on 2007/08/16 ? It would help to narrow the culprit. -- Ueimor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.23-rc "NETDEV WATCHDOG: eth0: transmit timed out"
Karl Meyer <[EMAIL PROTECTED]> : [...] > am am looking for this issue for some time now, but there where no > errors in 2.6.22-r2 (gentoo speak, I guess this is 2.6.22.2 > officially), I also ran git-bisect (for more information see the older > messages in this thread). 2.6.22-r2 in gentoo is based on 2.6.22.1. It is way before 0e4851502f846b13b29b7f88f1250c980d57e944 that you reported to work. Thus it is not surprizing that it works. Any update regarding the patchkit that I sent on 2007/08/16 ? It would help to narrow the culprit. -- Ueimor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.23-rc NETDEV WATCHDOG: eth0: transmit timed out
Karl Meyer [EMAIL PROTECTED] : [...] am am looking for this issue for some time now, but there where no errors in 2.6.22-r2 (gentoo speak, I guess this is 2.6.22.2 officially), I also ran git-bisect (for more information see the older messages in this thread). 2.6.22-r2 in gentoo is based on 2.6.22.1. It is way before 0e4851502f846b13b29b7f88f1250c980d57e944 that you reported to work. Thus it is not surprizing that it works. Any update regarding the patchkit that I sent on 2007/08/16 ? It would help to narrow the culprit. -- Ueimor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.23-rc "NETDEV WATCHDOG: eth0: transmit timed out"
Hi, am am looking for this issue for some time now, but there where no errors in 2.6.22-r2 (gentoo speak, I guess this is 2.6.22.2 officially), I also ran git-bisect (for more information see the older messages in this thread). 2007/9/3, Michal Piotrowski <[EMAIL PROTECTED]>: > Hi, > > On 01/09/07, Karl Meyer <[EMAIL PROTECTED]> wrote: > > This is what happened today: > > > > Sep 1 21:08:01 frege NETDEV WATCHDOG: eth0: transmit timed out > > frege ~ # uname -r > > 2.6.22.5-cfs-v20.5 > > Can you reproduce this on 2.6.22 (not 2.6.22.x - it might be a -stable > regression)? > > Regards, > Michal > > -- > LOG > http://www.stardust.webpages.pl/log/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.23-rc "NETDEV WATCHDOG: eth0: transmit timed out"
Hi, On 01/09/07, Karl Meyer <[EMAIL PROTECTED]> wrote: > This is what happened today: > > Sep 1 21:08:01 frege NETDEV WATCHDOG: eth0: transmit timed out > frege ~ # uname -r > 2.6.22.5-cfs-v20.5 Can you reproduce this on 2.6.22 (not 2.6.22.x - it might be a -stable regression)? Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.23-rc NETDEV WATCHDOG: eth0: transmit timed out
Hi, On 01/09/07, Karl Meyer [EMAIL PROTECTED] wrote: This is what happened today: Sep 1 21:08:01 frege NETDEV WATCHDOG: eth0: transmit timed out frege ~ # uname -r 2.6.22.5-cfs-v20.5 Can you reproduce this on 2.6.22 (not 2.6.22.x - it might be a -stable regression)? Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.23-rc NETDEV WATCHDOG: eth0: transmit timed out
Hi, am am looking for this issue for some time now, but there where no errors in 2.6.22-r2 (gentoo speak, I guess this is 2.6.22.2 officially), I also ran git-bisect (for more information see the older messages in this thread). 2007/9/3, Michal Piotrowski [EMAIL PROTECTED]: Hi, On 01/09/07, Karl Meyer [EMAIL PROTECTED] wrote: This is what happened today: Sep 1 21:08:01 frege NETDEV WATCHDOG: eth0: transmit timed out frege ~ # uname -r 2.6.22.5-cfs-v20.5 Can you reproduce this on 2.6.22 (not 2.6.22.x - it might be a -stable regression)? Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.23-rc "NETDEV WATCHDOG: eth0: transmit timed out"
This is what happened today: Sep 1 21:08:01 frege NETDEV WATCHDOG: eth0: transmit timed out frege ~ # uname -r 2.6.22.5-cfs-v20.5 2007/8/16, Francois Romieu <[EMAIL PROTECTED]>: > (please do not remove the netdev Cc:) > > Francois Romieu <[EMAIL PROTECTED]> : > [...] > > If it does not work I'll dissect 0e4851502f846b13b29b7f88f1250c980d57e944 > > tomorrow. > > You will find a tgz archive in attachment which contains a serie of patches > (0001-... to 0005-...) to walk from 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 > to 0e4851502f846b13b29b7f88f1250c980d57e944 in smaller steps. > > Please apply 0001 on top of 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2. If it > still works, apply 0002 on top of 0001, etc. > > -- > Ueimor > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.23-rc NETDEV WATCHDOG: eth0: transmit timed out
This is what happened today: Sep 1 21:08:01 frege NETDEV WATCHDOG: eth0: transmit timed out frege ~ # uname -r 2.6.22.5-cfs-v20.5 2007/8/16, Francois Romieu [EMAIL PROTECTED]: (please do not remove the netdev Cc:) Francois Romieu [EMAIL PROTECTED] : [...] If it does not work I'll dissect 0e4851502f846b13b29b7f88f1250c980d57e944 tomorrow. You will find a tgz archive in attachment which contains a serie of patches (0001-... to 0005-...) to walk from 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 to 0e4851502f846b13b29b7f88f1250c980d57e944 in smaller steps. Please apply 0001 on top of 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2. If it still works, apply 0002 on top of 0001, etc. -- Ueimor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.23-rc "NETDEV WATCHDOG: eth0: transmit timed out"
On 21-08-2007 12:56, Karl Meyer wrote: > fyi: > I do not know whether it is related to the problem, but since using > the version you told me there are these entries is my log: > frege Hangcheck: hangcheck value past margin! ... BTW, I don't know wheter it's related too, but I think you should try first to get rid of these errors: > Freeing unused kernel memory: 220k freed > usb_id[1320]: segfault at eip b7e25db2 esp bfd1d734 error 4 > usb_id[1329]: segfault at eip b7e1bdb2 esp bf9c9224 error 4 > usb_id[1322]: segfault at eip b7df3db2 esp bfcb66c4 error 4 > usb_id[1321]: segfault at eip b7e11db2 esp bf8f4b04 error 4 Regards, Jarek P. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.23-rc NETDEV WATCHDOG: eth0: transmit timed out
On 21-08-2007 12:56, Karl Meyer wrote: fyi: I do not know whether it is related to the problem, but since using the version you told me there are these entries is my log: frege Hangcheck: hangcheck value past margin! ... BTW, I don't know wheter it's related too, but I think you should try first to get rid of these errors: Freeing unused kernel memory: 220k freed usb_id[1320]: segfault at eip b7e25db2 esp bfd1d734 error 4 usb_id[1329]: segfault at eip b7e1bdb2 esp bf9c9224 error 4 usb_id[1322]: segfault at eip b7df3db2 esp bfcb66c4 error 4 usb_id[1321]: segfault at eip b7e11db2 esp bf8f4b04 error 4 Regards, Jarek P. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.23-rc "NETDEV WATCHDOG: eth0: transmit timed out"
fyi: I do not know whether it is related to the problem, but since using the version you told me there are these entries is my log: frege Hangcheck: hangcheck value past margin! frege Hangcheck: hangcheck value past margin! frege Hangcheck: hangcheck value past margin! 2007/8/16, Francois Romieu <[EMAIL PROTECTED]>: > (please do not remove the netdev Cc:) > > Francois Romieu <[EMAIL PROTECTED]> : > [...] > > If it does not work I'll dissect 0e4851502f846b13b29b7f88f1250c980d57e944 > > tomorrow. > > You will find a tgz archive in attachment which contains a serie of patches > (0001-... to 0005-...) to walk from 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 > to 0e4851502f846b13b29b7f88f1250c980d57e944 in smaller steps. > > Please apply 0001 on top of 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2. If it > still works, apply 0002 on top of 0001, etc. > > -- > Ueimor > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.23-rc NETDEV WATCHDOG: eth0: transmit timed out
fyi: I do not know whether it is related to the problem, but since using the version you told me there are these entries is my log: frege Hangcheck: hangcheck value past margin! frege Hangcheck: hangcheck value past margin! frege Hangcheck: hangcheck value past margin! 2007/8/16, Francois Romieu [EMAIL PROTECTED]: (please do not remove the netdev Cc:) Francois Romieu [EMAIL PROTECTED] : [...] If it does not work I'll dissect 0e4851502f846b13b29b7f88f1250c980d57e944 tomorrow. You will find a tgz archive in attachment which contains a serie of patches (0001-... to 0005-...) to walk from 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 to 0e4851502f846b13b29b7f88f1250c980d57e944 in smaller steps. Please apply 0001 on top of 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2. If it still works, apply 0002 on top of 0001, etc. -- Ueimor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.23-rc "NETDEV WATCHDOG: eth0: transmit timed out"
The error exists from patch 2 on. I did some network testing with patch 1 and currently use it and have no errors so far. >From my experiences up to now patch 1 should be error free. 2007/8/16, Francois Romieu <[EMAIL PROTECTED]>: > (please do not remove the netdev Cc:) > > Francois Romieu <[EMAIL PROTECTED]> : > [...] > > If it does not work I'll dissect 0e4851502f846b13b29b7f88f1250c980d57e944 > > tomorrow. > > You will find a tgz archive in attachment which contains a serie of patches > (0001-... to 0005-...) to walk from 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 > to 0e4851502f846b13b29b7f88f1250c980d57e944 in smaller steps. > > Please apply 0001 on top of 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2. If it > still works, apply 0002 on top of 0001, etc. > > -- > Ueimor > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.23-rc NETDEV WATCHDOG: eth0: transmit timed out
The error exists from patch 2 on. I did some network testing with patch 1 and currently use it and have no errors so far. From my experiences up to now patch 1 should be error free. 2007/8/16, Francois Romieu [EMAIL PROTECTED]: (please do not remove the netdev Cc:) Francois Romieu [EMAIL PROTECTED] : [...] If it does not work I'll dissect 0e4851502f846b13b29b7f88f1250c980d57e944 tomorrow. You will find a tgz archive in attachment which contains a serie of patches (0001-... to 0005-...) to walk from 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 to 0e4851502f846b13b29b7f88f1250c980d57e944 in smaller steps. Please apply 0001 on top of 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2. If it still works, apply 0002 on top of 0001, etc. -- Ueimor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.23-rc "NETDEV WATCHDOG: eth0: transmit timed out"
I did some testing today and found that the error occurs after applying some of the patches. However I did not figure out the exact patch in which the error "starts" since it sometimes occurs immediatly when moving some data over the net and sometimes it takes 30 min till I get the transmit timeout. I will be away till sunday and do some more testing then. 2007/8/16, Francois Romieu <[EMAIL PROTECTED]>: > (please do not remove the netdev Cc:) > > Francois Romieu <[EMAIL PROTECTED]> : > [...] > > If it does not work I'll dissect 0e4851502f846b13b29b7f88f1250c980d57e944 > > tomorrow. > > You will find a tgz archive in attachment which contains a serie of patches > (0001-... to 0005-...) to walk from 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 > to 0e4851502f846b13b29b7f88f1250c980d57e944 in smaller steps. > > Please apply 0001 on top of 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2. If it > still works, apply 0002 on top of 0001, etc. > > -- > Ueimor > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.23-rc "NETDEV WATCHDOG: eth0: transmit timed out"
(please do not remove the netdev Cc:) Francois Romieu <[EMAIL PROTECTED]> : [...] > If it does not work I'll dissect 0e4851502f846b13b29b7f88f1250c980d57e944 > tomorrow. You will find a tgz archive in attachment which contains a serie of patches (0001-... to 0005-...) to walk from 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 to 0e4851502f846b13b29b7f88f1250c980d57e944 in smaller steps. Please apply 0001 on top of 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2. If it still works, apply 0002 on top of 0001, etc. -- Ueimor r8169-meyer.tgz Description: GNU Zip compressed data
Re: PROBLEM: 2.6.23-rc NETDEV WATCHDOG: eth0: transmit timed out
(please do not remove the netdev Cc:) Francois Romieu [EMAIL PROTECTED] : [...] If it does not work I'll dissect 0e4851502f846b13b29b7f88f1250c980d57e944 tomorrow. You will find a tgz archive in attachment which contains a serie of patches (0001-... to 0005-...) to walk from 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 to 0e4851502f846b13b29b7f88f1250c980d57e944 in smaller steps. Please apply 0001 on top of 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2. If it still works, apply 0002 on top of 0001, etc. -- Ueimor r8169-meyer.tgz Description: GNU Zip compressed data
Re: PROBLEM: 2.6.23-rc NETDEV WATCHDOG: eth0: transmit timed out
I did some testing today and found that the error occurs after applying some of the patches. However I did not figure out the exact patch in which the error starts since it sometimes occurs immediatly when moving some data over the net and sometimes it takes 30 min till I get the transmit timeout. I will be away till sunday and do some more testing then. 2007/8/16, Francois Romieu [EMAIL PROTECTED]: (please do not remove the netdev Cc:) Francois Romieu [EMAIL PROTECTED] : [...] If it does not work I'll dissect 0e4851502f846b13b29b7f88f1250c980d57e944 tomorrow. You will find a tgz archive in attachment which contains a serie of patches (0001-... to 0005-...) to walk from 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2 to 0e4851502f846b13b29b7f88f1250c980d57e944 in smaller steps. Please apply 0001 on top of 6dccd16b7c2703e8bbf8bca62b5cf248332afbe2. If it still works, apply 0002 on top of 0001, etc. -- Ueimor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.23-rc "NETDEV WATCHDOG: eth0: transmit timed out"
Karl Meyer <[EMAIL PROTECTED]> :
> I did some additional testing, the results are:
> [0e4851502f846b13b29b7f88f1250c980d57e944] r8169: merge with version
> 8.001.00 of Realtek's r8168 driver
> does not work, I after some traffic the transmit timeout occurs.
> [6dccd16b7c2703e8bbf8bca62b5cf248332afbe2] r8169: merge with version
> 6.001.00 of Realtek's r8169 driver
> Seems to be the last version to work. I did some stress testing (much
> more than the level that was enough to make
> [0e4851502f846b13b29b7f88f1250c980d57e944] break) and am currently
> using this version and no problems so far.
Thanks for the quick feedback.
Can you try the patch below on top of 2.6.23-rc3 ?
If it does not work I'll dissect 0e4851502f846b13b29b7f88f1250c980d57e944
tomorrow.
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index b85ab4a..cdb8a08 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -2749,6 +2749,7 @@ static irqreturn_t rtl8169_interrupt(int irq, void
*dev_instance)
if (!(status & tp->intr_event))
break;
+#if 0
/* Work around for rx fifo overflow */
if (unlikely(status & RxFIFOOver) &&
(tp->mac_version == RTL_GIGA_MAC_VER_11)) {
@@ -2756,6 +2757,7 @@ static irqreturn_t rtl8169_interrupt(int irq, void
*dev_instance)
rtl8169_tx_timeout(dev);
break;
}
+#endif
if (unlikely(status & SYSErr)) {
rtl8169_pcierr_interrupt(dev);
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.23-rc "NETDEV WATCHDOG: eth0: transmit timed out"
I did some additional testing, the results are: [0e4851502f846b13b29b7f88f1250c980d57e944] r8169: merge with version 8.001.00 of Realtek's r8168 driver does not work, I after some traffic the transmit timeout occurs. [6dccd16b7c2703e8bbf8bca62b5cf248332afbe2] r8169: merge with version 6.001.00 of Realtek's r8169 driver Seems to be the last version to work. I did some stress testing (much more than the level that was enough to make [0e4851502f846b13b29b7f88f1250c980d57e944] break) and am currently using this version and no problems so far. 2007/8/14, Francois Romieu <[EMAIL PROTECTED]>: > Karl Meyer <[EMAIL PROTECTED]> : > [...] > > dmesg, interrupts and .config are attached. I will have a look at git > > bisect. > > Can you reproduce the problem when nvidia binary-only stuff is not loaded > after boot ? > > -- > Ueimor > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.23-rc "NETDEV WATCHDOG: eth0: transmit timed out"
Sorry, I was wrong, still testing 2007/8/14, Francois Romieu <[EMAIL PROTECTED]>: > Karl Meyer <[EMAIL PROTECTED]> : > [...] > > dmesg, interrupts and .config are attached. I will have a look at git > > bisect. > > Can you reproduce the problem when nvidia binary-only stuff is not loaded > after boot ? > > -- > Ueimor > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.23-rc "NETDEV WATCHDOG: eth0: transmit timed out"
Hi, I successfully ran git bisect: 0127215c17414322b350c3c6fbd1a7d8dd13856f is first bad commit commit 0127215c17414322b350c3c6fbd1a7d8dd13856f Author: Francois Romieu <[EMAIL PROTECTED]> Date: Tue Feb 20 22:58:51 2007 +0100 r8169: small 8101 comment Extracted from version 1.001.00 of Realtek's r8101. Signed-off-by: Francois Romieu <[EMAIL PROTECTED]> Cc: Edward Hsu <[EMAIL PROTECTED]> :04 04 07dc911509e8d1b4ff2dfb013401108d4be85095 d41a52a215fb1b38ba652dda90faf6ed951bccd1 M drivers I did proof it by doing "git revert 0127215c17414322b350c3c6fbd1a7d8dd13856f" on my git clone, now I am happily running 2.6.23-rc3-ge60a without the NETDEV WATCHDOG message. 2007/8/14, Francois Romieu <[EMAIL PROTECTED]>: > Karl Meyer <[EMAIL PROTECTED]> : > [...] > > dmesg, interrupts and .config are attached. I will have a look at git > > bisect. > > Can you reproduce the problem when nvidia binary-only stuff is not loaded > after boot ? > > -- > Ueimor > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.23-rc "NETDEV WATCHDOG: eth0: transmit timed out"
Karl Meyer <[EMAIL PROTECTED]> : [...] > dmesg, interrupts and .config are attached. I will have a look at git bisect. Can you reproduce the problem when nvidia binary-only stuff is not loaded after boot ? -- Ueimor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.23-rc NETDEV WATCHDOG: eth0: transmit timed out
Karl Meyer [EMAIL PROTECTED] : [...] dmesg, interrupts and .config are attached. I will have a look at git bisect. Can you reproduce the problem when nvidia binary-only stuff is not loaded after boot ? -- Ueimor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.23-rc NETDEV WATCHDOG: eth0: transmit timed out
Hi, I successfully ran git bisect: 0127215c17414322b350c3c6fbd1a7d8dd13856f is first bad commit commit 0127215c17414322b350c3c6fbd1a7d8dd13856f Author: Francois Romieu [EMAIL PROTECTED] Date: Tue Feb 20 22:58:51 2007 +0100 r8169: small 8101 comment Extracted from version 1.001.00 of Realtek's r8101. Signed-off-by: Francois Romieu [EMAIL PROTECTED] Cc: Edward Hsu [EMAIL PROTECTED] :04 04 07dc911509e8d1b4ff2dfb013401108d4be85095 d41a52a215fb1b38ba652dda90faf6ed951bccd1 M drivers I did proof it by doing git revert 0127215c17414322b350c3c6fbd1a7d8dd13856f on my git clone, now I am happily running 2.6.23-rc3-ge60a without the NETDEV WATCHDOG message. 2007/8/14, Francois Romieu [EMAIL PROTECTED]: Karl Meyer [EMAIL PROTECTED] : [...] dmesg, interrupts and .config are attached. I will have a look at git bisect. Can you reproduce the problem when nvidia binary-only stuff is not loaded after boot ? -- Ueimor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.23-rc NETDEV WATCHDOG: eth0: transmit timed out
Sorry, I was wrong, still testing 2007/8/14, Francois Romieu [EMAIL PROTECTED]: Karl Meyer [EMAIL PROTECTED] : [...] dmesg, interrupts and .config are attached. I will have a look at git bisect. Can you reproduce the problem when nvidia binary-only stuff is not loaded after boot ? -- Ueimor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.23-rc NETDEV WATCHDOG: eth0: transmit timed out
I did some additional testing, the results are: [0e4851502f846b13b29b7f88f1250c980d57e944] r8169: merge with version 8.001.00 of Realtek's r8168 driver does not work, I after some traffic the transmit timeout occurs. [6dccd16b7c2703e8bbf8bca62b5cf248332afbe2] r8169: merge with version 6.001.00 of Realtek's r8169 driver Seems to be the last version to work. I did some stress testing (much more than the level that was enough to make [0e4851502f846b13b29b7f88f1250c980d57e944] break) and am currently using this version and no problems so far. 2007/8/14, Francois Romieu [EMAIL PROTECTED]: Karl Meyer [EMAIL PROTECTED] : [...] dmesg, interrupts and .config are attached. I will have a look at git bisect. Can you reproduce the problem when nvidia binary-only stuff is not loaded after boot ? -- Ueimor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.23-rc NETDEV WATCHDOG: eth0: transmit timed out
Karl Meyer [EMAIL PROTECTED] :
I did some additional testing, the results are:
[0e4851502f846b13b29b7f88f1250c980d57e944] r8169: merge with version
8.001.00 of Realtek's r8168 driver
does not work, I after some traffic the transmit timeout occurs.
[6dccd16b7c2703e8bbf8bca62b5cf248332afbe2] r8169: merge with version
6.001.00 of Realtek's r8169 driver
Seems to be the last version to work. I did some stress testing (much
more than the level that was enough to make
[0e4851502f846b13b29b7f88f1250c980d57e944] break) and am currently
using this version and no problems so far.
Thanks for the quick feedback.
Can you try the patch below on top of 2.6.23-rc3 ?
If it does not work I'll dissect 0e4851502f846b13b29b7f88f1250c980d57e944
tomorrow.
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index b85ab4a..cdb8a08 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -2749,6 +2749,7 @@ static irqreturn_t rtl8169_interrupt(int irq, void
*dev_instance)
if (!(status tp-intr_event))
break;
+#if 0
/* Work around for rx fifo overflow */
if (unlikely(status RxFIFOOver)
(tp-mac_version == RTL_GIGA_MAC_VER_11)) {
@@ -2756,6 +2757,7 @@ static irqreturn_t rtl8169_interrupt(int irq, void
*dev_instance)
rtl8169_tx_timeout(dev);
break;
}
+#endif
if (unlikely(status SYSErr)) {
rtl8169_pcierr_interrupt(dev);
--
Ueimor
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.23-rc "NETDEV WATCHDOG: eth0: transmit timed out"
(netdev Cced) Karl Meyer <[EMAIL PROTECTED]> : [...] > I am having trouble with the 2.6.23 kernel. With all versions since > 2.6.23-rc1 I have trouble with my network connection. When using the > network over a certain level (just browsing the web seems not to be > enough) e.g. when installing packages over the nvsv4 share, all > network stuff freezes for some time and syslog tells me: > Aug 13 13:16:09 frege NETDEV WATCHDOG: eth0: transmit timed out > Aug 13 13:16:39 frege NETDEV WATCHDOG: eth0: transmit timed out > Aug 13 13:17:09 frege NETDEV WATCHDOG: eth0: transmit timed out > Aug 13 13:17:57 frege NETDEV WATCHDOG: eth0: transmit timed out Can you: - send a complete dmesg + /proc/interrupts + .config - use git bisect to find a suspect changeset I do not expect any change of behavior between 2.6.22 and 25805dcf9d83098cf5492117ad2669cd14cc9b24 if it can help you narrow things down (assuming it is a r8169 regression). -- Ueimor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PROBLEM: 2.6.23-rc "NETDEV WATCHDOG: eth0: transmit timed out"
Hi, I am having trouble with the 2.6.23 kernel. With all versions since 2.6.23-rc1 I have trouble with my network connection. When using the network over a certain level (just browsing the web seems not to be enough) e.g. when installing packages over the nvsv4 share, all network stuff freezes for some time and syslog tells me: Aug 13 13:16:09 frege NETDEV WATCHDOG: eth0: transmit timed out Aug 13 13:16:39 frege NETDEV WATCHDOG: eth0: transmit timed out Aug 13 13:17:09 frege NETDEV WATCHDOG: eth0: transmit timed out Aug 13 13:17:57 frege NETDEV WATCHDOG: eth0: transmit timed out Some info about my system: /usr/src/linux-2.6.23-rc3 $ sh scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux frege linux-2.6.23-rc3 #1 SMP PREEMPT Sat Aug 11 16:24:26 CEST 2007 i686 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux Gnu C 4.2.0 Gnu make 3.81 binutils 2.17 util-linux 2.12r mount 2.12r module-init-tools 3.2.2 e2fsprogs 1.39 Linux C Library2.5 Dynamic linker (ldd) 2.5 Procps 3.2.7 Net-tools 1.60 Kbd1.12 Sh-utils 6.9 udev 114 Modules Loaded nvidia lspci -vvv 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03) Subsystem: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [88] Subsystem: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express PCI Express Root Port Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Address: Data: Capabilities: [a0] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s <64ns, L1 <1us Device: Errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed 2.5Gb/s, Width x16, ASPM L0s, Port 2 Link: Latency L0s <256ns, L1 <4us Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch- Link: Speed 2.5Gb/s, Width x16 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug- Surpise- Slot: Number 0, PowerLimit 0.00 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- Slot: AttnInd Off, PwrInd On, Power- Root: Correctable- Non-Fatal- Fatal- PME- 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [40] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s unlimited, L1 unlimited Device: Errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 1 Link: Latency L0s <256ns, L1 <4us Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch- Link: Speed 2.5Gb/s, Width x1 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug+ Surpise+ Slot: Number 0, PowerLimit 0.00 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- Slot: AttnInd Unknown, PwrInd Unknown, Power- Root: Correctable- Non-Fatal- Fatal- PME- Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Address: Data: Capabilities: [90] Subsystem: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 Capabilities: [a0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0
PROBLEM: 2.6.23-rc NETDEV WATCHDOG: eth0: transmit timed out
Hi, I am having trouble with the 2.6.23 kernel. With all versions since 2.6.23-rc1 I have trouble with my network connection. When using the network over a certain level (just browsing the web seems not to be enough) e.g. when installing packages over the nvsv4 share, all network stuff freezes for some time and syslog tells me: Aug 13 13:16:09 frege NETDEV WATCHDOG: eth0: transmit timed out Aug 13 13:16:39 frege NETDEV WATCHDOG: eth0: transmit timed out Aug 13 13:17:09 frege NETDEV WATCHDOG: eth0: transmit timed out Aug 13 13:17:57 frege NETDEV WATCHDOG: eth0: transmit timed out Some info about my system: /usr/src/linux-2.6.23-rc3 $ sh scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux frege linux-2.6.23-rc3 #1 SMP PREEMPT Sat Aug 11 16:24:26 CEST 2007 i686 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux Gnu C 4.2.0 Gnu make 3.81 binutils 2.17 util-linux 2.12r mount 2.12r module-init-tools 3.2.2 e2fsprogs 1.39 Linux C Library2.5 Dynamic linker (ldd) 2.5 Procps 3.2.7 Net-tools 1.60 Kbd1.12 Sh-utils 6.9 udev 114 Modules Loaded nvidia lspci -vvv 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03) Subsystem: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- Latency: 0 Capabilities: [e0] Vendor Specific Information 00:01.0 PCI bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express PCI Express Root Port (rev 03) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0, Cache Line Size: 32 bytes Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: a000-afff Memory behind bridge: f850-fe5f Prefetchable memory behind bridge: cff0-efef Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity- SERR+ NoISA- VGA+ MAbort- Reset- FastB2B- Capabilities: [88] Subsystem: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express PCI Express Root Port Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Address: Data: Capabilities: [a0] Express Root Port (Slot+) IRQ 0 Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag- Device: Latency L0s 64ns, L1 1us Device: Errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- Device: MaxPayload 128 bytes, MaxReadReq 128 bytes Link: Supported Speed 2.5Gb/s, Width x16, ASPM L0s, Port 2 Link: Latency L0s 256ns, L1 4us Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch- Link: Speed 2.5Gb/s, Width x16 Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug- Surpise- Slot: Number 0, PowerLimit 0.00 Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- Slot: AttnInd Off, PwrInd On, Power- Root: Correctable- Non-Fatal- Fatal- PME- 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 16 Region 0: Memory at febfc000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: Data: Capabilities: [70] Express Unknown type IRQ 0 Device: Supported
Re: PROBLEM: 2.6.23-rc NETDEV WATCHDOG: eth0: transmit timed out
(netdev Cced) Karl Meyer [EMAIL PROTECTED] : [...] I am having trouble with the 2.6.23 kernel. With all versions since 2.6.23-rc1 I have trouble with my network connection. When using the network over a certain level (just browsing the web seems not to be enough) e.g. when installing packages over the nvsv4 share, all network stuff freezes for some time and syslog tells me: Aug 13 13:16:09 frege NETDEV WATCHDOG: eth0: transmit timed out Aug 13 13:16:39 frege NETDEV WATCHDOG: eth0: transmit timed out Aug 13 13:17:09 frege NETDEV WATCHDOG: eth0: transmit timed out Aug 13 13:17:57 frege NETDEV WATCHDOG: eth0: transmit timed out Can you: - send a complete dmesg + /proc/interrupts + .config - use git bisect to find a suspect changeset I do not expect any change of behavior between 2.6.22 and 25805dcf9d83098cf5492117ad2669cd14cc9b24 if it can help you narrow things down (assuming it is a r8169 regression). -- Ueimor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NETDEV WATCHDOG: eth0: transmit timed out on LNE100TX 4.0, kernel2.4.2-ac11 and earlier.
On Tuesday 20 March 2001 14:58, Jeff Garzik wrote: > > With all the above kernel revisions/drivers, my network card > > hangs at random (sometimes within minutes, other times it takes > > days). To restart it I need to do an ifdown/ifup cycle and it > > will work fine until the next hang. I upgraded to 2.4.2-ac11 > > because of the documented tulip fixes, but after a few days got > > this again. The error log shows: > > In Alan Cox terms, that's a long time ago :) > > Can you please try 2.4.2-ac20? It includes fixes specifically for > this problem. I started having the same problem with my LNE100TX and switched it out with another LNE100TX and had the same problem. Figured it was my BP6 SMP motherboard and ordered a new computer. Doh. :-) Using 2.4.2-ac20. Current LNE100TX having problems (other is different Rev): Lite-On Communications Inc LNE100TX (rev 20) The first card would get "unexpected IRQ trap at vector d0" before dying whereas the second one didn't give that indication. It would just freeze and the traditional "NETDEV WATCHDOG: eth0: transmit timed out" message. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: NETDEV WATCHDOG: eth0: transmit timed out on LNE100TX 4.0, kernel2.4.2-ac11 and earlier.
I'd looked for changes in tulip between 2.4.2-ac11 and 2.4.2-ac20 and hadn't seen any - that's why I hadn't updated. I gather that the change in question is at a higher level? Anyway, I've upgraded to 2.4.2-ac20 and now I still get the error messages: Mar 20 14:35:52 ulthar kernel: NETDEV WATCHDOG: eth0: transmit timed out Mar 20 14:35:52 ulthar kernel: eth0: Transmit timed out, status fc664010, CSR12 , resetting... but instead of hanging completely the connection just gets extremely slow and "bursty" as shown by the following fragment of ping output: 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=8 ttl=255 time=130 usec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=9 ttl=255 time=358 usec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=10 ttl=255 time=6.000 sec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=4 ttl=255 time=12.001 sec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=12 ttl=255 time=1.000 sec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=13 ttl=255 time=368 usec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=14 ttl=255 time=361 usec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=15 ttl=255 time=395 usec So the behavior is quite a bit better (at least I can telnet in to ifdown/ifup) but still not OK. Once again, ifdown/ifup makes things work OK. Thanks! -- Manuel A. McLure - Unify Corp. Technical Support <[EMAIL PROTECTED]> Space Ghost: "Hey, what happened to the-?" Moltar: "It's out." SG: "What about-?" M: "It's fixed." SG: "Eh, good. Good." "Jeff Garzik" wrote: > "Manuel A. McLure" wrote: > > > > System: > > AMD Athlon Thunderbird 900MHz > > MSI K7T Pro (VIA KT133 chipset) > > Network card: Linksys LNE100TX Rev. 4.0 (tulip) > > Kernel: 2.2.18 (with 0.92 Scyld drivers), 2.4.0, 2.4.1, > 2.4.2, 2.4.2-ac11 > > > > With all the above kernel revisions/drivers, my network > card hangs at random > > (sometimes within minutes, other times it takes days). To > restart it I need > > to do an ifdown/ifup cycle and it will work fine until the > next hang. I > > upgraded to 2.4.2-ac11 because of the documented tulip > fixes, but after a > > few days got this again. The error log shows: > > In Alan Cox terms, that's a long time ago :) > > Can you please try 2.4.2-ac20? It includes fixes > specifically for this > problem. I'd looked for changes in tulip between 2.4.2-ac11 and 2.4.2-ac20 and hadn't seen any - that's why I hadn't updated. I gather that the change in question is at a higher level? Anyway, I've upgraded to 2.4.2-ac20 and now I still get the error messages: Mar 20 14:35:52 ulthar kernel: NETDEV WATCHDOG: eth0: transmit timed out Mar 20 14:35:52 ulthar kernel: eth0: Transmit timed out, status fc664010, CSR12 , resetting... but instead of hanging completely the connection just gets extremely slow and "bursty" as shown by the following fragment of ping output: 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=8 ttl=255 time=130 usec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=9 ttl=255 time=358 usec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=10 ttl=255 time=6.000 sec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=4 ttl=255 time=12.001 sec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=12 ttl=255 time=1.000 sec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=13 ttl=255 time=368 usec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=14 ttl=255 time=361 usec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=15 ttl=255 time=395 usec So the behavior is quite a bit better (at least I can telnet in to ifdown/ifup) but still not OK. Once again, ifdown/ifup makes things work fine until the problem starts again. Thanks! -- Manuel A. McLure - Unify Corp. Technical Support <[EMAIL PROTECTED]> Space Ghost: "Hey, what happened to the-?" Moltar: "It's out." SG: "What about-?" M: "It's fixed." SG: "Eh, good. Good." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NETDEV WATCHDOG: eth0: transmit timed out on LNE100TX 4.0, kernel2.4.2-ac11 and earlier.
"Manuel A. McLure" wrote: > > System: > AMD Athlon Thunderbird 900MHz > MSI K7T Pro (VIA KT133 chipset) > Network card: Linksys LNE100TX Rev. 4.0 (tulip) > Kernel: 2.2.18 (with 0.92 Scyld drivers), 2.4.0, 2.4.1, 2.4.2, 2.4.2-ac11 > > With all the above kernel revisions/drivers, my network card hangs at random > (sometimes within minutes, other times it takes days). To restart it I need > to do an ifdown/ifup cycle and it will work fine until the next hang. I > upgraded to 2.4.2-ac11 because of the documented tulip fixes, but after a > few days got this again. The error log shows: In Alan Cox terms, that's a long time ago :) Can you please try 2.4.2-ac20? It includes fixes specifically for this problem. -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full mooon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
NETDEV WATCHDOG: eth0: transmit timed out on LNE100TX 4.0, kernel 2.4.2-ac11 and earlier.
System: AMD Athlon Thunderbird 900MHz MSI K7T Pro (VIA KT133 chipset) Network card: Linksys LNE100TX Rev. 4.0 (tulip) Kernel: 2.2.18 (with 0.92 Scyld drivers), 2.4.0, 2.4.1, 2.4.2, 2.4.2-ac11 With all the above kernel revisions/drivers, my network card hangs at random (sometimes within minutes, other times it takes days). To restart it I need to do an ifdown/ifup cycle and it will work fine until the next hang. I upgraded to 2.4.2-ac11 because of the documented tulip fixes, but after a few days got this again. The error log shows: Mar 16 18:37:00 ulthar kernel: NETDEV WATCHDOG: eth0: transmit timed out Mar 16 18:37:00 ulthar kernel: eth0: Transmit timed out, status fc664010, CSR12 , resetting... ad infinitum until I do ifdown/ifup. The status & CSR12 values are always the same. My card is detected as follows by the kernel: Mar 12 21:38:49 ulthar kernel: Linux Tulip driver version 0.9.14c (March 3, 2001 ) Mar 12 21:38:49 ulthar kernel: PCI: Found IRQ 11 for device 00:0a.0 Mar 12 21:38:49 ulthar kernel: IRQ routing conflict in pirq table for device 00: 07.2 Mar 12 21:38:49 ulthar kernel: IRQ routing conflict in pirq table for device 00: 07.3 Mar 12 21:38:49 ulthar kernel: PCI: The same IRQ used for device 00:0e.0 Mar 12 21:38:49 ulthar kernel: eth0: ADMtek Comet rev 17 at 0xdc00, 00:20:78:0D: D2:E1, IRQ 11. Any ideas on why this might be happening? -- Manuel A. McLure - Unify Corp. Technical Support <[EMAIL PROTECTED]> Space Ghost: "Hey, what happened to the-?" Moltar: "It's out." SG: "What about-?" M: "It's fixed." SG: "Eh, good. Good." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
NETDEV WATCHDOG: eth0: transmit timed out on LNE100TX 4.0, kernel 2.4.2-ac11 and earlier.
System: AMD Athlon Thunderbird 900MHz MSI K7T Pro (VIA KT133 chipset) Network card: Linksys LNE100TX Rev. 4.0 (tulip) Kernel: 2.2.18 (with 0.92 Scyld drivers), 2.4.0, 2.4.1, 2.4.2, 2.4.2-ac11 With all the above kernel revisions/drivers, my network card hangs at random (sometimes within minutes, other times it takes days). To restart it I need to do an ifdown/ifup cycle and it will work fine until the next hang. I upgraded to 2.4.2-ac11 because of the documented tulip fixes, but after a few days got this again. The error log shows: Mar 16 18:37:00 ulthar kernel: NETDEV WATCHDOG: eth0: transmit timed out Mar 16 18:37:00 ulthar kernel: eth0: Transmit timed out, status fc664010, CSR12 , resetting... ad infinitum until I do ifdown/ifup. The status CSR12 values are always the same. My card is detected as follows by the kernel: Mar 12 21:38:49 ulthar kernel: Linux Tulip driver version 0.9.14c (March 3, 2001 ) Mar 12 21:38:49 ulthar kernel: PCI: Found IRQ 11 for device 00:0a.0 Mar 12 21:38:49 ulthar kernel: IRQ routing conflict in pirq table for device 00: 07.2 Mar 12 21:38:49 ulthar kernel: IRQ routing conflict in pirq table for device 00: 07.3 Mar 12 21:38:49 ulthar kernel: PCI: The same IRQ used for device 00:0e.0 Mar 12 21:38:49 ulthar kernel: eth0: ADMtek Comet rev 17 at 0xdc00, 00:20:78:0D: D2:E1, IRQ 11. Any ideas on why this might be happening? -- Manuel A. McLure - Unify Corp. Technical Support [EMAIL PROTECTED] Space Ghost: "Hey, what happened to the-?" Moltar: "It's out." SG: "What about-?" M: "It's fixed." SG: "Eh, good. Good." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NETDEV WATCHDOG: eth0: transmit timed out on LNE100TX 4.0, kernel2.4.2-ac11 and earlier.
"Manuel A. McLure" wrote: System: AMD Athlon Thunderbird 900MHz MSI K7T Pro (VIA KT133 chipset) Network card: Linksys LNE100TX Rev. 4.0 (tulip) Kernel: 2.2.18 (with 0.92 Scyld drivers), 2.4.0, 2.4.1, 2.4.2, 2.4.2-ac11 With all the above kernel revisions/drivers, my network card hangs at random (sometimes within minutes, other times it takes days). To restart it I need to do an ifdown/ifup cycle and it will work fine until the next hang. I upgraded to 2.4.2-ac11 because of the documented tulip fixes, but after a few days got this again. The error log shows: In Alan Cox terms, that's a long time ago :) Can you please try 2.4.2-ac20? It includes fixes specifically for this problem. -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full mooon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: NETDEV WATCHDOG: eth0: transmit timed out on LNE100TX 4.0, kernel2.4.2-ac11 and earlier.
I'd looked for changes in tulip between 2.4.2-ac11 and 2.4.2-ac20 and hadn't seen any - that's why I hadn't updated. I gather that the change in question is at a higher level? Anyway, I've upgraded to 2.4.2-ac20 and now I still get the error messages: Mar 20 14:35:52 ulthar kernel: NETDEV WATCHDOG: eth0: transmit timed out Mar 20 14:35:52 ulthar kernel: eth0: Transmit timed out, status fc664010, CSR12 , resetting... but instead of hanging completely the connection just gets extremely slow and "bursty" as shown by the following fragment of ping output: 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=8 ttl=255 time=130 usec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=9 ttl=255 time=358 usec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=10 ttl=255 time=6.000 sec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=4 ttl=255 time=12.001 sec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=12 ttl=255 time=1.000 sec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=13 ttl=255 time=368 usec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=14 ttl=255 time=361 usec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=15 ttl=255 time=395 usec So the behavior is quite a bit better (at least I can telnet in to ifdown/ifup) but still not OK. Once again, ifdown/ifup makes things work OK. Thanks! -- Manuel A. McLure - Unify Corp. Technical Support [EMAIL PROTECTED] Space Ghost: "Hey, what happened to the-?" Moltar: "It's out." SG: "What about-?" M: "It's fixed." SG: "Eh, good. Good." "Jeff Garzik" wrote: "Manuel A. McLure" wrote: System: AMD Athlon Thunderbird 900MHz MSI K7T Pro (VIA KT133 chipset) Network card: Linksys LNE100TX Rev. 4.0 (tulip) Kernel: 2.2.18 (with 0.92 Scyld drivers), 2.4.0, 2.4.1, 2.4.2, 2.4.2-ac11 With all the above kernel revisions/drivers, my network card hangs at random (sometimes within minutes, other times it takes days). To restart it I need to do an ifdown/ifup cycle and it will work fine until the next hang. I upgraded to 2.4.2-ac11 because of the documented tulip fixes, but after a few days got this again. The error log shows: In Alan Cox terms, that's a long time ago :) Can you please try 2.4.2-ac20? It includes fixes specifically for this problem. I'd looked for changes in tulip between 2.4.2-ac11 and 2.4.2-ac20 and hadn't seen any - that's why I hadn't updated. I gather that the change in question is at a higher level? Anyway, I've upgraded to 2.4.2-ac20 and now I still get the error messages: Mar 20 14:35:52 ulthar kernel: NETDEV WATCHDOG: eth0: transmit timed out Mar 20 14:35:52 ulthar kernel: eth0: Transmit timed out, status fc664010, CSR12 , resetting... but instead of hanging completely the connection just gets extremely slow and "bursty" as shown by the following fragment of ping output: 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=8 ttl=255 time=130 usec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=9 ttl=255 time=358 usec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=10 ttl=255 time=6.000 sec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=4 ttl=255 time=12.001 sec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=12 ttl=255 time=1.000 sec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=13 ttl=255 time=368 usec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=14 ttl=255 time=361 usec 64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=15 ttl=255 time=395 usec So the behavior is quite a bit better (at least I can telnet in to ifdown/ifup) but still not OK. Once again, ifdown/ifup makes things work fine until the problem starts again. Thanks! -- Manuel A. McLure - Unify Corp. Technical Support [EMAIL PROTECTED] Space Ghost: "Hey, what happened to the-?" Moltar: "It's out." SG: "What about-?" M: "It's fixed." SG: "Eh, good. Good." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NETDEV WATCHDOG: eth0: transmit timed out on LNE100TX 4.0, kernel2.4.2-ac11 and earlier.
On Tuesday 20 March 2001 14:58, Jeff Garzik wrote: With all the above kernel revisions/drivers, my network card hangs at random (sometimes within minutes, other times it takes days). To restart it I need to do an ifdown/ifup cycle and it will work fine until the next hang. I upgraded to 2.4.2-ac11 because of the documented tulip fixes, but after a few days got this again. The error log shows: In Alan Cox terms, that's a long time ago :) Can you please try 2.4.2-ac20? It includes fixes specifically for this problem. I started having the same problem with my LNE100TX and switched it out with another LNE100TX and had the same problem. Figured it was my BP6 SMP motherboard and ordered a new computer. Doh. :-) Using 2.4.2-ac20. Current LNE100TX having problems (other is different Rev): Lite-On Communications Inc LNE100TX (rev 20) The first card would get "unexpected IRQ trap at vector d0" before dying whereas the second one didn't give that indication. It would just freeze and the traditional "NETDEV WATCHDOG: eth0: transmit timed out" message. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NETDEV WATCHDOG: eth0: transmit timed out
Caleb Epstein wrote: > > I am seeing the following error after my machine has been up > for a while. My eth0 is connected to a switched, local > subnet. There is not a lot of traffic on the interface, maybe > a few 100 Mbytes or so. Taking the interface down and then up > again fixes the problem (until it happens again :) > > Here is the relevant section from my kernel log > > Mar 1 10:48:44 tela kernel: NETDEV WATCHDOG: eth0: transmit timed out My guess would be that the driver has decided there's no link beat on the 10baseT interface and has flopped over to using 10base2. A fix for this exists in 2.4.2-ac5+, in the zerocopy patch and in http://www.uow.edu.au/~andrewm/linux/3c59x.c-2.4.2-pre4.gz but not in 2.4.2. You'll need to use options 3c59x options=0 in /etc/modules.conf to pin the driver down to using a particular physical interface - disable autoselection. So could you please upgrade the driver? If problems remain, please send me a report, as described in the final section of Documentation/networking/vortex.txt. Thanks. - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
NETDEV WATCHDOG: eth0: transmit timed out
I am seeing the following error after my machine has been up for a while. My eth0 is connected to a switched, local subnet. There is not a lot of traffic on the interface, maybe a few 100 Mbytes or so. Taking the interface down and then up again fixes the problem (until it happens again :) Here is the relevant section from my kernel log Mar 1 10:48:44 tela kernel: NETDEV WATCHDOG: eth0: transmit timed out Mar 1 10:48:44 tela kernel: eth0: transmit timed out, tx_status 00 status e000. Mar 1 10:48:44 tela kernel: diagnostics: net 0ec0 media 4810 dma 0021. Mar 1 10:48:44 tela kernel: Flags; bus-master 1, full 1; dirty 87959(7) current 87975(7). Mar 1 10:48:44 tela kernel: Transmit list 01252270 vs. c1252270. Mar 1 10:48:44 tela kernel: 0: @c1252200 length 80f7 status 00f7 Mar 1 10:48:44 tela kernel: 1: @c1252210 length 810c status 010c Mar 1 10:48:44 tela kernel: 2: @c1252220 length 80f7 status 00f7 Mar 1 10:48:44 tela kernel: 3: @c1252230 length 810c status 010c Mar 1 10:48:44 tela kernel: 4: @c1252240 length 80f7 status 00f7 Mar 1 10:48:44 tela kernel: 5: @c1252250 length 802a status 802a Mar 1 10:48:44 tela kernel: 6: @c1252260 length 802a status 802a Mar 1 10:48:44 tela kernel: 7: @c1252270 length 810c status 010c Mar 1 10:48:44 tela kernel: 8: @c1252280 length 80f7 status 00f7 Mar 1 10:48:44 tela kernel: 9: @c1252290 length 810c status 010c Mar 1 10:48:44 tela kernel: 10: @c12522a0 length 80f7 status 00f7 Mar 1 10:48:44 tela kernel: 11: @c12522b0 length 810c status 010c Mar 1 10:48:44 tela kernel: 12: @c12522c0 length 80f7 status 00f7 Mar 1 10:48:44 tela kernel: 13: @c12522d0 length 810c status 010c Mar 1 10:48:44 tela kernel: 14: @c12522e0 length 80f7 status 00f7 Mar 1 10:48:44 tela kernel: 15: @c12522f0 length 810c status 010c Mar 1 10:48:44 tela kernel: eth0: Resetting the Tx ring pointer. Then a similar dump repeats until the interface is recycled. It appears that the interface was not functioning for some hours before the message was generated, and it was my attempt to ping a host on the local subnet that caused the NETDEV WATCHDOG error to be generated (e.g. the card locked up, but the kernel didn't notice until I tried to send something on the wire). The card is: eth0: 3Com PCI 3c900 Boomerang 10Mbps Combo at 0x1400, 00:60:08:bd:ab:0e, IRQ 9 I am running kernel 2.4.2, and have seen this error in 2.4.1 as well; not sure about 2.4.0. I do not ever recall encountering this error with the 2.2.x kernels, though my network topology has changed, but not my hardware. I know of at least one other person who gets this same error with a eth0: 3Com PCI 3c905B Cyclone 100baseTx card. The system is a P2-300, 128 Mb RAM, running various versions of Linux very happily for 3 years. FWIW, IRQ 9 is shared with the bttv module, though the network lockup doesn't seem to be related to my use of that module. I was using xawtv last night while the interface was stil active and functioning. The lockup happened this morning. Sorry for the long-winded post. Is this a known bug? Anything I can do to help track it down and squash it if so? -- cae at bklyn dot org | Caleb Epstein | bklyn . org | Brooklyn Dust Bunny Mfg. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NETDEV WATCHDOG: eth0: transmit timed out
Caleb Epstein wrote: I am seeing the following error after my machine has been up for a while. My eth0 is connected to a switched, local subnet. There is not a lot of traffic on the interface, maybe a few 100 Mbytes or so. Taking the interface down and then up again fixes the problem (until it happens again :) Here is the relevant section from my kernel log Mar 1 10:48:44 tela kernel: NETDEV WATCHDOG: eth0: transmit timed out My guess would be that the driver has decided there's no link beat on the 10baseT interface and has flopped over to using 10base2. A fix for this exists in 2.4.2-ac5+, in the zerocopy patch and in http://www.uow.edu.au/~andrewm/linux/3c59x.c-2.4.2-pre4.gz but not in 2.4.2. You'll need to use options 3c59x options=0 in /etc/modules.conf to pin the driver down to using a particular physical interface - disable autoselection. So could you please upgrade the driver? If problems remain, please send me a report, as described in the final section of Documentation/networking/vortex.txt. Thanks. - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NETDEV WATCHDOG: eth0: transmit timed out
I am getting complete lockups of the NIC, up/down the interface doesn't restore it. rmmod/insmod of ne2k-pci and 8390 doesn't restore it. A reboot does. The m/c with this card in isn't normally highly loaded on the network, but under heavy load it will lockup completely (fairly reliably I suspect). I have also had this problem with 2.4.0-test11, I had traced it to ei_tx_intr() in so much as it was calling the "ei_local->stat.collisions += 16;" line. This is 8390.c:635 in 2.4.0. The log below shows the time I had reloaded the modules trying to bring it back to life. Jan 13 01:46:24 thehostname kernel: NETDEV WATCHDOG: eth0: transmit timed out Jan 13 01:46:24 thehostname kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=951. Jan 13 01:46:26 thehostname kernel: NETDEV WATCHDOG: eth0: transmit timed out Jan 13 01:46:26 thehostname kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=100. Jan 13 01:47:14 thehostname kernel: NETDEV WATCHDOG: eth0: transmit timed out Jan 13 01:47:14 thehostname kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=106. Jan 13 01:47:15 thehostname kernel: NETDEV WATCHDOG: eth0: transmit timed out Jan 13 01:47:15 thehostname kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=26. Jan 13 01:47:17 thehostname kernel: NETDEV WATCHDOG: eth0: transmit timed out Jan 13 01:47:17 thehostname kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=105. Jan 13 01:47:24 thehostname kernel: RPC: sendmsg returned error 101 Jan 13 01:47:24 thehostname kernel: nfs: RPC call returned error 101 Jan 13 01:47:24 thehostname kernel: nfs_statfs: statfs error = 101 Jan 13 01:47:37 thehostname kernel: ne2k-pci.c:v1.02 10/19/2000 D. Becker/P. Gortmaker Jan 13 01:47:37 thehostname kernel: http://www.scyld.com/network/ne2k-pci.html Jan 13 01:47:37 thehostname kernel: eth0: RealTek RTL-8029 found at 0xe800, IRQ 19, 48:54:E8:21:15:56. Jan 13 01:47:47 thehostname kernel: NETDEV WATCHDOG: eth0: transmit timed out Jan 13 01:47:47 thehostname kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=111. Jan 13 01:47:58 thehostname kernel: NETDEV WATCHDOG: eth0: transmit timed out Jan 13 01:47:58 thehostname kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=1031. Jan 13 01:48:00 thehostname kernel: NETDEV WATCHDOG: eth0: transmit timed out Jan 13 01:48:00 thehostname kernel: eth0: Tx timed out, lost interrupt? TSR=0x1, ISR=0x3, t=107. Jan 13 01:48:04 thehostname kernel: NETDEV WATCHDOG: eth0: transmit timed out Jan 13 01:48:04 thehostname kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=106. Jan 13 01:48:08 thehostname kernel: NETDEV WATCHDOG: eth0: transmit timed out Jan 13 01:48:08 thehostname kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=306. Jan 13 01:48:10 thehostname kernel: NETDEV WATCHDOG: eth0: transmit timed out Jan 13 01:48:10 thehostname kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=105. Jan 13 01:48:24 thehostname kernel: NETDEV WATCHDOG: eth0: transmit timed out Jan 13 01:48:24 thehostname kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x2, t=72. $ uname -r 2.4.0 lsmod bits: ne2k-pci4448 1 (autoclean) 83906544 0 (autoclean) [ne2k-pci] /proc/pci: Bus 0, device 11, function 0: Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS) (rev 0). IRQ 19. I/O at 0xe800 [0xe81f]. -- Darryl Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: NETDEV WATCHDOG: eth0: transmit timed out
I am getting complete lockups of the NIC, up/down the interface doesn't restore it. rmmod/insmod of ne2k-pci and 8390 doesn't restore it. A reboot does. The m/c with this card in isn't normally highly loaded on the network, but under heavy load it will lockup completely (fairly reliably I suspect). I have also had this problem with 2.4.0-test11, I had traced it to ei_tx_intr() in so much as it was calling the "ei_local-stat.collisions += 16;" line. This is 8390.c:635 in 2.4.0. The log below shows the time I had reloaded the modules trying to bring it back to life. Jan 13 01:46:24 thehostname kernel: NETDEV WATCHDOG: eth0: transmit timed out Jan 13 01:46:24 thehostname kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=951. Jan 13 01:46:26 thehostname kernel: NETDEV WATCHDOG: eth0: transmit timed out Jan 13 01:46:26 thehostname kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=100. Jan 13 01:47:14 thehostname kernel: NETDEV WATCHDOG: eth0: transmit timed out Jan 13 01:47:14 thehostname kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=106. Jan 13 01:47:15 thehostname kernel: NETDEV WATCHDOG: eth0: transmit timed out Jan 13 01:47:15 thehostname kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=26. Jan 13 01:47:17 thehostname kernel: NETDEV WATCHDOG: eth0: transmit timed out Jan 13 01:47:17 thehostname kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=105. Jan 13 01:47:24 thehostname kernel: RPC: sendmsg returned error 101 Jan 13 01:47:24 thehostname kernel: nfs: RPC call returned error 101 Jan 13 01:47:24 thehostname kernel: nfs_statfs: statfs error = 101 Jan 13 01:47:37 thehostname kernel: ne2k-pci.c:v1.02 10/19/2000 D. Becker/P. Gortmaker Jan 13 01:47:37 thehostname kernel: http://www.scyld.com/network/ne2k-pci.html Jan 13 01:47:37 thehostname kernel: eth0: RealTek RTL-8029 found at 0xe800, IRQ 19, 48:54:E8:21:15:56. Jan 13 01:47:47 thehostname kernel: NETDEV WATCHDOG: eth0: transmit timed out Jan 13 01:47:47 thehostname kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=111. Jan 13 01:47:58 thehostname kernel: NETDEV WATCHDOG: eth0: transmit timed out Jan 13 01:47:58 thehostname kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=1031. Jan 13 01:48:00 thehostname kernel: NETDEV WATCHDOG: eth0: transmit timed out Jan 13 01:48:00 thehostname kernel: eth0: Tx timed out, lost interrupt? TSR=0x1, ISR=0x3, t=107. Jan 13 01:48:04 thehostname kernel: NETDEV WATCHDOG: eth0: transmit timed out Jan 13 01:48:04 thehostname kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=106. Jan 13 01:48:08 thehostname kernel: NETDEV WATCHDOG: eth0: transmit timed out Jan 13 01:48:08 thehostname kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=306. Jan 13 01:48:10 thehostname kernel: NETDEV WATCHDOG: eth0: transmit timed out Jan 13 01:48:10 thehostname kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=105. Jan 13 01:48:24 thehostname kernel: NETDEV WATCHDOG: eth0: transmit timed out Jan 13 01:48:24 thehostname kernel: eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x2, t=72. $ uname -r 2.4.0 lsmod bits: ne2k-pci4448 1 (autoclean) 83906544 0 (autoclean) [ne2k-pci] /proc/pci: Bus 0, device 11, function 0: Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS) (rev 0). IRQ 19. I/O at 0xe800 [0xe81f]. -- Darryl Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: NETDEV WATCHDOG: eth0: transmit timed out
On Thu, Dec 28, 2000 at 12:26:06PM +0100, Manfred wrote: > David wrote: > > > > Same old story, bugger still does it. Have to set the link down/up to > > get it running again. > > > > 00:12.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev > > 20) > > > > I missed your earlier mails, could you resend the details? > I'm interested in the output from > > tulip-diag -m -a -f > > before and after a link failure. > > > I'm aware that the tulip drivers doesn't handle cable disconnects and > reconnects with MII pnic cards. I have a patch for that problem, but it > affects _all_ MII tulip cards, and thus it won't be included soon. If > tulip-diag says "10mbps-serial", then you have run into that bug. I have the same transmit timeout problem, but with a D-Link via rhine board. I'm running -test10, and it seems to happen under high (interrupt?) load with both heavy disk and network activity. Interestingly, it appears to happen more often when the other end of the network activity is a 10BaseT link. I'm using a Netgear dual-speed hub. Do you think these might be related? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: NETDEV WATCHDOG: eth0: transmit timed out
Manfred wrote:
> David wrote:
> >
> > Same old story, bugger still does it. Have to set the link down/up to
> > get it running again.
> >
> > 00:12.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev
> > 20)
> >
>
> I missed your earlier mails, could you resend the details?
> I'm interested in the output from
>
> tulip-diag -m -a -f
>
> before and after a link failure.
>
> I'm aware that the tulip drivers doesn't handle cable disconnects and
> reconnects with MII pnic cards. I have a patch for that problem, but it
> affects _all_ MII tulip cards, and thus it won't be included soon. If
> tulip-diag says "10mbps-serial", then you have run into that bug.
>
> --
> Manfred
Here's the before, when the after happens..
# ./tulip-diag -m -a -f
tulip-diag.c:v2.04 9/26/2000 Donald Becker ([EMAIL PROTECTED])
http://www.scyld.com/diag/index.html
Index #1: Found a Lite-On 82c168 PNIC adapter at 0xf800.
Lite-On 82c168 PNIC chip registers at 0xf800:
8000 01ff 00450008 0118f000 0118f200 02660010 814c2202 0001ebef
0118f2d0 01e3a88c 0020 1001
f0041385 00bf 609641e1 0118f110 00c99010 0001e978
Port selection is MII, full-duplex.
Transmit started, Receive started, full-duplex.
The Rx process state is 'Waiting for packets'.
The Tx process state is 'Idle'.
The transmit threshold is 72.
MII PHY found at address 1, status 0x782d.
MII PHY #1 transceiver registers:
3000 782d 0040 6212 01e1 41e1 0003
5000 032b 0002 0046 01cd 0100
003f f53e 0f00 ff00 002f 4000 80a0 000b.
This particular one is on a crossover @ 100 FD with a pcmcia tulip
card...which works fine.
The other machine I had reset tonight was on a crossover w/ cisco 3640
iirc.
-d
begin:vcard
n:Ford;David
x-mozilla-html:TRUE
url:www.blue-labs.org
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Blue Labs Developer
note;quoted-printable:GPG key: http:[EMAIL PROTECTED]=0D=0A
x-mozilla-cpt:;9952
fn:David Ford
end:vcard
Re: NETDEV WATCHDOG: eth0: transmit timed out
David wrote: > > Same old story, bugger still does it. Have to set the link down/up to > get it running again. > > 00:12.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev > 20) > I missed your earlier mails, could you resend the details? I'm interested in the output from tulip-diag -m -a -f before and after a link failure. I'm aware that the tulip drivers doesn't handle cable disconnects and reconnects with MII pnic cards. I have a patch for that problem, but it affects _all_ MII tulip cards, and thus it won't be included soon. If tulip-diag says "10mbps-serial", then you have run into that bug. -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
NETDEV WATCHDOG: eth0: transmit timed out
Same old story, bugger still does it. Have to set the link down/up to get it running again. I had to reset two systems tonight, one up for ~60 days, one up for two days. Both have this card. Unrelated traffic. This is kernel 2.4.0-test13-pre4 00:12.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20) Subsystem: Unknown device 1385:f004 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- begin:vcard n:Ford;David x-mozilla-html:TRUE url:www.blue-labs.org adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer note;quoted-printable:GPG key: http:[EMAIL PROTECTED]=0D=0A x-mozilla-cpt:;9952 fn:David Ford end:vcard
NETDEV WATCHDOG: eth0: transmit timed out
Same old story, bugger still does it. Have to set the link down/up to get it running again. I had to reset two systems tonight, one up for ~60 days, one up for two days. Both have this card. Unrelated traffic. This is kernel 2.4.0-test13-pre4 00:12.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20) Subsystem: Unknown device 1385:f004 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 64 set Interrupt: pin A routed to IRQ 11 Region 0: I/O ports at f800 Region 1: Memory at fdfffc00 (32-bit, non-prefetchable) -d begin:vcard n:Ford;David x-mozilla-html:TRUE url:www.blue-labs.org adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer note;quoted-printable:GPG key: http:[EMAIL PROTECTED]=0D=0A x-mozilla-cpt:;9952 fn:David Ford end:vcard
Re: NETDEV WATCHDOG: eth0: transmit timed out
Manfred wrote:
David wrote:
Same old story, bugger still does it. Have to set the link down/up to
get it running again.
00:12.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev
20)
I missed your earlier mails, could you resend the details?
I'm interested in the output from
tulip-diag -m -a -f
before and after a link failure.
I'm aware that the tulip drivers doesn't handle cable disconnects and
reconnects with MII pnic cards. I have a patch for that problem, but it
affects _all_ MII tulip cards, and thus it won't be included soon. If
tulip-diag says "10mbps-serial", then you have run into that bug.
--
Manfred
Here's the before, when the after happens..
# ./tulip-diag -m -a -f
tulip-diag.c:v2.04 9/26/2000 Donald Becker ([EMAIL PROTECTED])
http://www.scyld.com/diag/index.html
Index #1: Found a Lite-On 82c168 PNIC adapter at 0xf800.
Lite-On 82c168 PNIC chip registers at 0xf800:
8000 01ff 00450008 0118f000 0118f200 02660010 814c2202 0001ebef
0118f2d0 01e3a88c 0020 1001
f0041385 00bf 609641e1 0118f110 00c99010 0001e978
Port selection is MII, full-duplex.
Transmit started, Receive started, full-duplex.
The Rx process state is 'Waiting for packets'.
The Tx process state is 'Idle'.
The transmit threshold is 72.
MII PHY found at address 1, status 0x782d.
MII PHY #1 transceiver registers:
3000 782d 0040 6212 01e1 41e1 0003
5000 032b 0002 0046 01cd 0100
003f f53e 0f00 ff00 002f 4000 80a0 000b.
This particular one is on a crossover @ 100 FD with a pcmcia tulip
card...which works fine.
The other machine I had reset tonight was on a crossover w/ cisco 3640
iirc.
-d
begin:vcard
n:Ford;David
x-mozilla-html:TRUE
url:www.blue-labs.org
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Blue Labs Developer
note;quoted-printable:GPG key: http:[EMAIL PROTECTED]=0D=0A
x-mozilla-cpt:;9952
fn:David Ford
end:vcard
Re: NETDEV WATCHDOG: eth0: transmit timed out
On Thu, Dec 28, 2000 at 12:26:06PM +0100, Manfred wrote: David wrote: Same old story, bugger still does it. Have to set the link down/up to get it running again. 00:12.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20) I missed your earlier mails, could you resend the details? I'm interested in the output from tulip-diag -m -a -f before and after a link failure. I'm aware that the tulip drivers doesn't handle cable disconnects and reconnects with MII pnic cards. I have a patch for that problem, but it affects _all_ MII tulip cards, and thus it won't be included soon. If tulip-diag says "10mbps-serial", then you have run into that bug. I have the same transmit timeout problem, but with a D-Link via rhine board. I'm running -test10, and it seems to happen under high (interrupt?) load with both heavy disk and network activity. Interestingly, it appears to happen more often when the other end of the network activity is a 10BaseT link. I'm using a Netgear dual-speed hub. Do you think these might be related? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [bug] NETDEV WATCHDOG: eth0: transmit timed out
On Thu, 2 Nov 2000, David Ford wrote: > Dan Hollis wrote: > > On Thu, 2 Nov 2000, David Ford wrote: > > > Ok, something happend to the tulip driver in the recent testN kernels. > > > I haven't found a reason why it happens and I can't easily reproduce it > > > but what happens is noted on the subject line. > > > I have three machines now that do this. It's unfixable until reboot (I > > > don't have these as modules). > > What card, linksys lne100tx? > yep Im working on this problem as we speak. -Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [bug] NETDEV WATCHDOG: eth0: transmit timed out
Dan Hollis wrote: > On Thu, 2 Nov 2000, David Ford wrote: > > Ok, something happend to the tulip driver in the recent testN kernels. > > I haven't found a reason why it happens and I can't easily reproduce it > > but what happens is noted on the subject line. > > I have three machines now that do this. It's unfixable until reboot (I > > don't have these as modules). > > What card, linksys lne100tx? > > -Dan yep 00:13.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20) Subsystem: Netgear FA310TX Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- [disabled] [size=256K] -d -- "The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'." begin:vcard n:Ford;David x-mozilla-html:TRUE org:http://www.kalifornia.com/images/paradise.jpg"> adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;-12480 fn:David Ford end:vcard
[bug] NETDEV WATCHDOG: eth0: transmit timed out
Ok, something happend to the tulip driver in the recent testN kernels. I haven't found a reason why it happens and I can't easily reproduce it but what happens is noted on the subject line. I have three machines now that do this. It's unfixable until reboot (I don't have these as modules). I have a suspicion that it's triggered by large amounts of traffic. My brother feels he is able to trigger it repeatedly by doing big transfers between a w9x box and a linux box. -d -- "The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'." begin:vcard n:Ford;David x-mozilla-html:TRUE org:http://www.kalifornia.com/images/paradise.jpg"> adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;-12480 fn:David Ford end:vcard
[bug] NETDEV WATCHDOG: eth0: transmit timed out
Ok, something happend to the tulip driver in the recent testN kernels. I haven't found a reason why it happens and I can't easily reproduce it but what happens is noted on the subject line. I have three machines now that do this. It's unfixable until reboot (I don't have these as modules). I have a suspicion that it's triggered by large amounts of traffic. My brother feels he is able to trigger it repeatedly by doing big transfers between a w9x box and a linux box. -d -- "The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'." begin:vcard n:Ford;David x-mozilla-html:TRUE org:img src="http://www.kalifornia.com/images/paradise.jpg" adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;-12480 fn:David Ford end:vcard
Re: [bug] NETDEV WATCHDOG: eth0: transmit timed out
Dan Hollis wrote: On Thu, 2 Nov 2000, David Ford wrote: Ok, something happend to the tulip driver in the recent testN kernels. I haven't found a reason why it happens and I can't easily reproduce it but what happens is noted on the subject line. I have three machines now that do this. It's unfixable until reboot (I don't have these as modules). What card, linksys lne100tx? -Dan yep 00:13.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20) Subsystem: Netgear FA310TX Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 32 set Interrupt: pin A routed to IRQ 10 Region 0: I/O ports at 6200 [size=256] Region 1: Memory at e4001000 (32-bit, non-prefetchable) [size=256] Expansion ROM at unassigned [disabled] [size=256K] -d -- "The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'." begin:vcard n:Ford;David x-mozilla-html:TRUE org:img src="http://www.kalifornia.com/images/paradise.jpg" adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer x-mozilla-cpt:;-12480 fn:David Ford end:vcard
Re: [bug] NETDEV WATCHDOG: eth0: transmit timed out
On Thu, 2 Nov 2000, David Ford wrote: Dan Hollis wrote: On Thu, 2 Nov 2000, David Ford wrote: Ok, something happend to the tulip driver in the recent testN kernels. I haven't found a reason why it happens and I can't easily reproduce it but what happens is noted on the subject line. I have three machines now that do this. It's unfixable until reboot (I don't have these as modules). What card, linksys lne100tx? yep Im working on this problem as we speak. -Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
