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 se
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 PROT
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 base
;
> 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
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]> :
> [...]
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 Romie
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 timeout
(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 6dccd16b7c2703e
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.
> [6dccd16b7c2703e8bbf8bca62b5cf248332afb
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 R
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
> af
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
the
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
-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 unsu
: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 frag
"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 h
, 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
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
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
ck 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 kern
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 m
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 inte
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 Communicatio
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 subj
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
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 ha
32 matches
Mail list logo