netdev - Re: Kernel oops on setting sky2 interfaces down

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: <200908202237.43776.rene.mayrhofer@gibraltar.at>
Date:	Thu, 20 Aug 2009 22:37:43 +0200
From:	Rene Mayrhofer <rene.mayrhofer@...raltar.at>
To:	Stephen Hemminger <shemminger@...ux-foundation.org>
Cc:	Mike McCormack <mikem@...g3k.org>, netdev@...r.kernel.org,
	Richard Leitner <leitner@...s.at>
Subject: Re: Kernel oops on setting sky2 interfaces down

Hi Stephen,

Am Donnerstag, 20. August 2009 02:46:29 schrieb Stephen Hemminger:
> On Thu, 20 Aug 2009 07:05:03 +0900
>
> Mike McCormack <mikem@...g3k.org> wrote:
> > 2009/8/20 Rene Mayrhofer <rene.mayrhofer@...raltar.at>:
> > > Pulling the latest sky2.c and sky2.h from net-next-2.6 and applying the
> > > patch rids me of the oops - it is unreproducible right now. However, a
> > > networking restart (i.e. all interfaces attached to sky2) leaves the
> > > devices in a state where they no longer receive any network packets (at
> > > least nothing visible in tcpdump). In this state, rmmod sky2 / modprobe
> > > sky2 gives:
> >
> > After you've got it into that state, does "rmmod sky2; modprobe sky2"
> > change anything?

Nope, tried it multiple times.

I've also tried the net-next-2.6 version of sky2.[ch] as of yesterday without 
Mike's "bandaid" patches. With that version (the last one in branch 
gibraltar-3.0 at https://www.gibraltar.at/git/linux-2.6-gibraltar.git), I 
managed to successfully do a networking restart (with "light" traffic on one 
interface), leaving the interfaces functional after the restart. This worked 
even twice in a row, so mabye we are onto something here. This is certainly an 
improvement over the version with Mike's last patch (from yesterday) applied, 
which left the interfaces broken after a restart (and with the quoted errors 
on a rmmod/modprobe sky2). 

However, after doing a ping -f on one of the (GBit) interfaces to another host 
on the same switch for a few seconds and then executing networking restart, 
the result was an immediate reboot of the box without any oops being printed 
to the (serial) console beforehand. 

The same thing happened without particularly heavy traffic after executing 
networking restart twice and then just letting the box sit idle (with some 
traffic on the interfaces) for a few minutes.

> Please send (I forget) the hardware info (lspci) and the register values
> from ethtool -d ethX.

Attached (lspci -v).

> Some part of the power control doesn't work on Rene's system, so
> device falls off the bus. Probably no auxilary +5 supplied, the register
> values will tell whether driver is at fault (turning on aux when not
> available), or hardware is lying about vaux.

Is it possible to disable (kernel-level) power control for particular PCI 
devices to check if this is indeed the issue? Or do you suspect hardware-level 
power-off when the chip state goes down?

best regards,
Rene

-- 
-------------------------------------------------
Gibraltar firewall       http://www.gibraltar.at/

Download attachment "lspci.out.gz" of type "application/x-gzip" (1600 bytes)

Download attachment "ethtool.out.gz" of type "application/x-gzip" (1425 bytes)