netdev - Re: [BUG] oops in net_rx_action on 64-bit powerpc

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:	Fri, 24 Oct 2008 17:39:00 -0600
From:	"Chris Friesen" <cfriesen@...tel.com>
To:	David Miller <davem@...emloft.net>
CC:	jesse.brandeburg@...el.com, linuxppc-dev@...abs.org,
	netdev@...r.kernel.org, romieu@...zoreil.com
Subject: Re: [BUG] oops in net_rx_action on 64-bit powerpc

David Miller wrote:
> From: "Brandeburg, Jesse" <jesse.brandeburg@...el.com> Date: Thu, 23 Oct
> 2008 14:50:06 -0700
> 
>> Chris Friesen wrote:
>>> I tried booting a post 2.6.27 -git on a Motorola ATCA6101 (very similar
>>> to a Maple board).  The first time I booted I got the first log below
>>> via the serial console.  I rebooted and got as far as a login prompt.
>>> I was able to log in via the serial console, but then got an almost
>>> identical oops again, as shown in the second log below.
>>> 
>>> I configed out the gigE drivers for the backplane so the only remaining
>>> network link was the e100 link used for booting, but the problem
>>> remained.
>>> 
>>> Anyone have any idea what might be causing this?
>>> 
>>> Thanks,
>>> 
>>> Chris
>>> 
>>> 
>>> Starting xinetd: [  OK  ] Starting cron: [  OK  ] Unable to handle
>>> kernel paging request for data at address 0x00100108
>> that 00100108 pattern looks familiar, I'm not much help here, but I think
>> that had something to do with the list management of the poll_list in a
>> netdev struct.
>> 
>> so now you just have to figure out why someone's netdev struct is
>> becoming NULL. :-)
> 
> Usually this is an indication of returning the wrong value from the
> driver's ->poll() routine.

Looks like I was wrong before...the remaining ethernet link is an AMD-8111, 
not an e100.  Sorry about that.

I backed out 6ba33ac "amd8111e: delete non NAPI code from the driver".  With 
NAPI disabled, the blade appears stable.  With NAPI enabled, the original 
problem recurred.

So...it would appear that the NAPI code is somehow buggy, and 6ba33ac should 
probably be reverted until the problem is found and fixed.

Chris
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html