linux-kernel - 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)

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]

Message-Id: <200703072048.29398.tuxiko@free.fr>
Date:	Wed, 7 Mar 2007 20:48:29 +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>,
	Eric Lacombe <tuxiko@...e.fr>
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,

On Tuesday 06 March 2007 17:42:36 Eric Lacombe wrote:
> Hello,
>
> I've just triggered the bug again but _now_ without the nvidia proprietary
> module. Unfortunately, I hadn't enable the DEBUG options yet.
>
> Nevertheless, It seems that the bug was triggered when the NAS was going to
> awake and that 2 user applications wanted to access it during his
> awakening.
>
> Maybe it could give you some clues about where the problem could be (it
> seems to be a deadlock that occur when (maybe) the r8169 driver is waiting
> to serve one application and that an other one reclaim the same type of
> service, dunno...).
>
> I will give you more information and a trace if I can obtain it.

I have some new results.

I can now trigger the bug relatively easily. I can crash the system using the 
assumption that I made previously :

-----------
1. I wait for the NAS to sleep.

2. I access the NAS with the Amarok application to read a mp3 file. This 
action triggers the awakening of the NAS (~3 secs).

3. Before the NAS awakes, I access the NAS from another application : a file 
manager (Konqueror).
I click on the directory that contains the mp3 (which is the same directory 
that is accessed by amarok - this directory contains the mounted cifs volume 
of the NAS).

4. The system freezes.
-------------

Note that I've enabled the following debug options inside the kernel (as you 
suggest) :
CONFIG_DETECT_SOFTLOCKUP, CONFIG_DEBUG_STACK_USAGE, CONFIG_DEBUG_SPINLOCK, 
CONFIG_DEBUG_SPINLOCK_SLEEP, CONFIG_DEBUG_STACKOVERFLOW.

I've also disabled the preemption.

When I proceed to the step 3, I have on the screen a console application that 
display what syslog-ng provide. I tested the console by using the magic sysrq 
(via alt-sysrq-cmd_key), and it prints well.

Unfortunately, when the system crash no trace appear on the console :/

So, I'm stuck with those information. But I hope that they could give you some 
insights.
Also, feel free to give me other stuff that you want I try (however, I could 
not do it before the next week).

Also, I have setup a cron to monitor an ethtool dump of the registers of the 
8169 at regular intervals : each 5 minutes. I join the last part of the file.

Best regards,

	Eric Lacombe

>
> Thanks
>
> 	Eric Lacombe
>
> On Monday 05 March 2007 23:16:40 Francois Romieu wrote:
> > Eric Lacombe <tuxiko@...e.fr> :
> > [...]
> >
> > > 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.
> >
> > You can add more DEBUG options for spinlock and stack usage, disable
> > preempt and pray for a trace before the crash. If you do not have a
> > second host to add more traffic (wrt to bandwidth and/or pps), try to
> > dd your disk and/or your remote storage to /dev/null while watching TV.
> >
> > You are out of luck if it does not crash more easily.

View attachment "ethtool.result" of type "text/plain" (71353 bytes)