lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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