Prev: ftrace,kdb: Extend kdb to be able to dump the ftrace buffer
Next: obsolete in kernel source (B43_LEGACY_RFKILL)
From: Zhu Yi on 20 Jan 2010 04:40
On Mon, 2010-01-18 at 22:47 -0700, Norbert Preining wrote:
> Hi Reinette,
>
> On Fr, 15 Jan 2010, reinette chatre wrote:
> > > I am having repeatable complete hard lockups on my laptop with 2.6.33-rc4.
> > > 2.6.32.3 works fine.
> > >
> > > I believe that it is related to the network, because sometimes I can
> > > actually log in (gnomes session) and as soon as I do some network
> > > related suddenly hard hang, not even Sysrq working anymore.
> > >
> > > Interestingly it only happens at a specific AP where the ESSID is
> > > hidden (at work). At home I can work without any problems (ESSID not
> > > hidden).
> > >
> > > Unfortunately I cannot set up a serial console or similar.
> >
> > Does that mean no netconsole either? Does anything show up in the logs?
> > Is it easy to reproduce? If so, perhaps you can have increased debug at
> > that time and hopefully something will be captured in the logs when the
> > problem occurs.
>
> Ok, I can confirm that setting up the network is not the problem, nor
> is it pinging other hosts. But ssh-ing into another server
> made it go boom. From the screenshot I attach it looks like something
> in TCP code (that explains why it does not happen in pings), below
> I see tcp_data_snd_check
>
> I managed to swithc in time to a console with tail -f syslog before
> it hard locked up. The log files are empty, but I got a screenshot photo
> which has some hopefully useful information. I cannot scroll up or down
> anymore ...

Looks like this this is the BUG_ON in skb_pull. Please try if this patch
help? BTW, are you using swiotlb?

diff --git a/drivers/net/wireless/iwlwifi/iwl-rx.c b/drivers/net/wireless/iwlwifi/iwl-rx.c
index 6f36b6e..2f8978f 100644
--- a/drivers/net/wireless/iwlwifi/iwl-rx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-rx.c
@@ -1031,6 +1031,11 @@ void iwl_rx_reply_rx(struct iwl_priv *priv,
return;
}

+ if (len < ieee80211_hdrlen(header->frame_control)) {
+ IWL_DEBUG_RX(priv, "Packet size is too small %d\n", len);
+ return;
+ }
+
/* This will be used in several places later */
rate_n_flags = le32_to_cpu(phy_res->rate_n_flags);



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Johannes Berg on 20 Jan 2010 05:00
On Wed, 2010-01-20 at 01:36 +0100, Norbert Preining wrote:
> On Di, 19 Jan 2010, Johannes Berg wrote:
> > Sorry, no, seems weird. The trace is not very useful unfortunately,
> is
> > this with CONFIG_FRAME_POINTER?
>
> # CONFIG_FRAME_POINTER is not set
>
> Do you need it?

The stacktrace would be a lot more useful with it set, yes. Other than
that, I don't know. If there's a way to make your display resolution
higher that might be useful so more info fits on the screen, or maybe
trimming the stack trace depth (though I don't know if that's possible,
I do know it is on powerpc because I added it there but not sure on x86)

All assuming you can reproduce this issue, of course.

johannes
From: Norbert Preining on 20 Jan 2010 19:30
Dear all,

On Mi, 20 Jan 2010, Zhu Yi wrote:
> Looks like this this is the BUG_ON in skb_pull. Please try if this patch
> help? BTW, are you using swiotlb?

On Mi, 20 Jan 2010, Johannes Berg wrote:
> > # CONFIG_FRAME_POINTER is not set
>
> The stacktrace would be a lot more useful with it set, yes. Other than
> that, I don't know. If there's a way to make your display resolution
> higher that might be useful so more info fits on the screen, or maybe
> trimming the stack trace depth (though I don't know if that's possible,
> I do know it is on powerpc because I added it there but not sure on x86)
>
> All assuming you can reproduce this issue, of course.


@Zhu: the patch didn't help. I patched it into the kernel plus activated
CONFIG_FRAME_POINTER which led to the same hang (not surprisingly, the
patch does only debug more ;-)

This time unfortunately I there was too much output to actually capture it.

@Johannes: 100% reproducible. Everytime I boot into 33-rc4 and ssh into
any remote place it goes boom. 100%.

Maybe another tidbig might help: With 2.6.32.3 it happens that I have
hickups with WLAN:
[ 996.514491] iwlagn 0000:06:00.0: iwl_tx_agg_start on ra = 00:24:c4:ab:bb:42 tid = 0
and the connections needs 10-20secs (hard to guess) until it is
back alive.

Best wishes

Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TU Wien, Austria Debian TeX Task Force
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
AITH (n.)
The single bristle that sticks out sideways on a cheap paintbrush.
--- Douglas Adams, The Meaning of Liff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: John Ranson on 21 Jan 2010 13:20
Do you have a point and shoot camera that can shoot video? I've used
one in the past to capture debug info that scrolls by too quickly.

John

On Wed, Jan 20, 2010 at 4:28 PM, Norbert Preining <preining(a)logic.at> wrote:
> Dear all,
>
> On Mi, 20 Jan 2010, Zhu Yi wrote:
>> Looks like this this is the BUG_ON in skb_pull. Please try if this patch
>> help? BTW, are you using swiotlb?
>
> On Mi, 20 Jan 2010, Johannes Berg wrote:
>> > # CONFIG_FRAME_POINTER is not set
>>
>> The stacktrace would be a lot more useful with it set, yes. Other than
>> that, I don't know. If there's a way to make your display resolution
>> higher that might be useful so more info fits on the screen, or maybe
>> trimming the stack trace depth (though I don't know if that's possible,
>> I do know it is on powerpc because I added it there but not sure on x86)
>>
>> All assuming you can reproduce this issue, of course.
>
>
> @Zhu: the patch didn't help. I patched it into the kernel plus activated
> CONFIG_FRAME_POINTER which led to the same hang (not surprisingly, the
> patch does only debug more ;-)
>
> This time unfortunately I there was too much output to actually capture it.
>
> @Johannes: 100% reproducible. Everytime I boot into 33-rc4 and ssh into
> any remote place it goes boom. 100%.
>
> Maybe another tidbig might help: With 2.6.32.3 it happens that I have
> hickups with WLAN:
> [ �996.514491] iwlagn 0000:06:00.0: iwl_tx_agg_start on ra = 00:24:c4:ab:bb:42 tid = 0
> and the connections needs 10-20secs (hard to guess) until it is
> back alive.
>
> Best wishes
>
> Norbert
> ------------------------------------------------------------------------
> Norbert Preining � � � � � �preining@{jaist.ac.jp, logic.at, debian.org}
> JAIST, Japan � � � � � �TU Wien, Austria � � � � � Debian TeX Task Force
> DSA: 0x09C5B094 � fp: 14DF 2E6C 0307 BE6D AD76 �A9C0 D2BF 4AA3 09C5 B094
> ------------------------------------------------------------------------
> AITH (n.)
> The single bristle that sticks out sideways on a cheap paintbrush.
> � � � � � � � � � � � �--- Douglas Adams, The Meaning of Liff
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> Ipw3945-devel mailing list
> Ipw3945-devel(a)lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ipw3945-devel
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Norbert Preining on 27 Jan 2010 10:40
Hi everyone,

On Mi, 20 Jan 2010, Zhu Yi wrote:
> Looks like this this is the BUG_ON in skb_pull. Please try if this patch
> help? BTW, are you using swiotlb?

As said, no it does not help.

I am currently running 2.6.33-rc5 and that bug is in my work place
100% reproducible.

Anything I can do more?

Should we move that to a bugzilla entry?

Best wishes

Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TU Wien, Austria Debian TeX Task Force
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
CAMER (n.)
A mis-tossed caber.
--- Douglas Adams, The Meaning of Liff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: ftrace,kdb: Extend kdb to be able to dump the ftrace buffer
Next: obsolete in kernel source (B43_LEGACY_RFKILL)