Subject: Re: Repeatable panic in wi_read_bap
To: Martin Husemann <firstname.lastname@example.org>
From: Paul Ripke <email@example.com>
Date: 12/31/2002 00:39:19
On Monday, December 30, 2002, at 11:48 PM, Martin Husemann wrote:
> On Mon, Dec 30, 2002 at 11:34:37PM +1100, Paul Ripke wrote:
>> wi_read_bap(c06fd000,286,3c,ca45f018,54fe) at wi_read_bap+0x96
>> wi_rx_intr(c06fd000,0,c01be614,c045ee7c,c06f1ec0) at wi_rx_intr+0x3c1
> Hmm, wi_read_bap is called with a len of 0x54fe - this looks highly
> as the mbuf that this is read into surely can not hold that much data
> The call where this probably happens is in wi_rx_intr:
> len = le16toh(frmhdr.wi_dat_len);
> off = ALIGN(sizeof(struct ieee80211_frame));
> and later:
> wi_read_bap(sc, fid, sizeof(frmhdr),
> m->m_data + sizeof(struct ieee80211_frame), len);
> Probably the len from the received frame header should be
> I have no clue where the wrong header comes from, though.
What's worse, is that the mbuf pointer is invalid in the dump I'm
looking at. Just a hunch, but since this only seems to happen when
there is a high amount of interrupt activity (SCSI and tlp0 so far),
could another interrupt routine be called and stomp on the stack?
'm' appears to be a register var in the context of wi_rx_intr, and
is 0xca68906c in the crash I'm looking at.
> Please file a PR!
101 reasons why you can't find your Sysadmin:
68: It's 9AM. He/She is not working that late.
-- Koos van den Hout