* Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
From: Daniel Mack @ 2012-10-21 12:12 UTC (permalink / raw)
To: Artem S. Tashkinov
Cc: bp, pavel, linux-kernel, netdev, security, linux-media, linux-usb
In-Reply-To: <121566322.100103.1350820776893.JavaMail.mail@webmail20>
On 21.10.2012 13:59, Artem S. Tashkinov wrote:
> On Oct 21, 2012, Borislav Petkov wrote:
>>
>> On Sun, Oct 21, 2012 at 01:57:21AM +0000, Artem S. Tashkinov wrote:
>>> The freeze happens on my *host* Linux PC. For an experiment I decided
>>> to check if I could reproduce the freeze under a virtual machine - it
>>> turns out the Linux kernel running under it also freezes.
>>
>> I know that - but a freeze != oops - at least not necessarily. Which
>> means it could very well be a different issue now that vbox is gone.
>>
>> Or, it could be the same issue with different incarnations: with vbox
>> you get the corruptions and without it, you get the freezes. I'm
>> assuming you do the same flash player thing in both cases?
>>
>> Here's a crazy idea: can you try to reproduce it in KVM?
>
> OK, dismiss VBox altogether - it has a very buggy USB implementation, thus
> it just hangs when trying to access my webcam.
>
> What I've found out is that my system crashes *only* when I try to enable
> usb-audio (from the same webcam)
It would also be interesting to know whether you have problems with
*only* the video capture, with some tool like "cheese". It might be
you're hitting a host controller issue here, and then isochronous input
packets on the video interface would most likely also trigger such am
effect. Actually, knowing whether that's the case would be crucial for
further debugging.
Daniel
^ permalink raw reply
* Re: [net-next 12/13] ixgbe: Add support for pipeline reset
From: Martin Josefsson @ 2012-10-21 12:06 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Don Skidmore, netdev, gospo, sassmann
In-Reply-To: <1350714367-24208-13-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, Oct 20, 2012 at 8:26 AM, Jeff Kirsher
<jeffrey.t.kirsher@intel.com> wrote:
> From: Don Skidmore <donald.c.skidmore@intel.com>
Hi Jeff, Don,
> Calling the ixgbe_reset_pipeline_82599 function will ensure a full pipeline
> reset on all 82599 devices. This is necessary to avoid possible link issues.
> Since this patch accomplishes this by modifying AUTOC.LMS we need to wrap
> all AUTOC writes when LESM is enabled.
The section below doesn't look right.
Old behaviour gave LMS == 011b (SFI)
New behaviour gives LMS == 000b (1 GbE link (no backplane auto-negotiation))
LMS is reset to 0 before ixgbe_reset_pipeline_82599() is called.
Looks like that part of the old code wasn't removed.
> @@ -137,28 +135,37 @@ static s32 ixgbe_setup_sfp_modules_82599(struct ixgbe_hw *hw)
> usleep_range(hw->eeprom.semaphore_delay * 1000,
> hw->eeprom.semaphore_delay * 2000);
>
> + /* Need SW/FW semaphore around AUTOC writes if LESM on,
> + * likewise reset_pipeline requires lock as it also writes
> + * AUTOC.
> + */
> + if (ixgbe_verify_lesm_fw_enabled_82599(hw)) {
> + ret_val = hw->mac.ops.acquire_swfw_sync(hw,
> + IXGBE_GSSR_MAC_CSR_SM);
> + if (ret_val)
> + goto setup_sfp_out;
> +
> + got_lock = true;
> + }
> +
> /* Now restart DSP by setting Restart_AN and clearing LMS */
> IXGBE_WRITE_REG(hw, IXGBE_AUTOC, ((IXGBE_READ_REG(hw,
> IXGBE_AUTOC) & ~IXGBE_AUTOC_LMS_MASK) |
> IXGBE_AUTOC_AN_RESTART));
>
> - /* Wait for AN to leave state 0 */
> - for (i = 0; i < 10; i++) {
> - usleep_range(4000, 8000);
> - reg_anlp1 = IXGBE_READ_REG(hw, IXGBE_ANLP1);
> - if (reg_anlp1 & IXGBE_ANLP1_AN_STATE_MASK)
> - break;
> + ret_val = ixgbe_reset_pipeline_82599(hw);
> +
> + if (got_lock) {
> + hw->mac.ops.release_swfw_sync(hw,
> + IXGBE_GSSR_MAC_CSR_SM);
> + got_lock = false;
> }
> - if (!(reg_anlp1 & IXGBE_ANLP1_AN_STATE_MASK)) {
> - hw_dbg(hw, "sfp module setup not complete\n");
> +
> + if (ret_val) {
> + hw_dbg(hw, " sfp module setup not complete\n");
> ret_val = IXGBE_ERR_SFP_SETUP_NOT_COMPLETE;
> goto setup_sfp_out;
> }
> -
> - /* Restart DSP by setting Restart_AN and return to SFI mode */
> - IXGBE_WRITE_REG(hw, IXGBE_AUTOC, (IXGBE_READ_REG(hw,
> - IXGBE_AUTOC) | IXGBE_AUTOC_LMS_10G_SERIAL |
> - IXGBE_AUTOC_AN_RESTART));
> }
>
> setup_sfp_out:
--
/Martin
^ permalink raw reply
* Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
From: Daniel Mack @ 2012-10-21 12:03 UTC (permalink / raw)
To: Artem S. Tashkinov
Cc: bp-Gina5bIWoIWzQB+pC5nmwQ, pavel-+ZI9xUNit7I,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, security-DgEjT+Ai2ygdnm+yROfE0A,
linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <121566322.100103.1350820776893.JavaMail.mail@webmail20>
On 21.10.2012 13:59, Artem S. Tashkinov wrote:
> On Oct 21, 2012, Borislav Petkov wrote:
>>
>> On Sun, Oct 21, 2012 at 01:57:21AM +0000, Artem S. Tashkinov wrote:
>>> The freeze happens on my *host* Linux PC. For an experiment I decided
>>> to check if I could reproduce the freeze under a virtual machine - it
>>> turns out the Linux kernel running under it also freezes.
>>
>> I know that - but a freeze != oops - at least not necessarily. Which
>> means it could very well be a different issue now that vbox is gone.
>>
>> Or, it could be the same issue with different incarnations: with vbox
>> you get the corruptions and without it, you get the freezes. I'm
>> assuming you do the same flash player thing in both cases?
>>
>> Here's a crazy idea: can you try to reproduce it in KVM?
>
> OK, dismiss VBox altogether - it has a very buggy USB implementation, thus
> it just hangs when trying to access my webcam.
Ok.
> What I've found out is that my system crashes *only* when I try to enable
> usb-audio (from the same webcam) - I still have no idea how to capture a
> panic message, but I ran
>
> "while :; do dmesg -c; done" in xterm, then I got like thousands of messages
> and I photographed my monitor:
>
> http://imageshack.us/a/img685/9452/panicz.jpg
A hint at least. How did you enable the audio record exactly? Can you
reproduce this with arecord?
What chipset are you on? Please provide both "lspci -v" and "lsusb -v"
dumps. As I said, I fail to reproduce that issue on any of my machines.
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Re: Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
From: Artem S. Tashkinov @ 2012-10-21 11:59 UTC (permalink / raw)
To: bp; +Cc: pavel, linux-kernel, netdev, security, linux-media, linux-usb
In-Reply-To: <20121021110851.GA6504@liondog.tnic>
On Oct 21, 2012, Borislav Petkov wrote:
>
> On Sun, Oct 21, 2012 at 01:57:21AM +0000, Artem S. Tashkinov wrote:
> > The freeze happens on my *host* Linux PC. For an experiment I decided
> > to check if I could reproduce the freeze under a virtual machine - it
> > turns out the Linux kernel running under it also freezes.
>
> I know that - but a freeze != oops - at least not necessarily. Which
> means it could very well be a different issue now that vbox is gone.
>
> Or, it could be the same issue with different incarnations: with vbox
> you get the corruptions and without it, you get the freezes. I'm
> assuming you do the same flash player thing in both cases?
>
> Here's a crazy idea: can you try to reproduce it in KVM?
OK, dismiss VBox altogether - it has a very buggy USB implementation, thus
it just hangs when trying to access my webcam.
What I've found out is that my system crashes *only* when I try to enable
usb-audio (from the same webcam) - I still have no idea how to capture a
panic message, but I ran
"while :; do dmesg -c; done" in xterm, then I got like thousands of messages
and I photographed my monitor:
http://imageshack.us/a/img685/9452/panicz.jpg
list_del corruption. prev->next should be ... but was ...
I cannot show you more as I have no serial console to use :( and the kernel
doesn't have enough time to push error messages to rsyslog and fsync
/var/log/messages
^ permalink raw reply
* Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
From: Daniel Mack @ 2012-10-21 11:59 UTC (permalink / raw)
To: Artem S. Tashkinov
Cc: bp, pavel, linux-kernel, netdev, security, linux-media, linux-usb
In-Reply-To: <5083CFCD.60303@gmail.com>
On 21.10.2012 12:34, Daniel Mack wrote:
> On 21.10.2012 01:15, Artem S. Tashkinov wrote:
>> You don't get me - I have *no* VirtualBox (or any proprietary) modules running
>> - but I can reproduce this problem using *the same system running under* VirtualBox
>> in Windows 7 64.
>>
>> It's almost definitely either a USB driver bug or video4linux driver bug:
>>
>> I'm CC'ing linux-media and linux-usb mailing lists, the problem is described here:
>> https://lkml.org/lkml/2012/10/20/35
>> https://lkml.org/lkml/2012/10/20/148
>>
>> Here are the last lines from my dmesg (with usbmon loaded):
>>
>> [ 292.164833] hub 1-0:1.0: state 7 ports 8 chg 0000 evt 0002
>> [ 292.168091] ehci_hcd 0000:00:1f.5: GetStatus port:1 status 00100a 0 ACK POWER sig=se0 PEC CSC
>> [ 292.172063] hub 1-0:1.0: port 1, status 0100, change 0003, 12 Mb/s
>> [ 292.174883] usb 1-1: USB disconnect, device number 2
>> [ 292.178045] usb 1-1: unregistering device
>> [ 292.183539] usb 1-1: unregistering interface 1-1:1.0
>> [ 292.197034] usb 1-1: unregistering interface 1-1:1.1
>> [ 292.204317] usb 1-1: unregistering interface 1-1:1.2
>> [ 292.234519] usb 1-1: unregistering interface 1-1:1.3
>> [ 292.236175] usb 1-1: usb_disable_device nuking all URBs
>> [ 292.364429] hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x100
>> [ 294.364279] hub 1-0:1.0: hub_suspend
>> [ 294.366045] usb usb1: bus auto-suspend, wakeup 1
>> [ 294.367375] ehci_hcd 0000:00:1f.5: suspend root hub
>> [ 296.501084] usb usb1: usb wakeup-resume
>> [ 296.508311] usb usb1: usb auto-resume
>> [ 296.509833] ehci_hcd 0000:00:1f.5: resume root hub
>> [ 296.560149] hub 1-0:1.0: hub_resume
>> [ 296.562240] ehci_hcd 0000:00:1f.5: GetStatus port:1 status 001003 0 ACK POWER sig=se0 CSC CONNECT
>> [ 296.566141] hub 1-0:1.0: port 1: status 0501 change 0001
>> [ 296.670413] hub 1-0:1.0: state 7 ports 8 chg 0002 evt 0000
>> [ 296.673222] hub 1-0:1.0: port 1, status 0501, change 0000, 480 Mb/s
>> [ 297.311720] usb 1-1: new high-speed USB device number 3 using ehci_hcd
>> [ 300.547237] usb 1-1: skipped 1 descriptor after configuration
>> [ 300.549443] usb 1-1: skipped 4 descriptors after interface
>> [ 300.552273] usb 1-1: skipped 2 descriptors after interface
>> [ 300.556499] usb 1-1: skipped 1 descriptor after endpoint
>> [ 300.559392] usb 1-1: skipped 2 descriptors after interface
>> [ 300.560960] usb 1-1: skipped 1 descriptor after endpoint
>> [ 300.562169] usb 1-1: skipped 2 descriptors after interface
>> [ 300.563440] usb 1-1: skipped 1 descriptor after endpoint
>> [ 300.564639] usb 1-1: skipped 2 descriptors after interface
>> [ 300.565828] usb 1-1: skipped 2 descriptors after endpoint
>> [ 300.567084] usb 1-1: skipped 9 descriptors after interface
>> [ 300.569205] usb 1-1: skipped 1 descriptor after endpoint
>> [ 300.570484] usb 1-1: skipped 53 descriptors after interface
>> [ 300.595843] usb 1-1: default language 0x0409
>> [ 300.602503] usb 1-1: USB interface quirks for this device: 2
>> [ 300.605700] usb 1-1: udev 3, busnum 1, minor = 2
>> [ 300.606959] usb 1-1: New USB device found, idVendor=046d, idProduct=081d
>> [ 300.610298] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=1
>> [ 300.613742] usb 1-1: SerialNumber: 48C5D2B0
>> [ 300.617703] usb 1-1: usb_probe_device
>> [ 300.620594] usb 1-1: configuration #1 chosen from 1 choice
>> [ 300.639218] usb 1-1: adding 1-1:1.0 (config #1, interface 0)
>> [ 300.640736] snd-usb-audio 1-1:1.0: usb_probe_interface
>> [ 300.642307] snd-usb-audio 1-1:1.0: usb_probe_interface - got id
>> [ 301.050296] usb 1-1: adding 1-1:1.1 (config #1, interface 1)
>> [ 301.054897] usb 1-1: adding 1-1:1.2 (config #1, interface 2)
>> [ 301.056934] uvcvideo 1-1:1.2: usb_probe_interface
>> [ 301.058072] uvcvideo 1-1:1.2: usb_probe_interface - got id
>> [ 301.059395] uvcvideo: Found UVC 1.00 device <unnamed> (046d:081d)
>> [ 301.090173] input: UVC Camera (046d:081d) as /devices/pci0000:00/0000:00:1f.5/usb1/1-1/1-1:1.2/input/input7
>
> That seems to be a Logitech model.
>
>> [ 301.111289] usb 1-1: adding 1-1:1.3 (config #1, interface 3)
>> [ 301.131207] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us]
>> [ 301.137066] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us]
>> [ 301.156451] ehci_hcd 0000:00:1f.5: reused qh f48d64c0 schedule
>> [ 301.158310] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us]
>> [ 301.160238] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us]
>> [ 301.196606] set resolution quirk: cval->res = 384
>> [ 371.309569] e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
>> [ 390.729568] ehci_hcd 0000:00:1f.5: reused qh f48d64c0 schedule
>> f5ade900 2296555[ 390.730023] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us]
>> 437 S Ii:1:003:7[ 390.736394] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us]
>> -115:128 16 <
>> f5ade900 2296566256 C Ii:1:003:7 -2:128 0
>> [ 391.100896] ehci_hcd 0000:00:1f.5: reused qh f48d64c0 schedule
>> [ 391.103188] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us]
>> f5ade900 2296926929 S Ii:1:003:7[ 391.104889] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us]
>> -115:128 16 <
>> f5ade900 2296937889 C Ii:1:003:7 -2:128 0
>> f5272300 2310382508 S Co:1:003:0 s 01 0b 0004 0001 0000 0
>> f5272300 2310407888 C Co:1:003:0 0 0
>> f5272300 2310408051 S Co:1:003:0 s 22 01 0100 0086 0003 3 = 80bb00
>> f5272300 2310412456 C Co:1:003:0 0 3 >
>> f5272300 2310412521 S Ci:1:003:0 s a2 81 0100 0086 0003 3 <
>> f5272300 2310415909 C Ci:1:003:0 0 0
>> f5272300 2310418133 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 <
>> f5272600 2310418219 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 <
>> f52720c0 2310418239 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 <
>> f5272a80 2310418247 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 <
>> f5272480 2310418256 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 <
>> f52723c0 2310418264 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 <
>> f5272d80 2310418272 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 <
>> f5272b40 2310418280 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 <
[...]
> I tried Chrome 22 on Ubuntu with a cheap Logitech USB webcam (different
> product ID than yours, though) under 3.6.0 and 3.6.2, and I can't
> reproduce the issue.
FWIW, I also tried Chrome 22 and Firefox 16 with kernel version 3.5.4
and 3.6.2 on Fedora 17 and everything worked as expected (with both an
external and the built-in webcam of a T420). Cheese and arecord also
work on all kernel versions and distributions I have tested so far.
So whatever causes your trouble, I assume it's rather specific to your
machine configuration and setup. More information is needed here.
Daniel
^ permalink raw reply
* Re: 3.5 bridging regression
From: Eric Dumazet @ 2012-10-21 11:53 UTC (permalink / raw)
To: Willy Tarreau; +Cc: Eric Dumazet, netdev
In-Reply-To: <20121021112727.GF21937@1wt.eu>
On Sun, 2012-10-21 at 13:27 +0200, Willy Tarreau wrote:
> Hi Eric,
>
> Since 3.5, I was getting very quick panic when setting up a bridge
> on my guruplug (dual-gig equipped ARM system). This week-end I could
> bisect the issue and found that it is this patch which introduced the
> issue :
>
> a1c7fff7e18f59e684e07b0f9a770561cd39f395 net: netdev_alloc_skb() use build_skb()
>
> I can reliably reproduce the issue by installing my laptop behind this
> bridge and running "find" on an NFS mount. I don't understand why this
> patch can cause this, I was thinking that maybe we free the same page
> twice or something like this but I don't see any such thing there.
>
> I set up the bridge using this script :
>
> brctl addbr br0
> brctl addif br0 eth0
> brctl addif br0 eth1
> ip a f dev eth0
> ip a f dev eth1
> ip li set eth0 up
> ip li set eth1 up
> ip li set br0 up
>
> The network driver is mv643xx. I don't know if this is important, but
> since this issue is still present in 3.6.2 and nobody has yet reported
> a panic on bridge, I suspect that it may contribute to the issue.
Hello Willy
This is most probably the needed fix.
I guess David planned to send it to stable teams if not already done.
commit acb600def2110b1310466c0e485c0d26299898ae
Author: Eric Dumazet <edumazet@google.com>
Date: Fri Oct 5 06:23:55 2012 +0000
net: remove skb recycling
Over time, skb recycling infrastructure got litle interest and
many bugs. Generic rx path skb allocation is now using page
fragments for efficient GRO / TCP coalescing, and recyling
a tx skb for rx path is not worth the pain.
Last identified bug is that fat skbs can be recycled
and it can endup using high order pages after few iterations.
With help from Maxime Bizon, who pointed out that commit
87151b8689d (net: allow pskb_expand_head() to get maximum tailroom)
introduced this regression for recycled skbs.
Instead of fixing this bug, lets remove skb recycling.
Drivers wanting really hot skbs should use build_skb() anyway,
to allocate/populate sk_buff right before netif_receive_skb()
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Maxime Bizon <mbizon@freebox.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* 3.5 bridging regression
From: Willy Tarreau @ 2012-10-21 11:27 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
[-- Attachment #1: Type: text/plain, Size: 4372 bytes --]
Hi Eric,
Since 3.5, I was getting very quick panic when setting up a bridge
on my guruplug (dual-gig equipped ARM system). This week-end I could
bisect the issue and found that it is this patch which introduced the
issue :
a1c7fff7e18f59e684e07b0f9a770561cd39f395 net: netdev_alloc_skb() use build_skb()
I can reliably reproduce the issue by installing my laptop behind this
bridge and running "find" on an NFS mount. I don't understand why this
patch can cause this, I was thinking that maybe we free the same page
twice or something like this but I don't see any such thing there.
I set up the bridge using this script :
brctl addbr br0
brctl addif br0 eth0
brctl addif br0 eth1
ip a f dev eth0
ip a f dev eth1
ip li set eth0 up
ip li set eth1 up
ip li set br0 up
The network driver is mv643xx. I don't know if this is important, but
since this issue is still present in 3.6.2 and nobody has yet reported
a panic on bridge, I suspect that it may contribute to the issue.
I'm also the config (only non-disabled options), I could strip it down
enough to reduce the possibilities. This config causes the panic with
the patch and does not without. I don't know what else to look for,
I'm open to any idea you might have.
The panic looks like this :
------------[ cut here ]------------
kernel BUG at mm/slab.c:505!
Internal error: Oops - BUG: 0 [#1] ARM
Modules linked in:
CPU: 0 Not tainted (3.5.0-fail #17)
PC is at kfree+0x8c/0xa8
LR is at __kfree_skb+0x14/0xc8
pc : [<8008bee8>] lr : [<801bad84>] psr: 40000093
sp : 8035fe08 ip : 00000000 fp : ffdf8480
r10: 803691a8 r9 : 00f82802 r8 : 80403900
r7 : 00000001 r6 : a0000013 r5 : 9fb776e0 r4 : 8040b000
r3 : 80801ee0 r2 : 00000000 r1 : 00000000 r0 : 00000000
Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 0005397f Table: 1f074000 DAC: 00000017
Process swapper (pid: 0, stack limit = 0x8035e270)
Stack: (0x8035fe08 to 0x80360000)
fe00: 9fb749e0 9fb749e0 9f9b0400 801bad84 9f9b1918 801aa740
fe20: 807ed620 00000010 00000000 9f96e400 00000002 9f9b0400 00000000 9f9b1918
fe40: 00000038 803804e0 00000000 00000000 00000001 801ab1c8 622af000 ffffffff
fe60: 0000001d 00000080 00000010 00001514 9f9b04d4 001312cf af6a5400 ffffffff
fe80: 00000000 00989680 001e8480 801aaef8 9f9b04d4 00000080 0000012c 803804e0
fea0: 803804e8 8036f1f0 ffff91f1 801c61bc 00000000 803804e0 00000000 00000001
fec0: 8040166c 8035e000 00000100 80401660 80370138 80401640 0000000a 80024cbc
fee0: 00000000 80370e88 0000000f 00000003 8035ff64 8035e000 0000000f 00000000
ff00: 8035ff64 00000000 56251311 8036b1f8 00000000 800250e8 8037608c 8000fd90
ff20: 801b1150 20000013 fed20200 8000eaf4 8035ff78 20000013 0002dffa 00000004
ff40: 3e957f9a 00000004 8036b470 00000000 00000000 56251311 8036b1f8 00000000
ff60: 9fffffae 8035ff78 80044de0 801b1150 20000013 ffffffff 3e985f94 00000004
ff80: 00000000 8035e000 00000000 00000000 00000000 8036b470 804070e8 8036b1f8
ffa0: 003592b0 801b0f74 8035e000 803806c8 80369e54 80369e4c 00004000 800100c8
ffc0: 80366108 8035a678 8080c0c0 80340738 00000000 00000000 803401d4 00000000
ffe0: 00000000 8035a678 00053975 80366044 8035a674 00008040 00000000 00000000
[<8008bee8>] (kfree+0x8c/0xa8) from [<801bad84>] (__kfree_skb+0x14/0xc8)
[<801bad84>] (__kfree_skb+0x14/0xc8) from [<801aa740>] (txq_reclaim+0x198/0x244)
[<801aa740>] (txq_reclaim+0x198/0x244) from [<801ab1c8>] (mv643xx_eth_poll+0x2d0/0x71c)
[<801ab1c8>] (mv643xx_eth_poll+0x2d0/0x71c) from [<801c61bc>] (net_rx_action+0xb0/0x188)
[<801c61bc>] (net_rx_action+0xb0/0x188) from [<80024cbc>] (__do_softirq+0x90/0x120)
[<80024cbc>] (__do_softirq+0x90/0x120) from [<800250e8>] (irq_exit+0x7c/0x84)
[<800250e8>] (irq_exit+0x7c/0x84) from [<8000fd90>] (handle_IRQ+0x34/0x84)
[<8000fd90>] (handle_IRQ+0x34/0x84) from [<8000eaf4>] (__irq_svc+0x34/0x80)
[<8000eaf4>] (__irq_svc+0x34/0x80) from [<801b1150>] (cpuidle_wrap_enter+0x54/0x9c)
[<801b1150>] (cpuidle_wrap_enter+0x54/0x9c) from [<801b0f74>] (cpuidle_idle_call+0x9c/0x130)
[<801b0f74>] (cpuidle_idle_call+0x9c/0x130) from [<800100c8>] (cpu_idle+0x88/0xd4)
[<800100c8>] (cpu_idle+0x88/0xd4) from [<80340738>] (start_kernel+0x298/0x2ec)
Code: e7845101 e5840000 e121f006 e8bd8070 (e7f001f2)
---[ end trace 879b0e636889a6d4 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 1 seconds..
Thanks,
Willy
[-- Attachment #2: config-arm-crash.txt --]
[-- Type: text/plain, Size: 8312 bytes --]
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_GENERIC_GPIO=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_KTIME_SCALAR=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_VECTORS_BASE=0xffff0000
CONFIG_ARM_PATCH_PHYS_VIRT=y
CONFIG_NEED_MACH_IO_H=y
CONFIG_GENERIC_BUG=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_HAVE_IRQ_WORK=y
CONFIG_IRQ_WORK=y
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
CONFIG_DEFAULT_HOSTNAME="dockstar"
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_HAVE_GENERIC_HARDIRQS=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_TINY_RCU=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=19
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_LZO=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_EXPERT=y
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_EMBEDDED=y
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y
CONFIG_PERF_EVENTS=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_COMPAT_BRK=y
CONFIG_SLAB=y
CONFIG_PROFILING=y
CONFIG_HAVE_OPROFILE=y
CONFIG_JUMP_LABEL=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_BLOCK=y
CONFIG_LBDAF=y
CONFIG_BLK_DEV_BSG=y
CONFIG_MSDOS_PARTITION=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_CFQ=y
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
CONFIG_INLINE_READ_UNLOCK=y
CONFIG_INLINE_READ_UNLOCK_IRQ=y
CONFIG_INLINE_WRITE_UNLOCK=y
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
CONFIG_MMU=y
CONFIG_ARCH_KIRKWOOD=y
CONFIG_MACH_GURUPLUG=y
CONFIG_MACH_DOCKSTAR=y
CONFIG_PLAT_ORION=y
CONFIG_CPU_FEROCEON=y
CONFIG_CPU_32v5=y
CONFIG_CPU_ABRT_EV5T=y
CONFIG_CPU_PABRT_LEGACY=y
CONFIG_CPU_CACHE_VIVT=y
CONFIG_CPU_COPY_FEROCEON=y
CONFIG_CPU_TLB_FEROCEON=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y
CONFIG_CPU_USE_DOMAINS=y
CONFIG_OUTER_CACHE=y
CONFIG_CACHE_FEROCEON_L2=y
CONFIG_ARM_L1_CACHE_SHIFT=5
CONFIG_ARM_NR_BANKS=8
CONFIG_PCI=y
CONFIG_PCI_SYSCALL=y
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_VMSPLIT_2G=y
CONFIG_PAGE_OFFSET=0x80000000
CONFIG_ARCH_NR_GPIO=0
CONFIG_PREEMPT_NONE=y
CONFIG_HZ=100
CONFIG_AEABI=y
CONFIG_OABI_COMPAT=y
CONFIG_HAVE_ARCH_PFN_VALID=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=999999
CONFIG_ZONE_DMA_FLAG=0
CONFIG_VIRT_TO_BUS=y
CONFIG_DEFAULT_MMAP_MIN_ADDR=32768
CONFIG_NEED_PER_CPU_KM=y
CONFIG_FORCE_MAX_ZONEORDER=11
CONFIG_ALIGNMENT_TRAP=y
CONFIG_UACCESS_WITH_MEMCPY=y
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_CMDLINE=""
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y
CONFIG_FPE_NWFPE=y
CONFIG_FPE_FASTFPE=y
CONFIG_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
CONFIG_HAVE_AOUT=y
CONFIG_PM_RUNTIME=y
CONFIG_PM=y
CONFIG_CPU_PM=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
CONFIG_UNIX_DIAG=y
CONFIG_XFRM=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_NET_IPIP=y
CONFIG_SYN_COOKIES=y
CONFIG_INET_TUNNEL=y
CONFIG_INET_LRO=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
CONFIG_INET_UDP_DIAG=y
CONFIG_TCP_CONG_ADVANCED=y
CONFIG_TCP_CONG_BIC=y
CONFIG_TCP_CONG_CUBIC=y
CONFIG_TCP_CONG_HTCP=y
CONFIG_TCP_CONG_HYBLA=y
CONFIG_TCP_CONG_VEGAS=y
CONFIG_DEFAULT_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
CONFIG_IPV6=y
CONFIG_INET6_XFRM_MODE_TRANSPORT=y
CONFIG_INET6_XFRM_MODE_TUNNEL=y
CONFIG_INET6_XFRM_MODE_BEET=y
CONFIG_IPV6_SIT=y
CONFIG_IPV6_NDISC_NODETYPE=y
CONFIG_NETFILTER=y
CONFIG_NETFILTER_ADVANCED=y
CONFIG_BRIDGE_NETFILTER=y
CONFIG_STP=y
CONFIG_BRIDGE=y
CONFIG_VLAN_8021Q=y
CONFIG_LLC=y
CONFIG_NET_SCHED=y
CONFIG_NET_CLS=y
CONFIG_NET_EMATCH=y
CONFIG_NET_EMATCH_STACK=32
CONFIG_NET_CLS_ACT=y
CONFIG_NET_SCH_FIFO=y
CONFIG_BQL=y
CONFIG_HAVE_BPF_JIT=y
CONFIG_BPF_JIT=y
CONFIG_FIB_RULES=y
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
CONFIG_MTD=y
CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_CFI=y
CONFIG_MTD_JEDECPROBE=y
CONFIG_MTD_GEN_PROBE=y
CONFIG_MTD_CFI_ADV_OPTIONS=y
CONFIG_MTD_CFI_NOSWAP=y
CONFIG_MTD_CFI_GEOMETRY=y
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_CFI_STAA=y
CONFIG_MTD_CFI_UTIL=y
CONFIG_MTD_PHYSMAP=y
CONFIG_MTD_NAND_ECC=y
CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_IDS=y
CONFIG_MTD_NAND_ORION=y
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_RESERVE=1
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=16384
CONFIG_HAVE_IDE=y
CONFIG_SCSI_MOD=y
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
CONFIG_MII=y
CONFIG_TUN=y
CONFIG_ETHERNET=y
CONFIG_NET_VENDOR_MARVELL=y
CONFIG_MV643XX_ETH=y
CONFIG_PHYLIB=y
CONFIG_MARVELL_PHY=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=16
CONFIG_DEVKMEM=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=2
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_DEVPORT=y
CONFIG_ARCH_REQUIRE_GPIOLIB=y
CONFIG_GPIOLIB=y
CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_GENERIC=y
CONFIG_GPIO_GENERIC_PLATFORM=y
CONFIG_SSB_POSSIBLE=y
CONFIG_BCMA_POSSIBLE=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB_ARCH_HAS_XHCI=y
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
CONFIG_RTC_DRV_MV=y
CONFIG_DMADEVICES=y
CONFIG_ASYNC_TX_ENABLE_CHANNEL_SWITCH=y
CONFIG_MV_XOR=y
CONFIG_DMA_ENGINE=y
CONFIG_STAGING=y
CONFIG_CLKSRC_MMIO=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_CONFIGFS_FS=y
CONFIG_MISC_FILESYSTEMS=y
CONFIG_UBIFS_FS=y
CONFIG_UBIFS_FS_LZO=y
CONFIG_UBIFS_FS_ZLIB=y
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
CONFIG_FRAME_WARN=1024
CONFIG_MAGIC_SYSRQ=y
CONFIG_STRIP_ASM_SYMS=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACING_SUPPORT=y
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_ARM_UNWIND=y
CONFIG_DEBUG_USER=y
CONFIG_DEBUG_LL=y
CONFIG_DEBUG_LL_UART_NONE=y
CONFIG_EARLY_PRINTK=y
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRYPTO_LZO=y
CONFIG_BITREVERSE=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IO=y
CONFIG_CRC16=y
CONFIG_CRC32=y
CONFIG_CRC32_SLICEBY8=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_LZO=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_GENERIC_ATOMIC64=y
^ permalink raw reply
* Re: [PATCH 3/6] drivers: net: ethernet: cpsw: add multicast address to ALE table
From: Richard Cochran @ 2012-10-21 11:26 UTC (permalink / raw)
To: Mugunthan V N; +Cc: netdev, davem
In-Reply-To: <1350427518-7230-4-git-send-email-mugunthanvnm@ti.com>
On Wed, Oct 17, 2012 at 04:15:15AM +0530, Mugunthan V N wrote:
> @@ -271,6 +273,30 @@ struct cpsw_priv {
> (func)((priv)->slaves + idx, ##arg); \
> } while (0)
>
> +static void cpsw_ndo_set_rx_mode(struct net_device *ndev)
> +{
> + struct cpsw_priv *priv = netdev_priv(ndev);
> +
> + if (ndev->flags & IFF_PROMISC) {
> + /* Enable promiscuous mode */
> + dev_err(priv->dev, "Ignoring Promiscuous mode\n");
> + return;
Why can't we support promiscuous mode here?
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH net-next V2] htb: improved accuracy at high rates
From: Eric Dumazet @ 2012-10-21 11:17 UTC (permalink / raw)
To: Vimalkumar; +Cc: davem, Jamal Hadi Salim, netdev
In-Reply-To: <1350817787.13333.1949.camel@edumazet-glaptop>
On Sun, 2012-10-21 at 13:09 +0200, Eric Dumazet wrote:
> Take your time, so that other people dont loose their time.
I meant 'dont lose their time', oh well ;)
^ permalink raw reply
* Re: [PATCH net-next V2] htb: improved accuracy at high rates
From: Eric Dumazet @ 2012-10-21 11:09 UTC (permalink / raw)
To: Vimalkumar; +Cc: davem, Jamal Hadi Salim, netdev
In-Reply-To: <1350751116-70056-1-git-send-email-j.vimal@gmail.com>
On Sat, 2012-10-20 at 09:38 -0700, Vimalkumar wrote:
> Current HTB (and TBF) uses rate table computed by the "tc"
> userspace program, which has the following issue:
>
> The rate table has 256 entries to map packet lengths
> to token (time units). With TSO sized packets, the
> 256 entry granularity leads to loss/gain of rate,
> making the token bucket inaccurate.
>
> Thus, instead of relying on rate table, this patch
> explicitly computes the time and accounts for packet
> transmission times with nanosecond granularity.
>
> This greatly improves accuracy of HTB with a wide
> range of packet sizes.
>
> Example:
>
> tc qdisc add dev $dev root handle 1: \
> htb default 1
>
> tc class add dev $dev classid 1:1 parent 1: \
> rate 5Gbit mtu 64k
>
> Here is an example of inaccuracy:
>
> $ iperf -c host -t 10 -i 1
>
> With old htb:
> eth4: 34.76 Mb/s In 5827.98 Mb/s Out - 65836.0 p/s In 481273.0 p/s Out
> [SUM] 9.0-10.0 sec 669 MBytes 5.61 Gbits/sec
> [SUM] 0.0-10.0 sec 6.50 GBytes 5.58 Gbits/sec
>
> With new htb:
> eth4: 28.36 Mb/s In 5208.06 Mb/s Out - 53704.0 p/s In 430076.0 p/s Out
> [SUM] 9.0-10.0 sec 594 MBytes 4.98 Gbits/sec
> [SUM] 0.0-10.0 sec 5.80 GBytes 4.98 Gbits/sec
>
> The bits per second on the wire is still 5200Mb/s with new HTB
> because qdisc accounts for packet length using skb->len, which
> is smaller than total bytes on the wire if GSO is used. But
> that is for another patch regardless of how time is accounted.
>
> Many thanks to Eric Dumazet for review and feedback.
>
> Signed-off-by: Vimalkumar <j.vimal@gmail.com>
> ---
> net/sched/sch_htb.c | 123 +++++++++++++++++++++++++++++++++------------------
> 1 files changed, 80 insertions(+), 43 deletions(-)
>
> diff --git a/net/sched/sch_htb.c b/net/sched/sch_htb.c
> index 9d75b77..1f26d6b 100644
> --- a/net/sched/sch_htb.c
> +++ b/net/sched/sch_htb.c
> @@ -55,6 +55,7 @@
>
> static int htb_hysteresis __read_mostly = 0; /* whether to use mode hysteresis for speedup */
> #define HTB_VER 0x30011 /* major must be matched with number suplied by TC as version */
> +#define HTB_MIN_PKT_BYTES (64)
This is not used in your patch.
is htb_precompute_ratedata() safe/correct for very low speeds, as 8000
bits/sec ?
If my maths are correct, there is an overflow.
factor = 8LLU * NSEC_PER_SEC * (1 << r->shift);
so factor = 262144000000000
r->mult = div64_u64(factor, r->rate_bps);
the result of the divide is 32768000000, and its bigger than an u32
So you should have a loop to reduce r->shift to make sure you dont have
an overflow for r->mult
> - if (nla_put(skb, TCA_HTB_INIT, sizeof(gopt), &gopt))
> - goto nla_put_failure;
> + NLA_PUT(skb, TCA_HTB_INIT, sizeof(gopt), &gopt);
> nla_nest_end(skb, nest);
...
> - if (nla_put(skb, TCA_HTB_PARMS, sizeof(opt), &opt))
> - goto nla_put_failure;
> + NLA_PUT(skb, TCA_HTB_PARMS, sizeof(opt), &opt);
Thats unfortunate, you apparently didnt compile your module and tested
it.
# make net/sched/sch_htb.ko
make[1]: Nothing to be done for `all'.
make[1]: Nothing to be done for `relocs'.
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CALL scripts/checksyscalls.sh
CC [M] net/sched/sch_htb.o
net/sched/sch_htb.c: In function ‘htb_dump’:
net/sched/sch_htb.c:1092: error: implicit declaration of function
‘NLA_PUT’
make[1]: *** [net/sched/sch_htb.o] Error 1
make: *** [net/sched/sch_htb.ko] Error 2
You should understand this is an absolute requirement, or else people
are less likely to take a serious look at your work.
So triple check next time you submit.
Read again Documentation/SubmitChecklist
Take your time, so that other people dont loose their time.
Thanks
PS : Documentation/SubmittingPatches
10) Don't get discouraged. Re-submit.
^ permalink raw reply
* Re: Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
From: Borislav Petkov @ 2012-10-21 11:08 UTC (permalink / raw)
To: Artem S. Tashkinov
Cc: pavel, linux-kernel, netdev, security, linux-media, linux-usb
In-Reply-To: <1798605268.19162.1350784641831.JavaMail.mail@webmail17>
On Sun, Oct 21, 2012 at 01:57:21AM +0000, Artem S. Tashkinov wrote:
> The freeze happens on my *host* Linux PC. For an experiment I decided
> to check if I could reproduce the freeze under a virtual machine - it
> turns out the Linux kernel running under it also freezes.
I know that - but a freeze != oops - at least not necessarily. Which
means it could very well be a different issue now that vbox is gone.
Or, it could be the same issue with different incarnations: with vbox
you get the corruptions and without it, you get the freezes. I'm
assuming you do the same flash player thing in both cases?
Here's a crazy idea: can you try to reproduce it in KVM?
Thanks.
--
Regards/Gruss,
Boris.
^ permalink raw reply
* Re: IPV6_RECVPKTINFO fix
From: Michael Kerrisk (man-pages) @ 2012-10-21 11:05 UTC (permalink / raw)
To: bert hubert
Cc: linux-man-u79uwXL29TY76Z2rM5mHXA, YOSHIFUJI Hideaki,
Yang Hongyang, netdev
In-Reply-To: <20121009130632.GA16787-UEKwcDob1UlZy7985ye5QA@public.gmane.org>
Hello Bert,
On Tue, Oct 9, 2012 at 3:06 PM, bert hubert <bert.hubert-dxZxOz86jR8sYtaaK7K+xw@public.gmane.org> wrote:
> Hi everybody,
>
> Recently PowerDNS needed to support the getting of the original destination
> address of packets received on ::. Following the advice in ipv6(7) generated
> an error on setsockopt().
>
> Some googling confirmed that setsockopt() with IPV6_PKTINFO indeed does not
> work, but we found that IPV6_RECVPKTINFO did.
>
> Our experiences are detailed in
> http://bert-hubert.blogspot.nl/2012/10/on-binding-datagram-udp-sockets-to-any.html
>
> Please find attached a quite naive patch to ipv6.7 that at least fixes 'my'
> problem, but does not document if IPV6_PKTINFO ever worked as a flag. It
> does document that IPV6_RECVPKTINFO is available since 2.6.13.
>
> Please let me know if this patch is acceptable, or if you want me to dig
> deeper into the IPV6_PKTINFO situation.
So, the kernel commit 333fad5364d6b457c8d837f7d05802d2aaf8a961 (Sep
2005) does this:
=====
-#define IPV6_PKTINFO 2
-#define IPV6_HOPOPTS 3
-#define IPV6_DSTOPTS 4
-#define IPV6_RTHDR 5
-#define IPV6_PKTOPTIONS 6
+#define IPV6_2292PKTINFO 2
+#define IPV6_2292HOPOPTS 3
+#define IPV6_2292DSTOPTS 4
+#define IPV6_2292RTHDR 5
+#define IPV6_2292PKTOPTIONS 6
...
+/* RFC3542 advanced socket options (50-67) */
+#define IPV6_RECVPKTINFO 50
+#define IPV6_PKTINFO 51
...
+#define IPV6_RECVHOPOPTS 56
+#define IPV6_HOPOPTS 57
#define IPV6_CHECKSUM 7
-#define IPV6_HOPLIMIT 8
+#define IPV6_2292HOPLIMIT 8
...
+#define IPV6_RTHDRDSTOPTS 59
+#define IPV6_RECVRTHDR 60
+#define IPV6_RTHDR 61
+#define IPV6_RECVDSTOPTS 62
+#define IPV6_DSTOPTS 63
+#define IPV6_RECVHOPLIMIT 64
+#define IPV6_HOPLIMIT 65
=====
Looking more closely (i.e., beyond just the above), the summary is
that IPV6_PKTINFO disappeared from the getsockopt/setsockopt API, and
IPV6_2292PKTINFO took its place. Meanwhile, IPV6_RECVPKTINFO was
added.
Then kernel commit b24a2516d10751d7ed5afb58420df25370c9dffb (Dec 2008)
added IPV6_PKTINFO back to the getsockopt/getsockopt API, but with
what looks to be a rather different meaning (it takes a 'struct
in6_pktinfo' as the third arg).
This seems consistent (if confusing) with the RFCs:
http://www.ietf.org/rfc/rfc2292.txt
http://www.ietf.org/rfc/rfc3542.txt (obsoletes 2292)
Both of those RFCs define an IPV6_PKTINO sockopt, but the former takes
an int arg, and the latter takes the 'struct in6_pktinfo'.
So, my summary of your patch is that it's correct. But I think that
IPV6_RECVPKTINFO is present since 2.6.14, not 2.6.13, and I tweaked
your patch (see below).
But it'd be great if the netdev folk in general could send in
documentation patches, or at least CC linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, for
future API changes.
Cheers,
Michael
--- a/man7/ipv6.7
+++ b/man7/ipv6.7
@@ -141,7 +141,7 @@ structure.
.\" FIXME IPV6_CHECKSUM is not documented, and probably should be
.\" FIXME IPV6_JOIN_ANYCAST is not documented, and probably should be
.\" FIXME IPV6_LEAVE_ANYCAST is not documented, and probably should be
-.\" FIXME IPV6_RECVPKTINFO is not documented, and probably should be
+.\" FIXME IPV6_PKTINFO is not documented, and probably should be
.\" FIXME IPV6_2292PKTINFO is not documented, and probably should be
.\" FIXME there are probably many other IPV6_* socket options that
.\" should be documented
@@ -183,10 +183,11 @@ in an integer.
Control whether the socket sees multicast packets that it has send itself.
Argument is a pointer to boolean.
.TP
-.B IPV6_PKTINFO
+.BR IPV6_RECVPKTINFO " (since Linux 2.6.14)"
Set delivery of the
.B IPV6_PKTINFO
control message on incoming datagrams.
+Such control messages contain a struct in6_pktinfo, as per RFC 3542.
Only allowed for
.B SOCK_DGRAM
or
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 4/5] ath6kl/wmi.c: eliminate possible double free
From: Julia Lawall @ 2012-10-21 10:52 UTC (permalink / raw)
To: Kalle Valo
Cc: kernel-janitors, John W. Linville, linux-wireless, netdev,
linux-kernel
In-Reply-To: <1350816727-1381-1-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
This makes two changes. In ath6kl_wmi_cmd_send, a call to dev_kfree_skb on
the skb argument is added to the initial sanity check to more completely
establish the invariant that ath6kl_wmi_cmd_send owns its skb argument.
Then, in ath6kl_wmi_sync_point, on failure of the call to
ath6kl_wmi_cmd_send, the clearing of the local skb variable is moved up, so
that the error-handling code at the end of the function does not free it
again.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@r@
identifier f,free,a;
parameter list[n] ps;
type T;
expression e;
@@
f(ps,T a,...) {
... when any
when != a = e
if(...) { ... free(a); ... return ...; }
... when any
}
@@
identifier r.f,r.free;
expression x,a;
expression list[r.n] xs;
@@
* x = f(xs,a,...);
if (...) { ... free(a); ... return ...; }
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
Not tested.
drivers/net/wireless/ath/ath6kl/wmi.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/wmi.c b/drivers/net/wireless/ath/ath6kl/wmi.c
index c30ab4b..50f50e4 100644
--- a/drivers/net/wireless/ath/ath6kl/wmi.c
+++ b/drivers/net/wireless/ath/ath6kl/wmi.c
@@ -1677,8 +1677,10 @@ int ath6kl_wmi_cmd_send(struct wmi *wmi, u8 if_idx, struct sk_buff *skb,
int ret;
u16 info1;
- if (WARN_ON(skb == NULL || (if_idx > (wmi->parent_dev->vif_max - 1))))
+ if (WARN_ON(skb == NULL || if_idx > (wmi->parent_dev->vif_max - 1))) {
+ dev_kfree_skb(skb);
return -EINVAL;
+ }
ath6kl_dbg(ATH6KL_DBG_WMI, "wmi tx id %d len %d flag %d\n",
cmd_id, skb->len, sync_flag);
@@ -2348,12 +2350,12 @@ static int ath6kl_wmi_sync_point(struct wmi *wmi, u8 if_idx)
ret = ath6kl_wmi_cmd_send(wmi, if_idx, skb, WMI_SYNCHRONIZE_CMDID,
NO_SYNC_WMIFLAG);
- if (ret)
- goto free_skb;
-
/* cmd buffer sent, we no longer own it */
skb = NULL;
+ if (ret)
+ goto free_skb;
+
for (index = 0; index < num_pri_streams; index++) {
if (WARN_ON(!data_sync_bufs[index].skb))
^ permalink raw reply related
* [PATCH 2/5] drivers/net/wireless/ti/wlcore/main.c: eliminate possible double power off
From: Julia Lawall @ 2012-10-21 10:52 UTC (permalink / raw)
To: Luciano Coelho
Cc: kernel-janitors, John W. Linville, linux-wireless, netdev,
linux-kernel
In-Reply-To: <1350816727-1381-1-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
The function wl12xx_set_power_on is only called twice, once in
wl12xx_chip_wakeup and once in wl12xx_get_hw_info. On the failure of the
call in wl12xx_chip_wakeup, the containing function just returns, but on
the failure of the call in wl12xx_get_hw_info, the containing function
calls wl1271_power_off. This does not seem necessary, because if
wl12xx_set_power_on has set the power on and then fails, it has already
turned the power off.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@r@
identifier f,free,a;
parameter list[n] ps;
type T;
expression e;
@@
f(ps,T a,...) {
... when any
when != a = e
if(...) { ... free(a); ... return ...; }
... when any
}
@@
identifier r.f,r.free;
expression x,a;
expression list[r.n] xs;
@@
* x = f(xs,a,...);
if (...) { ... free(a); ... return ...; }
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
wl1271_power_off seems to be resistent to being called when the power is
not on, so this should not change the behavior. Not tested.
drivers/net/wireless/ti/wlcore/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index 25530c8..0eb739b 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -5116,7 +5116,7 @@ static int wl12xx_get_hw_info(struct wl1271 *wl)
ret = wl12xx_set_power_on(wl);
if (ret < 0)
- goto out;
+ return ret;
ret = wlcore_read_reg(wl, REG_CHIP_ID_B, &wl->chip.id);
if (ret < 0)
^ permalink raw reply related
* Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
From: Daniel Mack @ 2012-10-21 10:34 UTC (permalink / raw)
To: Artem S. Tashkinov
Cc: bp, pavel, linux-kernel, netdev, security, linux-media, linux-usb
In-Reply-To: <1781795634.31179.1350774917965.JavaMail.mail@webmail04>
On 21.10.2012 01:15, Artem S. Tashkinov wrote:
> You don't get me - I have *no* VirtualBox (or any proprietary) modules running
> - but I can reproduce this problem using *the same system running under* VirtualBox
> in Windows 7 64.
>
> It's almost definitely either a USB driver bug or video4linux driver bug:
>
> I'm CC'ing linux-media and linux-usb mailing lists, the problem is described here:
> https://lkml.org/lkml/2012/10/20/35
> https://lkml.org/lkml/2012/10/20/148
>
> Here are the last lines from my dmesg (with usbmon loaded):
>
> [ 292.164833] hub 1-0:1.0: state 7 ports 8 chg 0000 evt 0002
> [ 292.168091] ehci_hcd 0000:00:1f.5: GetStatus port:1 status 00100a 0 ACK POWER sig=se0 PEC CSC
> [ 292.172063] hub 1-0:1.0: port 1, status 0100, change 0003, 12 Mb/s
> [ 292.174883] usb 1-1: USB disconnect, device number 2
> [ 292.178045] usb 1-1: unregistering device
> [ 292.183539] usb 1-1: unregistering interface 1-1:1.0
> [ 292.197034] usb 1-1: unregistering interface 1-1:1.1
> [ 292.204317] usb 1-1: unregistering interface 1-1:1.2
> [ 292.234519] usb 1-1: unregistering interface 1-1:1.3
> [ 292.236175] usb 1-1: usb_disable_device nuking all URBs
> [ 292.364429] hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x100
> [ 294.364279] hub 1-0:1.0: hub_suspend
> [ 294.366045] usb usb1: bus auto-suspend, wakeup 1
> [ 294.367375] ehci_hcd 0000:00:1f.5: suspend root hub
> [ 296.501084] usb usb1: usb wakeup-resume
> [ 296.508311] usb usb1: usb auto-resume
> [ 296.509833] ehci_hcd 0000:00:1f.5: resume root hub
> [ 296.560149] hub 1-0:1.0: hub_resume
> [ 296.562240] ehci_hcd 0000:00:1f.5: GetStatus port:1 status 001003 0 ACK POWER sig=se0 CSC CONNECT
> [ 296.566141] hub 1-0:1.0: port 1: status 0501 change 0001
> [ 296.670413] hub 1-0:1.0: state 7 ports 8 chg 0002 evt 0000
> [ 296.673222] hub 1-0:1.0: port 1, status 0501, change 0000, 480 Mb/s
> [ 297.311720] usb 1-1: new high-speed USB device number 3 using ehci_hcd
> [ 300.547237] usb 1-1: skipped 1 descriptor after configuration
> [ 300.549443] usb 1-1: skipped 4 descriptors after interface
> [ 300.552273] usb 1-1: skipped 2 descriptors after interface
> [ 300.556499] usb 1-1: skipped 1 descriptor after endpoint
> [ 300.559392] usb 1-1: skipped 2 descriptors after interface
> [ 300.560960] usb 1-1: skipped 1 descriptor after endpoint
> [ 300.562169] usb 1-1: skipped 2 descriptors after interface
> [ 300.563440] usb 1-1: skipped 1 descriptor after endpoint
> [ 300.564639] usb 1-1: skipped 2 descriptors after interface
> [ 300.565828] usb 1-1: skipped 2 descriptors after endpoint
> [ 300.567084] usb 1-1: skipped 9 descriptors after interface
> [ 300.569205] usb 1-1: skipped 1 descriptor after endpoint
> [ 300.570484] usb 1-1: skipped 53 descriptors after interface
> [ 300.595843] usb 1-1: default language 0x0409
> [ 300.602503] usb 1-1: USB interface quirks for this device: 2
> [ 300.605700] usb 1-1: udev 3, busnum 1, minor = 2
> [ 300.606959] usb 1-1: New USB device found, idVendor=046d, idProduct=081d
> [ 300.610298] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=1
> [ 300.613742] usb 1-1: SerialNumber: 48C5D2B0
> [ 300.617703] usb 1-1: usb_probe_device
> [ 300.620594] usb 1-1: configuration #1 chosen from 1 choice
> [ 300.639218] usb 1-1: adding 1-1:1.0 (config #1, interface 0)
> [ 300.640736] snd-usb-audio 1-1:1.0: usb_probe_interface
> [ 300.642307] snd-usb-audio 1-1:1.0: usb_probe_interface - got id
> [ 301.050296] usb 1-1: adding 1-1:1.1 (config #1, interface 1)
> [ 301.054897] usb 1-1: adding 1-1:1.2 (config #1, interface 2)
> [ 301.056934] uvcvideo 1-1:1.2: usb_probe_interface
> [ 301.058072] uvcvideo 1-1:1.2: usb_probe_interface - got id
> [ 301.059395] uvcvideo: Found UVC 1.00 device <unnamed> (046d:081d)
> [ 301.090173] input: UVC Camera (046d:081d) as /devices/pci0000:00/0000:00:1f.5/usb1/1-1/1-1:1.2/input/input7
That seems to be a Logitech model.
> [ 301.111289] usb 1-1: adding 1-1:1.3 (config #1, interface 3)
> [ 301.131207] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us]
> [ 301.137066] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us]
> [ 301.156451] ehci_hcd 0000:00:1f.5: reused qh f48d64c0 schedule
> [ 301.158310] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us]
> [ 301.160238] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us]
> [ 301.196606] set resolution quirk: cval->res = 384
> [ 371.309569] e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
> [ 390.729568] ehci_hcd 0000:00:1f.5: reused qh f48d64c0 schedule
> f5ade900 2296555[ 390.730023] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us]
> 437 S Ii:1:003:7[ 390.736394] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us]
> -115:128 16 <
> f5ade900 2296566256 C Ii:1:003:7 -2:128 0
> [ 391.100896] ehci_hcd 0000:00:1f.5: reused qh f48d64c0 schedule
> [ 391.103188] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us]
> f5ade900 2296926929 S Ii:1:003:7[ 391.104889] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us]
> -115:128 16 <
> f5ade900 2296937889 C Ii:1:003:7 -2:128 0
> f5272300 2310382508 S Co:1:003:0 s 01 0b 0004 0001 0000 0
> f5272300 2310407888 C Co:1:003:0 0 0
> f5272300 2310408051 S Co:1:003:0 s 22 01 0100 0086 0003 3 = 80bb00
> f5272300 2310412456 C Co:1:003:0 0 3 >
> f5272300 2310412521 S Ci:1:003:0 s a2 81 0100 0086 0003 3 <
> f5272300 2310415909 C Ci:1:003:0 0 0
> f5272300 2310418133 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 <
> f5272600 2310418219 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 <
> f52720c0 2310418239 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 <
> f5272a80 2310418247 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 <
> f5272480 2310418256 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 <
> f52723c0 2310418264 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 <
> f5272d80 2310418272 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 <
> f5272b40 2310418280 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 <
At least this last packet was an isochronous input on ep 6 which has
state -EINPROGRESS, but that isn't necessarily related.
> Hard freeze with 100% CPU usage at this point as if some driver got into an
> infinite loop or something.
>From your first mail in this thread, I suspect that to be some sort of
memory corruption, but now you're seeing a hard freeze. Hmm.
> All debug options from https://lkml.org/lkml/2012/10/20/116 are enabled, but
> serial console is empty.
Some thoughts:
- As Alan asked, it would be interesting to separate video and audio
functions in this test, either by unloading the kernel modules one by
one or by disallowing Flash access to the devices.
- Can you reproduce this with some other webcam tool like "cheese"?
- Can you reproduce this with some other audio capture tool like
"arecord" (use "-D" to point it to the correct device, and play with
various sample rates and buffer sizes here)
- Do you have any built-in webcam or microphone? Does it work when you
use them instead?
- Does http://trust.com/service/guides/webcam/ also crash your kernel?
- if you can narrow down the issue to USB devices, please post the
output of "lsusb -v"
I tried Chrome 22 on Ubuntu with a cheap Logitech USB webcam (different
product ID than yours, though) under 3.6.0 and 3.6.2, and I can't
reproduce the issue.
Daniel
^ permalink raw reply
* Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
From: Alan Stern @ 2012-10-21 2:19 UTC (permalink / raw)
To: Artem S. Tashkinov
Cc: bp, pavel, linux-kernel, netdev, security, linux-media, linux-usb
In-Reply-To: <1781795634.31179.1350774917965.JavaMail.mail@webmail04>
On Sat, 20 Oct 2012, Artem S. Tashkinov wrote:
> You don't get me - I have *no* VirtualBox (or any proprietary) modules running
> - but I can reproduce this problem using *the same system running under* VirtualBox
> in Windows 7 64.
>
> It's almost definitely either a USB driver bug or video4linux driver bug:
Does the same thing happen with earlier kernel versions?
What about if you unload snd-usb-audio or ehci-hcd?
Alan Stern
^ permalink raw reply
* Re: Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
From: Artem S. Tashkinov @ 2012-10-21 1:57 UTC (permalink / raw)
To: bp; +Cc: pavel, linux-kernel, netdev, security, linux-media, linux-usb
In-Reply-To: <20121021002424.GA16247@liondog.tnic>
> On Oct 21, 2012, Borislav Petkov wrote:
>
> On Sat, Oct 20, 2012 at 11:15:17PM +0000, Artem S. Tashkinov wrote:
> > You don't get me - I have *no* VirtualBox (or any proprietary) modules
> > running
>
> Ok, good. We got that out of the way - I wanted to make sure after you
> replied with two other possibilities of the system freezing.
>
> > - but I can reproduce this problem using *the same system running
> > under* VirtualBox in Windows 7 64.
>
> That's windoze as host and linux as a guest, correct?
Exactly.
> If so, that's virtualbox's problem, I'd say.
I can reproduce it on my host *alone* as I said in the very first message - never
before I tried to run my Linux in a virtual machine. Please, just forget about
VirtualBox - it has nothing to do with this problem.
> > It's almost definitely either a USB driver bug or video4linux driver
> > bug:
>
> And you're assuming that because the freeze happens when using your usb
> webcam, correct? And not otherwise?
Yes, like I said earlier - only when I try to access its settings using Adobe Flash the
system crashes/freezes.
> Maybe you can describe in more detail what exactly you're doing so that
> people could try to reproduce your issue.
I don't think many people have the same webcam so it's going to be a problem. It
can be reproduced easily - just open Flash "Settings" in Google Chrome 22. The
crash will occur immediately.
> > I'm CC'ing linux-media and linux-usb mailing lists, the problem is described here:
> > https://lkml.org/lkml/2012/10/20/35
> > https://lkml.org/lkml/2012/10/20/148
>
> Yes, good idea. Maybe the folks there have some more ideas how to debug
> this.
>
> I'm leaving in the rest for reference.
>
> What should be pointed out, though, is that you don't have any more
> random corruptions causing oopses now that virtualbox is gone. The
> freeze below is a whole another issue.
The freeze happens on my *host* Linux PC. For an experiment I decided to
check if I could reproduce the freeze under a virtual machine - it turns out the
Linux kernel running under it also freezes.
Artem
^ permalink raw reply
* Re: [PATCH v3 0/7] mv643xx.c: Add basic device tree support.
From: Jason Cooper @ 2012-10-21 1:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
andrew-g2DYL2Zd6BY, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
ben.dooks-4yDnlxn2s6sWdaTGBSpHTA, Ian Molton,
dale-1viX+2+OPRFcxvNqPlePQg, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
David Miller, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1347343411.2603.42.camel@pasglop>
Pong. ;-)
On Tue, Sep 11, 2012 at 04:03:31PM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2012-09-10 at 14:22 +0000, Arnd Bergmann wrote:
> > Following up on the old discussion, I talked briefly about this
> > issue with BenH at the kernel summit. The outcome basically is that
> > it's a bit sad to have incompatible bindings, but it's not the end
> > of the world,and it's more important to do it right this time.
> >
> > Just make sure that you use different values for the 'compatible'
> > strings and then do what you need to get the ARM hardware working.
> >
> > Ideally, the new binding should be written in a way that powerpc
> > machines can use the same one, but the existing ones all use
> > an version of Open Firmware that is not going to get updated
> > and it's also not too likely that we are going to see new
> > powerpc machines based on this chip.
>
> Right, mostly these machines where the Pegasos. Those came with a fairly
> busted variant of Open Firmware which generated a pretty gross
> device-tree.
>
> For some reason, the manufacturer of those things was never willing to
> fix anything in their firmware (despite the distributor providing
> patches etc...), seemingly on the assumption that whatever they were
> doing was perfect and operating system people like us didn't matter one
> little bit :-)
>
> So I don't care much about it. It would be nice to keep them working
> since people in the community still have them but if it goes through
> some "compat" code that detects old/broken device-trees and eventually
> disappears when we finally drop support, then so be it.
Ian,
What is the status of this work?
thx,
Jason.
^ permalink raw reply
* Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
From: Borislav Petkov @ 2012-10-21 0:24 UTC (permalink / raw)
To: Artem S. Tashkinov
Cc: pavel-+ZI9xUNit7I, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, security-DgEjT+Ai2ygdnm+yROfE0A,
linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1781795634.31179.1350774917965.JavaMail.mail@webmail04>
On Sat, Oct 20, 2012 at 11:15:17PM +0000, Artem S. Tashkinov wrote:
> You don't get me - I have *no* VirtualBox (or any proprietary) modules
> running
Ok, good. We got that out of the way - I wanted to make sure after you
replied with two other possibilities of the system freezing.
> - but I can reproduce this problem using *the same system running
> under* VirtualBox in Windows 7 64.
That's windoze as host and linux as a guest, correct?
If so, that's virtualbox's problem, I'd say.
> It's almost definitely either a USB driver bug or video4linux driver
> bug:
And you're assuming that because the freeze happens when using your usb
webcam, correct? And not otherwise?
Maybe you can describe in more detail what exactly you're doing so that
people could try to reproduce your issue.
> I'm CC'ing linux-media and linux-usb mailing lists, the problem is described here:
> https://lkml.org/lkml/2012/10/20/35
> https://lkml.org/lkml/2012/10/20/148
Yes, good idea. Maybe the folks there have some more ideas how to debug
this.
I'm leaving in the rest for reference.
What should be pointed out, though, is that you don't have any more
random corruptions causing oopses now that virtualbox is gone. The
freeze below is a whole another issue.
Thanks.
> Here are the last lines from my dmesg (with usbmon loaded):
>
> [ 292.164833] hub 1-0:1.0: state 7 ports 8 chg 0000 evt 0002
> [ 292.168091] ehci_hcd 0000:00:1f.5: GetStatus port:1 status 00100a 0 ACK POWER sig=se0 PEC CSC
> [ 292.172063] hub 1-0:1.0: port 1, status 0100, change 0003, 12 Mb/s
> [ 292.174883] usb 1-1: USB disconnect, device number 2
> [ 292.178045] usb 1-1: unregistering device
> [ 292.183539] usb 1-1: unregistering interface 1-1:1.0
> [ 292.197034] usb 1-1: unregistering interface 1-1:1.1
> [ 292.204317] usb 1-1: unregistering interface 1-1:1.2
> [ 292.234519] usb 1-1: unregistering interface 1-1:1.3
> [ 292.236175] usb 1-1: usb_disable_device nuking all URBs
> [ 292.364429] hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x100
> [ 294.364279] hub 1-0:1.0: hub_suspend
> [ 294.366045] usb usb1: bus auto-suspend, wakeup 1
> [ 294.367375] ehci_hcd 0000:00:1f.5: suspend root hub
> [ 296.501084] usb usb1: usb wakeup-resume
> [ 296.508311] usb usb1: usb auto-resume
> [ 296.509833] ehci_hcd 0000:00:1f.5: resume root hub
> [ 296.560149] hub 1-0:1.0: hub_resume
> [ 296.562240] ehci_hcd 0000:00:1f.5: GetStatus port:1 status 001003 0 ACK POWER sig=se0 CSC CONNECT
> [ 296.566141] hub 1-0:1.0: port 1: status 0501 change 0001
> [ 296.670413] hub 1-0:1.0: state 7 ports 8 chg 0002 evt 0000
> [ 296.673222] hub 1-0:1.0: port 1, status 0501, change 0000, 480 Mb/s
> [ 297.311720] usb 1-1: new high-speed USB device number 3 using ehci_hcd
> [ 300.547237] usb 1-1: skipped 1 descriptor after configuration
> [ 300.549443] usb 1-1: skipped 4 descriptors after interface
> [ 300.552273] usb 1-1: skipped 2 descriptors after interface
> [ 300.556499] usb 1-1: skipped 1 descriptor after endpoint
> [ 300.559392] usb 1-1: skipped 2 descriptors after interface
> [ 300.560960] usb 1-1: skipped 1 descriptor after endpoint
> [ 300.562169] usb 1-1: skipped 2 descriptors after interface
> [ 300.563440] usb 1-1: skipped 1 descriptor after endpoint
> [ 300.564639] usb 1-1: skipped 2 descriptors after interface
> [ 300.565828] usb 1-1: skipped 2 descriptors after endpoint
> [ 300.567084] usb 1-1: skipped 9 descriptors after interface
> [ 300.569205] usb 1-1: skipped 1 descriptor after endpoint
> [ 300.570484] usb 1-1: skipped 53 descriptors after interface
> [ 300.595843] usb 1-1: default language 0x0409
> [ 300.602503] usb 1-1: USB interface quirks for this device: 2
> [ 300.605700] usb 1-1: udev 3, busnum 1, minor = 2
> [ 300.606959] usb 1-1: New USB device found, idVendor=046d, idProduct=081d
> [ 300.610298] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=1
> [ 300.613742] usb 1-1: SerialNumber: 48C5D2B0
> [ 300.617703] usb 1-1: usb_probe_device
> [ 300.620594] usb 1-1: configuration #1 chosen from 1 choice
> [ 300.639218] usb 1-1: adding 1-1:1.0 (config #1, interface 0)
> [ 300.640736] snd-usb-audio 1-1:1.0: usb_probe_interface
> [ 300.642307] snd-usb-audio 1-1:1.0: usb_probe_interface - got id
> [ 301.050296] usb 1-1: adding 1-1:1.1 (config #1, interface 1)
> [ 301.054897] usb 1-1: adding 1-1:1.2 (config #1, interface 2)
> [ 301.056934] uvcvideo 1-1:1.2: usb_probe_interface
> [ 301.058072] uvcvideo 1-1:1.2: usb_probe_interface - got id
> [ 301.059395] uvcvideo: Found UVC 1.00 device <unnamed> (046d:081d)
> [ 301.090173] input: UVC Camera (046d:081d) as /devices/pci0000:00/0000:00:1f.5/usb1/1-1/1-1:1.2/input/input7
> [ 301.111289] usb 1-1: adding 1-1:1.3 (config #1, interface 3)
> [ 301.131207] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us]
> [ 301.137066] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us]
> [ 301.156451] ehci_hcd 0000:00:1f.5: reused qh f48d64c0 schedule
> [ 301.158310] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us]
> [ 301.160238] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us]
> [ 301.196606] set resolution quirk: cval->res = 384
> [ 371.309569] e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
> [ 390.729568] ehci_hcd 0000:00:1f.5: reused qh f48d64c0 schedule
> f5ade900 2296555[ 390.730023] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us]
> 437 S Ii:1:003:7[ 390.736394] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us]
> -115:128 16 <
> f5ade900 2296566256 C Ii:1:003:7 -2:128 0
> [ 391.100896] ehci_hcd 0000:00:1f.5: reused qh f48d64c0 schedule
> [ 391.103188] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us]
> f5ade900 2296926929 S Ii:1:003:7[ 391.104889] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us]
> -115:128 16 <
> f5ade900 2296937889 C Ii:1:003:7 -2:128 0
> f5272300 2310382508 S Co:1:003:0 s 01 0b 0004 0001 0000 0
> f5272300 2310407888 C Co:1:003:0 0 0
> f5272300 2310408051 S Co:1:003:0 s 22 01 0100 0086 0003 3 = 80bb00
> f5272300 2310412456 C Co:1:003:0 0 3 >
> f5272300 2310412521 S Ci:1:003:0 s a2 81 0100 0086 0003 3 <
> f5272300 2310415909 C Ci:1:003:0 0 0
> f5272300 2310418133 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 <
> f5272600 2310418219 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 <
> f52720c0 2310418239 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 <
> f5272a80 2310418247 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 <
> f5272480 2310418256 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 <
> f52723c0 2310418264 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 <
> f5272d80 2310418272 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 <
> f5272b40 2310418280 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 <
>
> Hard freeze with 100% CPU usage at this point as if some driver got into an
> infinite loop or something.
>
> All debug options from https://lkml.org/lkml/2012/10/20/116 are enabled, but
> serial console is empty.
>
> Best wishes,
>
> Artem
>
>
> On Oct 21, 2012, Borislav Petkov wrote:
>
> > I don't think that's the problem - I rather suspect the fact that he's
> > using virtualbox which is causing random corruptions by writing to
> > arbitrary locations.
> >
> >
> >
> > please remove virtualbox completely from your system, rebuild the kernel
> > and make sure the virtualbox kernel modules don't get loaded - simply
> > delete them so that they are completely gone; *and* *then* retest again.
>
>
--
Regards/Gruss,
Boris.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: PROBLEM: Memory leak (at least with SLUB) from "secpath_dup" (xfrm) in 3.5+ kernels
From: Mike Kazantsev @ 2012-10-21 0:24 UTC (permalink / raw)
To: Paul Moore; +Cc: netdev, linux-mm
In-Reply-To: <20121021044540.12e8f4b7@sacrilege>
[-- Attachment #1: Type: text/plain, Size: 4400 bytes --]
On Sun, 21 Oct 2012 04:45:40 +0600
Mike Kazantsev <mk.fraggod@gmail.com> wrote:
>
> kmemleak mechanism seem to provide stack traces and interesting calls
> for debugging of whatever is allocating the non-freed objects, so guess
> I'll see if I can get more definitive (to my ignorant eye) "look here"
> hint from it, and might drop one more mail with data from there.
>
kmemleak finds a lot (dozens megabytes of stack traces) of identical
paths leading to a leaks:
(for IPv6 packets)
unreferenced object 0xffff88002fa25b00 (size 56):
comm "softirq", pid 0, jiffies 4295009073 (age 295.620s)
hex dump (first 32 bytes):
01 00 00 00 01 00 00 00 00 fc 6e 30 00 88 ff ff ..........n0....
6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
backtrace:
[<ffffffff814cfa2b>] kmemleak_alloc+0x21/0x3e
[<ffffffff810d9445>] kmem_cache_alloc+0xa5/0xb1
[<ffffffff8147dd35>] secpath_dup+0x1b/0x5a
[<ffffffff8147df39>] xfrm_input+0x64/0x484
[<ffffffff814b1d2c>] xfrm6_rcv_spi+0x19/0x1b
[<ffffffff814b1d4e>] xfrm6_rcv+0x20/0x22
[<ffffffff8148c19f>] ip6_input_finish+0x203/0x31b
[<ffffffff8148c622>] ip6_input+0x1e/0x50
[<ffffffff8148c31c>] ip6_rcv_finish+0x65/0x69
[<ffffffff8148c5a3>] ipv6_rcv+0x283/0x2e4
[<ffffffff813ff8ba>] __netif_receive_skb+0x599/0x64c
[<ffffffff813ffb08>] netif_receive_skb+0x47/0x78
[<ffffffff81400644>] napi_skb_finish+0x21/0x53
[<ffffffff81400778>] napi_gro_receive+0x102/0x10e
[<ffffffff8136978b>] rtl8169_poll+0x326/0x4f9
[<ffffffff813ffcda>] net_rx_action+0x9f/0x175
(for IPv4 packets)
unreferenced object 0xffff88003387e000 (size 56):
comm "softirq", pid 0, jiffies 4294915803 (age 563.583s)
hex dump (first 32 bytes):
01 00 00 00 01 00 00 00 00 48 be 30 00 88 ff ff .........H.0....
6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
backtrace:
[<ffffffff814cfa2b>] kmemleak_alloc+0x21/0x3e
[<ffffffff810d9445>] kmem_cache_alloc+0xa5/0xb1
[<ffffffff8147dd35>] secpath_dup+0x1b/0x5a
[<ffffffff8147df39>] xfrm_input+0x64/0x484
[<ffffffff81474f7b>] xfrm4_rcv_encap+0x17/0x19
[<ffffffff81474f9c>] xfrm4_rcv+0x1f/0x21
[<ffffffff81430514>] ip_local_deliver_finish+0x170/0x22a
[<ffffffff81430706>] ip_local_deliver+0x46/0x78
[<ffffffff8143038d>] ip_rcv_finish+0x2bd/0x2d4
[<ffffffff81430969>] ip_rcv+0x231/0x28c
[<ffffffff813ff8ba>] __netif_receive_skb+0x599/0x64c
[<ffffffff813ffb08>] netif_receive_skb+0x47/0x78
[<ffffffff81400644>] napi_skb_finish+0x21/0x53
[<ffffffff81400778>] napi_gro_receive+0x102/0x10e
[<ffffffff8136978b>] rtl8169_poll+0x326/0x4f9
[<ffffffff813ffcda>] net_rx_action+0x9f/0x175
Object at the top and trace seem to be the same (between same
IP-family) everywhere, just ages and addresses are different.
IPv6 usage seem to be one important detail which I failed to mention.
IPv4 traces seem to be really rare (only several of them), but that
might be understandable because rsync was ran over IPv6.
Still wasn't able to figure out what might cause the get's/put's
disbalance with that commit, but was able to revert it, without
anything bad happening (so far), using the patch below (in case
issue might bite someone else before proper fix is found).
--
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 6e04b1f..52a9d40 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -427,26 +427,8 @@ struct sk_buff *__netdev_alloc_skb(struct net_device *dev,
unsigned int length, gfp_t gfp_mask)
{
struct sk_buff *skb = NULL;
- unsigned int fragsz = SKB_DATA_ALIGN(length + NET_SKB_PAD) +
- SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
-
- if (fragsz <= PAGE_SIZE && !(gfp_mask & (__GFP_WAIT | GFP_DMA))) {
- void *data;
-
- if (sk_memalloc_socks())
- gfp_mask |= __GFP_MEMALLOC;
-
- data = __netdev_alloc_frag(fragsz, gfp_mask);
-
- if (likely(data)) {
- skb = build_skb(data, fragsz);
- if (unlikely(!skb))
- put_page(virt_to_head_page(data));
- }
- } else {
- skb = __alloc_skb(length + NET_SKB_PAD, gfp_mask,
+ skb = __alloc_skb(length + NET_SKB_PAD, gfp_mask,
SKB_ALLOC_RX, NUMA_NO_NODE);
- }
if (likely(skb)) {
skb_reserve(skb, NET_SKB_PAD);
skb->dev = dev;
--
Mike Kazantsev // fraggod.net
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply related
* Re: [BUG] Kernel recieves DNS reply, but doesn't deliver it to a waiting application
From: Andrew Savchenko @ 2012-10-20 23:25 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <20121014031119.a60263d6.bircoph@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4558 bytes --]
Hello,
On Sun, 14 Oct 2012 03:11:19 +0400 Andrew Savchenko wrote:
> On Sat, 13 Oct 2012 15:44:20 +0200 Eric Dumazet wrote:
> > On Sat, 2012-10-13 at 16:36 +0400, Andrew Savchenko wrote:
> > > On Wed, 3 Oct 2012 23:25:48 +0400 Andrew Savchenko wrote:
> > > > I encountered a very weird bug: after a while of uptime kernel stops to deliver
> > > > DNS reply to applications. Tcpdump shows that correct reply is recieved, but
> > > > strace shows inquiring application never recieves it and ends with timeout,
> > > > epoll_wait() always returns 0:
> > > > a slice from: $ host kernel.org 8.8.8.8:
> [...]
> > > > In a few days I'll try 3.4.12 (I need to rebuild kernel anyway due to unrelated
> > > > issue) and will report if this bug will occur again. But please note it may
> > > > take several weeks to check this.
> > >
> > > I got this problem again with 3.4.12 kernel. System lasted less than
> > > a week and reboot was the only option...
> >
> > You should investigate and check where the incoming packet is lost
> >
> > Tools :
> >
> > netstat -s
> >
> > drop_monitor module and dropwatch command
> >
> > cat /proc/net/udp
>
> Thank you for you reply; I updated my kernel to 3.4.14, enabled
> CONFIG_NET_DROP_MONITOR, and installed dropwatch utility.
>
> I will report back when the bug will struck again.
> This may take a weak or two, however.
This bug is back again on kernel 3.4.14, but this time I was able to
get debug data and to recover running kernel without reboot.
Drowpatch showed that DNS UDP replies are always dropped here:
1 drops at __udp_queue_rcv_skb+61 (0xffffffff813bd670)
Another observations:
- only UDP replies are lost, TCP works fine;
- if network load is dropped dramatically (ip_forward disabled, most
network daemons are stopped) UDP DNS queries work again; but with
gradual load increase replies became first slow and than cease at all.
- CPU load is very low (uptime is below 0.05), so this shouldn't be
an insufficient computing power issue.
I found __udp_queue_rcv_skb function in net/ipv4/udp.c. From the code
and observations above it follows that this is likely to be a ENOMEM
condition leading to a packet loss.
This is a memory data after bug happened:
# cat /proc/meminfo
MemTotal: 1021576 kB
MemFree: 32056 kB
Buffers: 105204 kB
Cached: 646716 kB
SwapCached: 236 kB
Active: 205932 kB
Inactive: 587156 kB
Active(anon): 20636 kB
Inactive(anon): 22488 kB
Active(file): 185296 kB
Inactive(file): 564668 kB
Unevictable: 2152 kB
Mlocked: 2152 kB
SwapTotal: 995992 kB
SwapFree: 995020 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 43120 kB
Mapped: 7504 kB
Shmem: 148 kB
Slab: 176004 kB
SReclaimable: 118636 kB
SUnreclaim: 57368 kB
KernelStack: 688 kB
PageTables: 2948 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 1506780 kB
Committed_AS: 62708 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 262732 kB
VmallocChunk: 34359474615 kB
AnonHugePages: 0 kB
DirectMap4k: 33536 kB
DirectMap2M: 1013760 kB
# sysctl -a | grep mem
net.core.optmem_max = 20480
net.core.rmem_default = 229376
net.core.rmem_max = 131071
net.core.wmem_default = 229376
net.core.wmem_max = 131071
net.ipv4.igmp_max_memberships = 20
net.ipv4.tcp_mem = 22350 29801 44700
net.ipv4.tcp_rmem = 4096 87380 6291456
net.ipv4.tcp_wmem = 4096 16384 4194304
net.ipv4.udp_mem = 24150 32202 48300
net.ipv4.udp_rmem_min = 4096
net.ipv4.udp_wmem_min = 4096
vm.lowmem_reserve_ratio = 256 256 32
vm.overcommit_memory = 0
Sysctl memory parameters are system defaults, I haven't changed them
via sysctl or /proc interfaces.
I tried to increase udm_mem values to the following:
net.ipv4.udp_mem = 100000 150000 200000
This solved my issue, at least for a while: DNS queries are working
fine now.
But I suspect that there is some memory loss in the kernel UDP stack,
because this issue never happens after reboot and always after about
a week of network operation. So this memory increase should help only
for a month or so, if memory loss is linear.
If you need some memory debug information, let me know which one and
what tools will be needed.
Best regards,
Andrew Savchenko
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
From: Artem S. Tashkinov @ 2012-10-20 23:15 UTC (permalink / raw)
To: bp; +Cc: pavel, linux-kernel, netdev, security, linux-media, linux-usb
In-Reply-To: <20121020225849.GA8976@liondog.tnic>
You don't get me - I have *no* VirtualBox (or any proprietary) modules running
- but I can reproduce this problem using *the same system running under* VirtualBox
in Windows 7 64.
It's almost definitely either a USB driver bug or video4linux driver bug:
I'm CC'ing linux-media and linux-usb mailing lists, the problem is described here:
https://lkml.org/lkml/2012/10/20/35
https://lkml.org/lkml/2012/10/20/148
Here are the last lines from my dmesg (with usbmon loaded):
[ 292.164833] hub 1-0:1.0: state 7 ports 8 chg 0000 evt 0002
[ 292.168091] ehci_hcd 0000:00:1f.5: GetStatus port:1 status 00100a 0 ACK POWER sig=se0 PEC CSC
[ 292.172063] hub 1-0:1.0: port 1, status 0100, change 0003, 12 Mb/s
[ 292.174883] usb 1-1: USB disconnect, device number 2
[ 292.178045] usb 1-1: unregistering device
[ 292.183539] usb 1-1: unregistering interface 1-1:1.0
[ 292.197034] usb 1-1: unregistering interface 1-1:1.1
[ 292.204317] usb 1-1: unregistering interface 1-1:1.2
[ 292.234519] usb 1-1: unregistering interface 1-1:1.3
[ 292.236175] usb 1-1: usb_disable_device nuking all URBs
[ 292.364429] hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x100
[ 294.364279] hub 1-0:1.0: hub_suspend
[ 294.366045] usb usb1: bus auto-suspend, wakeup 1
[ 294.367375] ehci_hcd 0000:00:1f.5: suspend root hub
[ 296.501084] usb usb1: usb wakeup-resume
[ 296.508311] usb usb1: usb auto-resume
[ 296.509833] ehci_hcd 0000:00:1f.5: resume root hub
[ 296.560149] hub 1-0:1.0: hub_resume
[ 296.562240] ehci_hcd 0000:00:1f.5: GetStatus port:1 status 001003 0 ACK POWER sig=se0 CSC CONNECT
[ 296.566141] hub 1-0:1.0: port 1: status 0501 change 0001
[ 296.670413] hub 1-0:1.0: state 7 ports 8 chg 0002 evt 0000
[ 296.673222] hub 1-0:1.0: port 1, status 0501, change 0000, 480 Mb/s
[ 297.311720] usb 1-1: new high-speed USB device number 3 using ehci_hcd
[ 300.547237] usb 1-1: skipped 1 descriptor after configuration
[ 300.549443] usb 1-1: skipped 4 descriptors after interface
[ 300.552273] usb 1-1: skipped 2 descriptors after interface
[ 300.556499] usb 1-1: skipped 1 descriptor after endpoint
[ 300.559392] usb 1-1: skipped 2 descriptors after interface
[ 300.560960] usb 1-1: skipped 1 descriptor after endpoint
[ 300.562169] usb 1-1: skipped 2 descriptors after interface
[ 300.563440] usb 1-1: skipped 1 descriptor after endpoint
[ 300.564639] usb 1-1: skipped 2 descriptors after interface
[ 300.565828] usb 1-1: skipped 2 descriptors after endpoint
[ 300.567084] usb 1-1: skipped 9 descriptors after interface
[ 300.569205] usb 1-1: skipped 1 descriptor after endpoint
[ 300.570484] usb 1-1: skipped 53 descriptors after interface
[ 300.595843] usb 1-1: default language 0x0409
[ 300.602503] usb 1-1: USB interface quirks for this device: 2
[ 300.605700] usb 1-1: udev 3, busnum 1, minor = 2
[ 300.606959] usb 1-1: New USB device found, idVendor=046d, idProduct=081d
[ 300.610298] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=1
[ 300.613742] usb 1-1: SerialNumber: 48C5D2B0
[ 300.617703] usb 1-1: usb_probe_device
[ 300.620594] usb 1-1: configuration #1 chosen from 1 choice
[ 300.639218] usb 1-1: adding 1-1:1.0 (config #1, interface 0)
[ 300.640736] snd-usb-audio 1-1:1.0: usb_probe_interface
[ 300.642307] snd-usb-audio 1-1:1.0: usb_probe_interface - got id
[ 301.050296] usb 1-1: adding 1-1:1.1 (config #1, interface 1)
[ 301.054897] usb 1-1: adding 1-1:1.2 (config #1, interface 2)
[ 301.056934] uvcvideo 1-1:1.2: usb_probe_interface
[ 301.058072] uvcvideo 1-1:1.2: usb_probe_interface - got id
[ 301.059395] uvcvideo: Found UVC 1.00 device <unnamed> (046d:081d)
[ 301.090173] input: UVC Camera (046d:081d) as /devices/pci0000:00/0000:00:1f.5/usb1/1-1/1-1:1.2/input/input7
[ 301.111289] usb 1-1: adding 1-1:1.3 (config #1, interface 3)
[ 301.131207] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us]
[ 301.137066] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us]
[ 301.156451] ehci_hcd 0000:00:1f.5: reused qh f48d64c0 schedule
[ 301.158310] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us]
[ 301.160238] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us]
[ 301.196606] set resolution quirk: cval->res = 384
[ 371.309569] e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
[ 390.729568] ehci_hcd 0000:00:1f.5: reused qh f48d64c0 schedule
f5ade900 2296555[ 390.730023] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us]
437 S Ii:1:003:7[ 390.736394] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us]
-115:128 16 <
f5ade900 2296566256 C Ii:1:003:7 -2:128 0
[ 391.100896] ehci_hcd 0000:00:1f.5: reused qh f48d64c0 schedule
[ 391.103188] usb 1-1: link qh16-0001/f48d64c0 start 2 [1/0 us]
f5ade900 2296926929 S Ii:1:003:7[ 391.104889] usb 1-1: unlink qh16-0001/f48d64c0 start 2 [1/0 us]
-115:128 16 <
f5ade900 2296937889 C Ii:1:003:7 -2:128 0
f5272300 2310382508 S Co:1:003:0 s 01 0b 0004 0001 0000 0
f5272300 2310407888 C Co:1:003:0 0 0
f5272300 2310408051 S Co:1:003:0 s 22 01 0100 0086 0003 3 = 80bb00
f5272300 2310412456 C Co:1:003:0 0 3 >
f5272300 2310412521 S Ci:1:003:0 s a2 81 0100 0086 0003 3 <
f5272300 2310415909 C Ci:1:003:0 0 0
f5272300 2310418133 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 <
f5272600 2310418219 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 <
f52720c0 2310418239 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 <
f5272a80 2310418247 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 <
f5272480 2310418256 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 <
f52723c0 2310418264 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 <
f5272d80 2310418272 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 <
f5272b40 2310418280 S Zi:1:003:6 -115:8:0 1 -18:0:100 100 <
Hard freeze with 100% CPU usage at this point as if some driver got into an
infinite loop or something.
All debug options from https://lkml.org/lkml/2012/10/20/116 are enabled, but
serial console is empty.
Best wishes,
Artem
On Oct 21, 2012, Borislav Petkov wrote:
> I don't think that's the problem - I rather suspect the fact that he's
> using virtualbox which is causing random corruptions by writing to
> arbitrary locations.
>
>
>
> please remove virtualbox completely from your system, rebuild the kernel
> and make sure the virtualbox kernel modules don't get loaded - simply
> delete them so that they are completely gone; *and* *then* retest again.
^ permalink raw reply
* Re: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
From: Borislav Petkov @ 2012-10-20 22:58 UTC (permalink / raw)
To: Pavel Machek; +Cc: Artem S. Tashkinov, linux-kernel, netdev, security
In-Reply-To: <20121020203227.GC555@elf.ucw.cz>
On Sat, Oct 20, 2012 at 10:32:28PM +0200, Pavel Machek wrote:
> On Sat 2012-10-20 17:41:49, Artem S. Tashkinov wrote:
> > On Oct 20, 2012, Borislav Petkov wrote:
> >
> > > Yeah, your kernel is tainted with a proprietary module (vbox*, etc). Can
> > > you reproduce your corruptions (this is what it looks like) without that
> > > module?
> >
> > Yes, I can reproduce this panic with zero proprietary/non-free modules loaded.
> >
> > The problem is the kernel doesn't even print a kernel panic - the
> > system just freezes completely - cursor in a text console stops
> > blinking.
>
> bugtraq? :-).
>
> If remote website can crash your Linux, that's quite significant news.
>
> (Cc-ed netdev@ and security@ ... this may be important).
I don't think that's the problem - I rather suspect the fact that he's
using virtualbox which is causing random corruptions by writing to
arbitrary locations.
Artem,
please remove virtualbox completely from your system, rebuild the kernel
and make sure the virtualbox kernel modules don't get loaded - simply
delete them so that they are completely gone; *and* *then* retest again.
Thanks.
--
Regards/Gruss,
Boris.
^ permalink raw reply
* Re: PROBLEM: Memory leak (at least with SLUB) from "secpath_dup" (xfrm) in 3.5+ kernels
From: Mike Kazantsev @ 2012-10-20 22:45 UTC (permalink / raw)
To: Paul Moore; +Cc: netdev, linux-mm
In-Reply-To: <20121020204958.4bc8e293@sacrilege>
[-- Attachment #1: Type: text/plain, Size: 3897 bytes --]
On Sat, 20 Oct 2012 20:49:58 +0600
Mike Kazantsev <mk.fraggod@gmail.com> wrote:
> On Sat, 20 Oct 2012 08:42:33 -0400
> Paul Moore <paul@paul-moore.com> wrote:
>
> > Thanks for the problem report. I'm not going to be in a position to start
> > looking into this until late Sunday, but hopefully it will be a quick fix.
> >
> > Two quick questions (my apologies, I'm not able to dig through your logs
> > right now): do you see this leak on kernels < 3.5.0, and are you using any
> > labeled IPsec connections?
> >
>
> As I understand, labelled connections are only used in SELinux
> and SMACK LSM, which are not enabled (in Kconfig, i.e. not built) in any
> of the kernels I use.
>
> The only LSM I have enabled (and actually use on 2/4 of these machines)
> is AppArmor, and though I think it doesn't attach any labels to network
> connections yet (there's a "Wishlist" bug at
> https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/796588, but I
> can't seem to find an existing implementation).
>
> I believe it has started with 3.5.0, according to all available logs I
> have. I'm afraid laziness and other tasks have prevented me from
> looking into and reporting the issue back then, but memory graph trends
> start at the exact time of reboot into 3.5.0 kernels, and before that,
> there're no such trends for slab memory usage.
>
> I've been able to ignore and work around the problem for months now, so
> I don't think there's any rush at all ;)
>
> But that said, currently I've started git bisect process between v3.5
> and v3.4 tags, so hopefully I'll get good-enough results of it before
> you'll get to it (probably in a few hours to a few days).
>
> Also, I've found that switching to "slab" allocator from "slub" doesn't
> help the problem at all, so I guess something doesn't get freed in the
> code indeed, though I hasn't been able to find anything relevant in the
> logs for the sources where secpath_put and secpath_dup are used, and
> decided to try bisect.
>
Sorry for yet another mail on the weekend, but I've finished the bisect
and here is the result:
a1c7fff7e18f59e684e07b0f9a770561cd39f395 is the first bad commit
commit a1c7fff7e18f59e684e07b0f9a770561cd39f395
Author: Eric Dumazet <edumazet@google.com>
Date: Thu May 17 07:34:16 2012 +0000
net: netdev_alloc_skb() use build_skb()
netdev_alloc_skb() is used by networks driver in their RX path to
allocate an skb to receive an incoming frame.
With recent skb->head_frag infrastructure, it makes sense to change
netdev_alloc_skb() to use build_skb() and a frag allocator.
This permits a zero copy splice(socket->pipe), and better GRO or TCP
coalescing.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
:040000 040000 17938b1b46bc38aa126cc23b7a7647259297657d 1e29cf65869391eb13552c51e0cf288fc7085fec M net
No skips, all "good" / "bad" decisions were very unambiguous and easy
to make - secpath_cache slabs either stayed at always-constant 20K
cumulative size (~5 of them) and were reported as 10-15% full in "good"
case, or were 99% full and eating memory at hudreds KiB/s (during same
rsync transfer) in "bad" case.
Reverting that commit in 3.6.2 kernel looks like a bad idea and doesn't
seem possible to do cleanly.
Being not a C coder and having only faint idea about how things should
be done with regards to socket buffers, I can't seem to find anything
to tweak based on that commit either.
kmemleak mechanism seem to provide stack traces and interesting calls
for debugging of whatever is allocating the non-freed objects, so guess
I'll see if I can get more definitive (to my ignorant eye) "look here"
hint from it, and might drop one more mail with data from there.
--
Mike Kazantsev // fraggod.net
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [net-next 01/13] ixgbe: Add support for IPv6 and UDP to ixgbe_get_headlen
From: Alexander Duyck @ 2012-10-20 20:39 UTC (permalink / raw)
To: Eric Dumazet
Cc: Jeff Kirsher, davem, Alexander Duyck, netdev, gospo, sassmann
In-Reply-To: <1350720070.13333.359.camel@edumazet-glaptop>
On 10/20/2012 1:01 AM, Eric Dumazet wrote:
> On Fri, 2012-10-19 at 23:25 -0700, Jeff Kirsher wrote:
>> From: Alexander Duyck <alexander.h.duyck@intel.com>
>>
>> This change adds support for IPv6 and UDP to ixgbe_get_headlen. The
>> advantage to this is that we can now handle ipv4/UDP, ipv6/TCP, and
>> ipv6/UDP with a single memcpy instead of having to do them in multiple
>> pskb_may_pull calls.
>>
>> A quick bit of testing shows that we increase throughput for a single
>> session of netperf from 8800Mpbs to about 9300Mpbs in the case of ipv6/TCP.
>> As such overall ipv6 performance should improve with this change.
>>
>> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
>> Tested-by: Stephen Ko <stephen.s.ko@intel.com>
>> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>> ---
>> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 15 ++++++++++++++-
>> 1 file changed, 14 insertions(+), 1 deletion(-)
> Thats pretty interesting.
>
> Why this work is not done generically, so that all drivers can have
> benefit of it ?
>
> Even a driver not using fragments could have benefit, because we could
> prefetch() so that GRO stack is faster (no stall to get the last 2 bytes
> of a TCP header when timestamps are used)
>
> Thanks
The ixgbe_get_headlen function originally was written to handle the case
where we were doing the hardware LRO/RSC feature but we weren't setting
gso_size. We were using it to get the size of the header so we could
determine the average payload size of the frame. When we switched over
to page based receive the function came along with it and had actually
prevented a performance regression for IPv4/TCP which this patch is
fixing for the other supported protocols. The main idea of this code is
now to emulate what our hardware was doing in determining the length of
the header when we had header-data split enabled. I hadn't really
thought of any way it could be used in a generic sense. The function is
essentially is built around several assumptions that only apply to the
igb/ixgbe case such as the fact that the entire block being linear and
the limitation of the protocols so that they match up with what we used
to do for header-data split.
That being said, if there is a way for you to use it in the generic case
feel free to copy the ixgbe version, rename it, and export it for use.
The key bit for me is that I just need to be able to get the header
length before calling eth_type_trans as I only want to do one memcpy for
the entire header.
Thanks,
Alex
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox