[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080425.004523.146850490.davem@davemloft.net>
Date: Fri, 25 Apr 2008 00:45:23 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: jirislaby@...il.com
Cc: torvalds@...ux-foundation.org, zdenek.kabelac@...il.com,
mingo@...e.hu, rjw@...k.pl, paulmck@...ux.vnet.ibm.com,
linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
linux-ext4@...r.kernel.org, herbert@...dor.apana.org.au,
penberg@...helsinki.fi, clameter@....com,
johannes@...solutions.net, flamingice@...rmilk.net, jbenc@...e.cz
Subject: Re: 2.6.25-git2: BUG: unable to handle kernel paging request at
ffffffffffffffff
From: Jiri Slaby <jirislaby@...il.com>
Date: Fri, 25 Apr 2008 09:41:12 +0200
> Added 3 80211 experts.
>
> On 04/25/2008 03:57 AM, David Miller wrote:
> > From: Linus Torvalds <torvalds@...ux-foundation.org>
> > Date: Thu, 24 Apr 2008 18:48:32 -0700 (PDT)
> >
> >> But that 0xf0 definitely has shown up before. It's not the *only*
> >> corruption, but it's definitely a very interesting pattern. And the other
> >> ones that didn't show the 0xf0 pattern could obviously be due to pointers
> >> that were corrupted by 0xf0 in low bytes, so it _may_ be the source of the
> >> other corruptions too that didn't have an obvious 0xf0 directly in them.
> >
> > Ok.
> >
> > Do we know of any pattern of the wireless device type in use?
> > If there is a pattern to that, it would be a huge clue.
> >
> > And if it is predominantly one particular wireless device type, we
> > should be able to come up with a patch to test.
>
> Johannes, Michael, Jiri? Someone writes to freed memory patterns 0xf0 (not
> aligned to anything, addressed per byte), one of suspects is mac80211, don't you
> know that pattern from anywhere?
I notice Jiri, in your hardware list, you have an ath5k Atheros AR5212 chip
in there.
I took a look at the resume code for ath5k but nothing really suspicious
there except:
err = pci_enable_device(pdev);
if (err)
return err;
pci_restore_state(pdev);
Shouldn't we restore state before we turn the chip back on and thus
potentially let it start DMA'ing all over the place?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists