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 
> bogus,
> 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 
> sanity-checked?
>
> I have no clue where the wrong header comes from, though.

Martin,

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!

Done, kern/19605.

Cheers,
--
Paul Ripke
Unix/OpenVMS/DBA
101 reasons why you can't find your Sysadmin:
68: It's 9AM. He/She is not working that late.
-- Koos van den Hout