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
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
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
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
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
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
;
> 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.
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
regressi
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
, 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
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]> :
> [...]
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
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
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
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
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
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
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
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
(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
(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
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.
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.
>
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
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
>
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
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
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
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
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 ?
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
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]
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: eth
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
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
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
ommunications 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 unsubscri
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
"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
, 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
, 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
"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
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 2
"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
t
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
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
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
n 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 ti
3 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
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
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
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
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
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
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
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
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
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
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
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
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.
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.
62 matches
Mail list logo
