[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200703052219.23439.tuxiko@free.fr>
Date: Mon, 5 Mar 2007 22:19:23 +0100
From: Eric Lacombe <tuxiko@...e.fr>
To: Francois Romieu <romieu@...zoreil.com>
Cc: linux-kernel <linux-kernel@...r.kernel.org>,
Steve French <sfrench@...ibm.com>
Subject: Re: Linux 2.6.19.2: maybe a bug inside the r8169 network driver (was Re: Linux 2.6.19.2: Freeze with CIFS mount)
Hello,
Sorry for the long time without giving new information about the problem/bug,
but I wasn't able to trigger it since now.
Well, this time, my system freeze on a 2.6.20.1.
I try to use the magic sysrq (which works fine when my system is running), but
nothing happen (unraw, reboot, etc.).
Also, as I used the nvidia proprietary module when I reported this problem,
I've not open PR at bugzilla.kernel.org.
During 5 days, my system on a fresh 2.6.20.1 hasn't freezed without the nvidia
proprietary driver (just the nv driver from X).
So, I thought it was ok and I modprobe the nvidia driver (cause with nv I have
some minor display problems). Since today, after 7 days of well-behavior, my
system has freezed again.
So, now, I check again to see if it could crash without the nvidia driver...
Grrrr..
I will also do what you recommend here :
> > 6. You may setup a cron to monitor an ethtool dump of the register of
> > the 8169 at regular interval. ifconfig and /proc/interrupts could
> > exhibit some unusual drift as time passes on too.
I join the result of dmesg as wanted. Feel free to ask more information if
needed.
(the cifs log looks like before so I haven't joined it)
Also, if you have some new ideas about the problem or what I could try to
trigger it more frequently (I already wake up the NAS as more as I can, but
maybe I could write a script to do that), I would be thankful.
Best regards,
Eric Lacombe
On Wednesday 14 February 2007 11:49:52 Eric Lacombe wrote:
> On Tuesday 13 February 2007 21:30:47 Francois Romieu wrote:
> > Eric Lacombe <tuxiko@...e.fr> :
> > [...]
> >
> > > That problem also remind me that when I compiled this driver without
> > > the "CONFIG_NET_ETHERNET" (in the section "Ethernet (10 or 100Mbit)"),
> > > I have really poor performance with the net device. Maybe it is
> > > related, or not ;)
> > >
> > > If it gives you more ideas ?
> > > Maybe it could be interesting to know about the r8169 maintainer, but I
> > > dont know who he is.
> >
> > 1. $ ls
> > arch crypto include kernel mm scripts
> > block Documentation init lib net security
> > COPYING drivers ipc MAINTAINERS README sound
> > CREDITS fs Kbuild Makefile REPORTING-BUGS usr
> >
> > The maintainer of the r8169 driver is listed in the MAINTAINERS file.
>
> I see, thanks ;)
>
> (I thought the MAINTAINERS file was not fully maintained ;)
>
> > 2. Disabling CONFIG_NET_ETHERNET is a bad idea. Don't do that.
>
> ok, but why having it only inside the "ethernet 100" menu ?
> It is misleading, no ?
>
> > 3. See tethereal -w or tcpdump on the adequate interface to save a
> > traffic dump.
>
> yep, but the problem is that I cant do that from the NAS Box. I will try to
> monitor the traffic via the system that will freeze... For the moment I
> can't monitor the net traffic from an alternate PC, but soon.
>
> > 4. Are you using a binary module for your video adapter ?
>
> yes, I suppose that I have to unload this one before doing further tests.
>
> > 5. How does the 2.6.20 version of the r8169 driver behave ?
>
> I don't have installed it yet, but I'll do it this evening.
>
> > 6. You may setup a cron to monitor an ethtool dump of the register of
> > the 8169 at regular interval. ifconfig and /proc/interrupts could
> > exhibit some unusual drift as time passes on too.
>
> I will do that. When I could put a third system to monitor the traffic, I
> will make "the system that freeze" keep sending that information to it.
>
> > 7. A dmesg would be welcome.
>
> I could do that, this evening.
>
> > 8. Please open a PR at bugzilla.kernel.org.
>
> ok
>
> > |...]
> > |
> > > > There are various ways to analyze system hangs including (at least in
> > > > some cases) getting a system dump which
> > > > can be used to isolate the failing location - hopefully
> > >
> > > I would like to have more detailed help, if possible.
> >
> > CONFIG_MAGIC_SYSRQ is set. Check that the magic sysrq is not disabled at
> > runtime through /etc/sysctl.conf. See Documentation/sysrq.txt for
> > details.
>
> ok
>
> > Please keep Steve French in the loop.
>
> ok
>
> Thanks for your response ;)
>
> Eric
View attachment "dmesg" of type "text/plain" (21181 bytes)
Powered by blists - more mailing lists